Classloader issues
Hi there, I have the following maven project setup: master | module1 | class ClassA (has annotation @Annotation) | module2 | class ClassB (also has annotation @Annotation) and I'm building it with maven, and I use an AbstractProcessor during compilation to find all types annotated with @Annotation. When I build it from the module1 level it all works fine. The problem appears when I build it from master level. Then, what happens is I get an exception that class B cannot be found. Caused by: org.reflections.ReflectionsException: could not get type for name ClassB at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:389) at org.reflections.ReflectionUtils.forNames(ReflectionUtils.java:398) at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:385) at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:370) Here's how I find the types annotated with @Annotation: final Reflections reflections = new Reflections(new ConfigurationBuilder().setUrls(ClasspathHelper.forClassLoader(ClasspathHelper.staticClassLoader())).setScanners( new TypeAnnotationsScanner(), new SubTypesScanner())); return reflections.getTypesAnnotatedWith(Annotation.class); What happens is that the classloader will find all the jars in my pom.xml AND also the following url: /home/petar/workspace/master/./ and then it will be given to Reflections (method scan on line 235 in Reflections class ) where it will be treated as a SystemDir so reflections will recursively go thorough all the subfolders and add all the classes it finds (which also includes module2/target/classes/ClassB.class). Then it will try to load it and it will produce the error I pasted above. Now i'm not sure who's passing the master folder to the classpath, but I checked the maven classpath with -X and I don't see this folder coming from maven. Any idea who's adding this folder in the classpath, and also how can I disable adding it? Thanks a lot. -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
Musing about ClassLoader issues in plugins/reports.
There are a number of issues within JIRA that are the result of Resource access issues. They way I see it, we have 4 different resource access issues when dealing with plugins/reports. 1) resources from dependency in parent pom. 2) resources from transitive dependency. 3) resources from plugin/dependencies/dependency. 4) resources due to dependencyManagement. We need to be able to address all of these access vectors from 5 different paths. 1) Direct mojo:goal usage. 2) Configured mojo:goal in project pom. 3) Configured mojo:goal in parent pom. 4) Configured report in project pom. 5) Configured report in parent pom. Would it be wise to create a maven-core-it project (or similar for reporting) to cover all of these scenarios? /* joakim */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Musing about ClassLoader issues in plugins/reports.
Sounds like a great idea! They should all go in maven-core-it (possibly as multiple projects). This is really the integration testing of the Maven distribution, not just the maven-core library. - Brett Joakim Erdfelt wrote: There are a number of issues within JIRA that are the result of Resource access issues. They way I see it, we have 4 different resource access issues when dealing with plugins/reports. 1) resources from dependency in parent pom. 2) resources from transitive dependency. 3) resources from plugin/dependencies/dependency. 4) resources due to dependencyManagement. We need to be able to address all of these access vectors from 5 different paths. 1) Direct mojo:goal usage. 2) Configured mojo:goal in project pom. 3) Configured mojo:goal in parent pom. 4) Configured report in project pom. 5) Configured report in parent pom. Would it be wise to create a maven-core-it project (or similar for reporting) to cover all of these scenarios? /* joakim */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Surefire classloader issues (?)
From: Brett Porter [EMAIL PROTECTED] What forking are you using in m1/ant? None. Or rather, whatever the default is-- I have nothing in project.properties that says otherwise. Likewise, nothing special in the surefire configuration in pom.xml, so I'm using the defaults there, too. I've tracked the difference down to the fact that with m1/Ant, you get a new AntClassLoader for each test case, while with Surefire, you keep the same IsolatedClassLoader throughout the tests. I don't _think_ I'm forking a new JVM because I'm able to step through the entire set of tests in JSwat (debugger) in both m1 and m2. Suggestions? Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Surefire classloader issues (?)
(resending from the right address...) From: Brett Porter [EMAIL PROTECTED] What forking are you using in m1/ant? None. Or rather, whatever the default is-- I have nothing in project.properties that says otherwise. Likewise, nothing special in the surefire configuration in pom.xml, so I'm using the defaults there, too. I've tracked the difference down to the fact that with m1/Ant, you get a new AntClassLoader for each test case, while with Surefire, you keep the same IsolatedClassLoader throughout the tests. I don't _think_ I'm forking a new JVM because I'm able to step through the entire set of tests in JSwat (debugger) in both m1 and m2. Suggestions? Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Surefire classloader issues (?)
ok. I'm not sure whether recreating the classloader for each test is really necessary though, but we can look into it. Is this something you can correct by some appropriate commands in tearDown() ? It seems that would be more robust across test runners (I'm not sure how IDEs handle your tests, for example). - Brett Wendy Smoak wrote: (resending from the right address...) From: Brett Porter [EMAIL PROTECTED] What forking are you using in m1/ant? None. Or rather, whatever the default is-- I have nothing in project.properties that says otherwise. Likewise, nothing special in the surefire configuration in pom.xml, so I'm using the defaults there, too. I've tracked the difference down to the fact that with m1/Ant, you get a new AntClassLoader for each test case, while with Surefire, you keep the same IsolatedClassLoader throughout the tests. I don't _think_ I'm forking a new JVM because I'm able to step through the entire set of tests in JSwat (debugger) in both m1 and m2. Suggestions? Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Surefire classloader issues (?)
From: Brett Porter [EMAIL PROTECTED] ok. I'm not sure whether recreating the classloader for each test is really necessary though, but we can look into it. I'm not sure it's necessary either-- but it is different from the way it worked in m1, so it's worth noting. Is this something you can correct by some appropriate commands in tearDown() ? It seems that would be more robust across test runners (I'm not sure how IDEs handle your tests, for example). Yes, now that I understand the situation a little better I'll fix the tests. Thanks for your help! -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
