In the past, I've had great success in providing test helpers in a core or common project, and having those classes available to other sub-projects using the following:
Common Project A
task testJar(type: Jar) {
classifier = "tests"
from sourceSets.test.output
}
artifacts { testRuntime testJar }
Dependent Project B
testCompile(project(path: ":project-a", configuration: "testRuntime"))
However, I have the same requirement between two projects that do NOT share a Gradle multi-project hierarchy. To clarify, these are completely separate projects. They are in different repositories, using different build scripts. They are not sub-modules within a parent project.
To futher complex matters, I'm using the Java Library plugin and the Maven plugin to install libraries locally. In other words, I'd love for the second project to include a dependency as such:
testImplementation 'com.mycompany:common-test:1.0.0'
What should the first "common" project look like to a) generate that test jar and b) allow it to be installed to Maven?
Many thanks for all help.
I've found that it's best to put any test utilities in their own separate project rather than building a "test" jar from src/test/java and src/test/resources.
It seems that netflix feel the same as me. Previously they mentioned their test-jar plugin as deprecated in their documentation, now it doesn't even get a mention in the readme
Related
I'm developing library with Maven system, which is published in the Nexus repository.
In the nexus (and the maven build as well), the project produces the final jar named <projectName>-<version>.jar - this is exactly what I want.
Now, I decided to split the library into maven modules and therefore top level pom.xml have <packaging>pom</packaging>. The build also do not produce final <projectName>-<version>.jar, instead it produces <moduleName>-<version>.jar for each module.
What I want to achieve is to have the project split into modules and be able to produce final <projectName>-<version>.jar containing defined modules. Is this possible?
Is it possible to solve this issue migrating to the Gradle?
When you decided to split the library into multi modules it means that you decided to build them independently. So it's expected that each module creates it's own <moduleName>-<version>.jar.
Now when you use the created modules as dependencies for the bigger module with scope of compile maven would automatically add them to lib of the project.
So in your case you don't need to change packaging to pom and just add the modules as dependency in the pom.xml file and let maven to create the final jar for you.
Also if you want use pom packaging there is a good question here which might help you.
I went through this link to import a gradle project as dependency into another gradle project. Is there a way to include a maven project as dependency into a gradle project?
If that Maven project is built somewhere else and deployed to a Maven repository, you can specify the artifact it produces as a simple compile dependency. If this Maven project is somehow a subproject of a Gradle multi-project build, I suppose you could hack it to work by simply ignoring the Maven POM file and perhaps adding a build.gradle to that project.
To use the solution described on the link that you provided - both projects must be gradle and included in gradle settings. Therefore you can use project closure to compile and depend on the project without building it explicitly.
I am not aware of any way to do this with maven project. I understand you use some maven plugins that you dont want to rewrite in gradle as simply can not find any equivalents etc. Often had that problem.
In this scenario I would suggest to build maven project and depend on a built jar in your gradle project.
Otherwise you could probably amend sourcesets in your gradle project to include maven classes. But I think it would be to complicated.
If I would be you I would turn it into gradle and try to replicate what you had using maven or just build the artifact and depend on it in dependencies closure.
Gradle is not that new anymore and there are many plugins that are superseding old good maven stuff.
I have a legacy application that is written in Java and managed by Maven.
Recently I want to modify the code to make the application be able to run on a cluster of several machines. And I want to start with the akka-sample-cluster-scala template from activator, and the template is written in Scala and managed by SBT.
My question is: how can I merge the two projects together, so I can access my Java classes in the akka-sample-cluster-scala project or copy the code from akka-sample-cluster-scala project to my Java project and make it work.
Maven and SBT have completely independent sets of plugins but use the same Maven Central repository to download dependencies and the same directory conventions.
To play with samples in Maven project I would try to configure Scala Maven Plugin in your Maven build. This seems to be simpler. However if you wish to use SBT you need to:
Create an SBT project
Place you Java code to src/main/java or copy the entire multi-module structure if this code has multiple modules.
Copy dependencies to SBT build files.
Find plugin equivalents for SBT if they exist and configure them in SBT. Seems to be tricky, though...
Make the Maven project a library dependency of the SBT project.
resolvers += Resolver.mavenLocal
libraryDependencies += "com.originjing" %% "legacy-app" & "1.0.0"
Gradle/libgdx/Eclipse
Following Project Structure:
MainProject
-build.gradle
-settings.gradle
LibraryProject
-build.gradle
-settings.gradle
I can't seem to declare the dependency to the library correctly.
MainProject build.gradle
dependencies {
compile project(':LibraryProject')
}
MainProject settings.gradle
include ':LibraryProject'
project(':LibraryProject').projectDir = new File(settingsDir, '../LibraryProject')
Refreshing dependencies works without error. But I can't access any library classes.
It is not possible (in almost all cases) to reliably include a root project as a subproject of another multi-project build. You should not share subprojects between different Gradle builds.
There are two ways to solve this:
Change the dependency on :LibraryProject to a normal dependency: YourGroup:LibraryProject:1.0-SNAPSHOT. When you make changes to the library project, you first have to manually build the library project, and install it in a (local) repository. Then you can build the main project.
Make the library project an actual subproject of the main project.
What is best depends on the purpose of the library project. Is it a project to be reused by multiple applications? Then use the first approach. If it is specifically for the main project, then a subproject is better.
I have a project that generates some classes and resources that should then be packaged into a jar.
The class that does the generating has several dependencies. The generated classes have no dependencies.
My initial solution was to use the maven assembly plugin to only include the generated files. Unfortunately, the packaged pom includes all the dependencies required to do the generation. Consumers of this jar pull in a bunch of unnecessary dependencies.
I looked into the maven shade plugin. I compile once, run the generator class with mojo's exec plugin, the compile a final time. Then shade of course runs in the package phase. It creates a dependency-reduced-pom.xml without the excessive dependencies. So run mvn clean package and look in target/foo.jar. I expect the jar in the meta-inf folder to be the reduced dependency jar. But it's the full pom. I don't know how have the generated pom replace the one that is packaged.
Another poor solution I tried was using multiple profiles with their own dependency section. I run maven once with the generating profile, then again with the packaging profile. This works, but sucks because you have to run multiple maven commands. It's not jenkins friendly.
Am I going about this the wrong way? How should I go about arranging a project that generates some code and some text files that are then packaged in a maven friendly artifact?
1) One possibility is to make all your dependencies <optional>true</optional>.
The pom will still have the dependencies but the projects using your library won't try to download them.
2) Use plugin dependencies with the exec plugin.
That works well if the generator class is defined on another project.
Ideally you would call your generator using a plugin and avoid adding those dependencies to your project. That may not be worth doing depending on what your project is for and how reusable your generator has to be.
3) If you are using maven-shade-plugin the dependency-reduced-pom.xml is normally used. Check your .m2 repository to see the contents of the pom that is copied there when you do mvn install. It's likely that its contents will match the dependency-reduced-pom.xml