how to set archiveBaseName for local .m2 repository - maven

Question

I'm trying to upgrade a dependency to a project that will ultimately become a dependency to my project. I've made the upgrade and I want to test it locally before I put it out on the repo to be used. I'm learning Gradle and a few Google searches showed me how to add the project to the settings.gradle file. But the dependency project uses aliases for their dependencies (see build.gradle below).
settings.gradle
include ':TransportImpl'
Changed to:
include ':TransportImpl', ':jeromq'
project(':jeromq').projectDir = new File("../zeromq/jeromq")
build.gradle
//project.ext.set("JEROMQ", 'THIRD-PARTY:jeromq:0.4.2')
project.ext.set("JEROMQ", ':jeromq')
If I uncomment the original line (shown commented above), because that apk is in the repo it gets recognized. I'm guessing that this only works for external libraries.
Other things I have tried:
//project.ext.set("JEROMQ", 'C:/Users/username/.m2/repository/THIRD_PARTY/jeromq/0.5.1-SNAPSHOT/jeromq-0.5.1-SNAPSHOT-jeromq.jar')
//project.ext.set("JEROMQ", 'C:\\Users\\username\\.m2\\repository\\THIRD_PARTY\\jeromq\\0.5.1\\jeromq-0.5.1-jeromq.jar')
//implementation filetree(dir: 'C:\\Users\\username\\.m2\\repository\\THIRD_PARTY\\jeromq\\0.5.1', include:['jeromq-0.5.1-jeromq.jar'])
Can anyone give me a tip on how I can assign a variable that points to the local repository and use that variable to set an archiveBaseName?
New Information:
gradle.build for our jeromq project
apply plugin : 'maven'
apply plugin : 'maven-publish'
// Top-level build file where you can add configuration options common to all sub-projects/modules.
ext {
// Nexus paths
nexusUrl='https://nexus.path'
Releases='/Private_Releases'
nexusUsername = project.findProperty("nexusUsername") ?: (System.getenv("NEXUS_USERNAME") ?: "user_name"
nexusPassword = project.findProperty("nexusPassword") ?: (System.getenv("NEXUS_PASSWORD") ?: "password")
// Project versions
jeromqVersion = "0.5.1-SNAPSHOT"
}
allprojects {
// Read only repositories for dependencies; this should never be used to publish
repositories {
mavenCentral()
jcenter()
}
}
The project that uses it as a dependency finds it using the following from its build.gradle file:
// Create aliases for dependencies
project.ext.set("EASY_MOCK", 'Test:easymock:3.5.1')
project.ext.set("OBJENESIS", 'Test:objenesis:2.6')
// **************** HERE ***************************
// THIRD-PARTY is configured to look on the nexus server
project.ext.set("JEROMQ", 'THIRD-PARTY:jeromq:0.4.2') ... or 0.5.1 or 0.5.1-SNAPSHOT ...
allprojects {
// Read only repositories for dependencies; this should never be used to publish
repositories {
mavenCentral()
mavenLocal()
// maven {
// // trying to add my local repo,
// // BUT this still does not change where THIRD-PARTY is pointing to
// url 'file://C:/Users/me/.m2/repository/THIRD_PARTY/jeromq/0.5.1-SNAPSHOT/jeromq-0.5.1-SNAPSHOT-jeromq.jar'
// }
maven {
name 'ReleasesName'
url "$nexusUrl$ReleasesName
}
}
maven {
name 'ReleasesNameSnapshots'
url "$nexusUrl$ReleasesNameSnapshots"
credentials {
username "${rootProject.ext.nexusReadOnlyUsername}"
password "${rootProject.ext.nexusReadOnlyPassword}"
}
}
jcenter {
url "https://jcenter.bintray.com/"
}
}
The only reason I need the alias for that dependency is because it is used in other places.

Answer 1

I'm not entirely sure what you are asking, but I think what you are trying is completely off.
The build you are trying to include is a Maven build, not a Gradle build, so it is unlikely you can simply treat it as it were a Gradle build.
And even if it were a Gradle build, including it like you did would not be the right way. How you tried it is for including multiple projects of a multi-project build, not including external libraries.
If it were a Gradle build, you would use a composite build, which effectively replaces a declared binary dependency by the build output of a "sub-build". But afair this only works cleanly with a Gradle build.
Why don't you simply mvn install your modified jeromq version, add mavenLocal() to your dependencies and depend on that just installed version? That would be the usual way for locally testing new Maven built dependencies.