I have a 3 maven projects with different groupIds/ArtifactIDs. Project A has depedencies on projects B and C. and I'm using maven-failsafe-plugin in order to run B's and C's integration tests from A during build:
(In project A) :
<dependency>
<groupId>com.group.b</groupId>
<artifactId>artifactB</artifactId>
</dependency>
<dependency>
<groupId>com.group.c</groupId>
<artifactId>artifactC</artifactId>
</dependency>
But for some reason, when I run this line in Project C -
URL path = ThisClass.class.getResource("/someResource");
It gives me the jar location of Project B, as in the classloader is in projectB
Both B and C have a resource directory called /someResource and thats why its failing. When I do the same call but to a resource that exists ONLY in C, then the class loader is correct:
(Code written in Project C)
URL path1 = SomeClass.class.getResource("/directory1");
System.out.println(pathA.getPath()); // .m2/../ProjectB.jar!/directory1
URL path2 = SomeClass.class.getResource("/directory2");
System.out.println(pathB.getPath()); // .m2/../ProjectC.jar!/directory2
Since directory1 exists in B and C, then A gives me B's class loader (the first depedency), and when its a directory that exists only in C, then I get the correct class loader
If I comment out the dependency to B, then all works good.
I've also added <useSystemClassLoader>false</useSystemClassLoader> to maven-failsafe and that didn't help
I've also tried <useManifestOnlyJar>false</useManifestOnlyJar> which didn't change anything
======UPDATE=======
If anyone has a suggestion as to how I can run test jars externally (jenkins, maven, doesn't matter) without having their class loader mixed up
Related
I have two modules, A and B, they are under the same parent. Now A is requiring for B as dependency. I can't just use jar as dependency type because module B is using spring-boot-maven-plugin, so I was wondering how can I set A's pom configuration to make A depend on B's compiled classes not jar?
- root
- A
- src # module A's source code
- target
- classes # module A's compiled classes
- A.jar # module A's compiled jar output
- pom.xml # module A's mvn config
- B
- src # module B's source code
- target
- classes # module B's compiled classes, HOW CAN I IMPORT THESE TO A?
- B.jar # module B's mvn config
- pom.xml # module B's mvn config
- pom.xml # parent mvn config
parent mvn config
...
<modules>
<module>A</module>
<module>B</module>
</modules>
...
module A mvn config
...
<parent>
<!- pointed to parent ->
</parent>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>B</artifactId>
<scope>??????????????</scope> # WHAT SHOULD I PUT HERE?
<type>???????????????</type> # WHAT SHOULD I PUT HERE?
</dependency>
<dependencies>
...
First of all: When A depends on the classes of some other module, it necessarily depends on the jar. You cannot depend on parts of a module or just the classes.
So let me sketch a solution:
If B is of <packaging>jar</packaging> (standard, also true if no packaging is given), then you can just use it as dependency. You do not need a scope or type entry.
If B is of some other packaging (including spring-defined packaging types, which I am no expert of), then you should not define a dependency from A on B. Instead, you define a third module C, which includes the classes that are used from A and from B and let both of them have a dependency on C.
Don't try to construct dependencies to non-jars. If you need classes, define a module with these classes and use it when the classes are needed.
Here is good information about maven dependency scope and type.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
This should work fine for you. (Not tested)
<scope>compile</scope>
<type>jar</type>
I have added two projects as modules in empty intellij project.
Then I added in pom of module B following dependency to first project(module A):
<dependency>
<groupId>Tests</groupId>
<artifactId>Group</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
This allows me to import classes from module A into module B.
But I can't see any method from that module (it looks like classes are empty or they have only private fields/methods).
What am I missing? What should I do to see all public methods/fields from A module?
Thanks
Kamil
If you are adding one of them as a dependency, you can avoid to join them as modules. For local purposes, you can build(mvn clean package) one of them and add that as a dependency to another one. You can check relevant .class file to see the access levels of the class members.
For multi-module projects, please, see: https://www.jetbrains.com/help/idea/creating-and-managing-modules.html
I have a multi module maven project, and in the dao module, I added the JSON-IO dependency. When I try to deserialize my object, it gives me:
Exception in thread "main" com.cedarsoftware.util.io.JsonIoException: Class listed in #type [hu.kleatech.projekt.model.Employee] is not found
The class name is correct, the Employee is public, and the dao has the module as dependency. What could have gone wrong?
Edit: Since this is an old question and have been answered long ago, I'm deleting the github repository that I made specifically for this question. The solution to the problem is in the accepted answer, the exact code is not relevant.
Please try adding an empty constructor to Employee class.
Edit: Actually, while adding an empty constructor solves the problem, it is not necessarily required. Json-IO "will make a valiant effort to instantiate passed in Class, including calling all of its constructors until successful. The order they tried are public with the fewest arguments first to private with the most arguments."
(copied from MetaUtils.java javadoc)
Also, when calling a multi-argument constructor, the library fills the arguments with nulls and defaults for primitives. Then any exceptions thrown during the constructor call is ignored. In your case, a NullPointerException was thrown, because the constructor is not null-safe. So either modify the constructor so that it can handle nulls, or add an empty constructor.
Maven dependency configuration is hierarchical from <parent> element not from <modules> element.
It means that in the project's pom.xml file where you have dependency on "JSON-IO dependency" you do not have dependency on your dao project or where that class is.
<modules> stands only to define what projects to build. Order of modules definition does not matter, since Maven detects order by required dependencies
So, you can define dependency in <parent> pom.xml either in
<dependencies> element. then all children will have it.
or in <dependencyManagement> - then children who need it can include it in their <dependencies> without common configurations like version, scope etc...
look at quite similar answer here:
How to minimize maven pom.xml
As per your project and modules Pom your main Pom should have modules in following order ....
<modules>
<module>core</module>
<module>controller</module>
<module>service</module>
<module>dao</module>
</modules>
service depends on core so core should be build before service
dao depends on service and core both so dao should be after core and service.
Employee class is available in core and it should be available in core jar.
You should add depencyManagent in main Pom and then add all the module as dependencies in dependencyManagement so whoever adds your main Pom as dependency will be able to access all your jars.
Once you change order build your project again and then update your maven project.
If this code is being used in another project then make sure that you have uploaded jars to repository (mvn deploy) so whoever uses it can download it when they are building their project.
One way to verify whether this jar is downloaded in the main project where it is used or not is check in project explorer there would be a Maven Dependencies section where you can see all dependency jars and check if core is present or not.
I am not sure what controller module is doing in main Pom as I couldn’t find a module by that name in your project so you should either remove it or add a module (folder) for it.
I have two modules, A and B, they are under the same parent. Now A is requiring for B as dependency. I can't just use jar as dependency type because module B is using spring-boot-maven-plugin, so I was wondering how can I set A's pom configuration to make A depend on B's compiled classes not jar?
- root
- A
- src # module A's source code
- target
- classes # module A's compiled classes
- A.jar # module A's compiled jar output
- pom.xml # module A's mvn config
- B
- src # module B's source code
- target
- classes # module B's compiled classes, HOW CAN I IMPORT THESE TO A?
- B.jar # module B's mvn config
- pom.xml # module B's mvn config
- pom.xml # parent mvn config
parent mvn config
...
<modules>
<module>A</module>
<module>B</module>
</modules>
...
module A mvn config
...
<parent>
<!- pointed to parent ->
</parent>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>B</artifactId>
<scope>??????????????</scope> # WHAT SHOULD I PUT HERE?
<type>???????????????</type> # WHAT SHOULD I PUT HERE?
</dependency>
<dependencies>
...
First of all: When A depends on the classes of some other module, it necessarily depends on the jar. You cannot depend on parts of a module or just the classes.
So let me sketch a solution:
If B is of <packaging>jar</packaging> (standard, also true if no packaging is given), then you can just use it as dependency. You do not need a scope or type entry.
If B is of some other packaging (including spring-defined packaging types, which I am no expert of), then you should not define a dependency from A on B. Instead, you define a third module C, which includes the classes that are used from A and from B and let both of them have a dependency on C.
Don't try to construct dependencies to non-jars. If you need classes, define a module with these classes and use it when the classes are needed.
Here is good information about maven dependency scope and type.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
This should work fine for you. (Not tested)
<scope>compile</scope>
<type>jar</type>
I've created small util to wrap MavenCli, which generates a new Maven project, using the quickstart archetype.
When executing the Util as a unit test, it is working quite well (just generating an empty Maven project).
Now I want to integrate this small wrapper into a Maven plugin. But when I execute the mojo (within a third Maven project), the invocation of MavenCli fails with exception:
[ERROR] Error executing Maven.
[ERROR] java.util.NoSuchElementException
role: org.apache.maven.eventspy.internal.EventSpyDispatcher
roleHint:
[ERROR] Caused by: null
The util looks like:
public void createProject() {
final MavenCli cli = new MavenCli();
System.setProperty("maven.multiModuleProjectDirectory", "/usr/share/maven");
cli.doMain(new String[] { "archetype:generate", "-DgroupId=com.my.company",
"-DartifactId=hello-world", "-DarchetypeArtifactId=maven-archetype-quickstart",
"-DinteractiveMode=false" }, "/tmp", System.out, System.out);
}
relevant dependency of the util:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>3.3.9</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<version>3.3.9</version>
</dependency>
The mojo code looks like:
#Mojo(name = "custommojo", requiresProject = false)
public class CustomMojo extends AbstractMojo {
#Override
public void execute() throws MojoExecutionException, MojoFailureException {
Util.createProject();
}
}
The POM of the mojo just includes dependencies to relevant Maven artifacts (plugin-api, plugin-annotation, etc.) and the util.
The third project I mentioned, is an empty "maven-quickstart" project which have dependency to the mojo-project and a configuration for the mojo to execute in compile phase.
I have no idea why it works in context of unit test, but not in context of a mojo.
Can anybody help?
This is a class loading issue.
MavenCli will try to load classes from the context classloader of the current thread. Inside of a Maven plugin, there is a special, restricted, classloader, which has access to:
its own classes;
the classes used in its dependencies block;
exported classes as part of a possible build extension of the project;
exported classes from the Maven core and core extensions;
and has the bootstrap classloader as parent.
However, the specific class org.apache.maven.eventspy.internal.EventSpyDispatcher is part of Maven core, but it is not part of the exported APIs (the package org.apache.maven.eventspy is not listed as an exportedPackage). So the plugin cannot load that class. This is also why it works in your tests: you're not inside of a plugin, so the classloader is different and has access to that class.
You won't even be able to get away with adding explictly a dependency on maven-core for the plugin: it will be disgarded since it is supposedly already provided.
There are 2 solutions here:
Don't use the Maven Embedder API from within a plugin, but the Invoker API. The difference between the two is that the Invoker API will launch Maven in a clean environment, completely distinct with regard to the current one. Since it starts everything anew, you won't have any classloading issue.
Use the mojo-executor library, that provides an easy way to invoke other Mojos from within a Maven plugin. You could use it here to invoke the archetype:generate Mojo.
This works for me inside a custom maven plugin (using Maven 3.5.0):
ClassRealm classRealm = (ClassRealm) Thread.currentThread().getContextClassLoader();
MavenCli cli = new MavenCli(classRealm.getWorld());
cli.doMain( ... );
The plexus Launcher sets the context class loader to its ClassRealm, which has access to the "global" ClassWorld.
Not sure how stable that solution is, but so far looking good.
Used imports:
import org.codehaus.plexus.classworlds.ClassWorld;
import org.codehaus.plexus.classworlds.realm.ClassRealm;
import org.apache.maven.cli.MavenCli;
#Alexander:
You answer put me in the right direction, I was getting the mentioned error when trying to run to doMain maven commands subsequently (one command would succeed).
However your code gives me a ClassCast exception :
Exception in thread "main" java.lang.ClassCastException: sun.misc.Launcher$AppClassLoader cannot be cast to org.codehaus.plexus.classworlds.realm.ClassRealm
at com.misys.tools.integration.codegen.cli.cmd.InstallApi.mavenInstallMchApi(InstallApi.java:58)
at com.misys.tools.integration.codegen.cli.cmd.InstallApi.run(InstallApi.java:50)
at com.misys.tools.integration.codegen.cli.OpenApiGen.main(OpenApiGen.java:26)
I managed to rewrite the code to:
MavenCli cli = new MavenCli(new ClassWorld("maven",Thread.currentThread().getContextClassLoader()));
And then 2 subsequent doMain invocations of embedded maven succeed!