Re: how to tell if a packaging is classpath
Hi Benson,
Benson Margulies wrote:
In the jxr plugin, I see:
if ( !pom.equals( getProject().getPackaging().toLowerCase() ) )
{
l.addAll( sourceDirs );
}
This can't be good, can it? Isn't there some way to tell what are the
classpath packagings?
Why is it doing this at all? Isn't the existing of src/main/java enough? I
can build empty jars (resp. jars with only resources), I may use pom and
build an attached jar with Java sources, ...
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Jira rights for Robert
Hi Robert, There is a problem of sync (I think) between xircles and Jira. I just added you manually in maven-developers group in Jira and I opened an issue on codehaus side (http://jira.codehaus.org/browse/HAUS-2099) Welcome Arnaud
Re: Jira rights for Robert
2011/7/11 Arnaud Héritier aherit...@gmail.com: Hi Robert, There is a problem of sync (I think) between xircles and Jira. I just added you manually in maven-developers group in Jira and I opened an issue on codehaus side (http://jira.codehaus.org/browse/HAUS-2099) I'm happy to use http://issues.apache.org if that would make things easier... Welcome :-) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 72 hours, two binding votes, now what?
On Sun, Jul 10, 2011 at 11:43 PM, Wendy Smoak wsm...@gmail.com wrote: On Sun, Jul 10, 2011 at 1:58 PM, Benson Margulies bimargul...@gmail.com wrote: The vote on wagon only attracted two binding +1 votes. Now what? A new vote, since this one is formally closed? The 72 hour waiting time is a minimum, you can certainly let it go longer (especially when it runs over a weekend when people may not be paying attention.) +1 One little trick I picked up is to promise to say something like I'll tally the vote no earlier than 1800UTC Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Dependency Plugin 2.3 Released
The Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.3 This plugin is used to copy and unpack artifacts and dependencies. It also provides visualization and optimization tools for your project dependencies. http://maven.apache.org/plugins/maven-dependency-plugin/ The main change in this plugin from version 2.2 is that the copy and unpack goals will now resolve from the reactor in Maven 2.x. Initially when these goals were added to the dependency plugin, they did not resolve artifacts from the reactor. With Maven 3, however, the plugin would resolve artifacts from the reactor. The fix for MDEP-316 ensures that there is consistent behaviour when running with both Maven 2.x and Maven 3 by having the copy and unpack goals alway search for artifacts from the reactor before failing through to the local, and subsequently remote repositories. The side-effect of this is that some builds which may have been forced to set the release plugin's preparationGoals to clean install in order to be able to release, will now be able to revert to the preferred clean verify. You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.3/version /plugin Release Notes - Maven 2.x Dependency Plugin - Version 2.3 ** Bug * [MDEP-316] - dependency:copy and dependency:unpack behave differently with M2 and M3 (should always search the reactor for artifacts) ** Improvement * [MDEP-145] - Outputting dependency resolution/tree in a well known _machine readable_ output format * [MDEP-265] - Add classifier option for dependency:get * [MDEP-315] - Add pt_BR localization Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jira rights for Robert
On Mon, Jul 11, 2011 at 9:47 AM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: 2011/7/11 Arnaud Héritier aherit...@gmail.com: Hi Robert, There is a problem of sync (I think) between xircles and Jira. I just added you manually in maven-developers group in Jira and I opened an issue on codehaus side (http://jira.codehaus.org/browse/HAUS-2099) I'm happy to use http://issues.apache.org if that would make things easier... Ben fixed the issue 5 min after I opened it :-) Someone is working on such migration I think but it won't be easy due to the number of projects and the set of customizations we mage in codehaus instance Welcome :-) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: how to tell if a packaging is classpath
Why is it doing this at all? Jörg, Honestly, I have no idea -- I just happened to spot it on the way by. And when I thought some more, I realized that my question is mis-stated. The issue here isn't classpath, it's more related to yours: What's the configured java src directory, and is there anything in it? Isn't the existing of src/main/java enough? I can build empty jars (resp. jars with only resources), I may use pom and build an attached jar with Java sources, ... - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: how to tell if a packaging is classpath
http://mojo.codehaus.org/build-helper-maven-plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67 Don't limit yourself to just one directory... And then if this is not a Java based project, those directories might be not holding .java files... On 11 July 2011 12:04, Benson Margulies bimargul...@gmail.com wrote: Why is it doing this at all? Jörg, Honestly, I have no idea -- I just happened to spot it on the way by. And when I thought some more, I realized that my question is mis-stated. The issue here isn't classpath, it's more related to yours: What's the configured java src directory, and is there anything in it? Isn't the existing of src/main/java enough? I can build empty jars (resp. jars with only resources), I may use pom and build an attached jar with Java sources, ... - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: how to tell if a packaging is classpath
Stephen Connolly wrote: http://mojo.codehaus.org/build-helper-maven- plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67 Don't limit yourself to just one directory... Yeah, but this raises the question, if a JXR report over generated Java sources is actually wanted. And then if this is not a Java based project, those directories might be not holding .java files... No Java source - no report :) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: how to tell if a packaging is classpath
On 11 July 2011 12:37, Jörg Schaible joerg.schai...@scalaris.com wrote: Stephen Connolly wrote: http://mojo.codehaus.org/build-helper-maven- plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67 Don't limit yourself to just one directory... Yeah, but this raises the question, if a JXR report over generated Java sources is actually wanted. Hell yes. If I want to see the source I don't want to spend hours trying to wonder why I cannot see the XYZ file's source anywhere only to find that its generated source... And then if this is not a Java based project, those directories might be not holding .java files... No Java source - no report :) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Getting integration tests into eclipse
Anyone got a trick for getting integration tests, complete with @'s, into eclipse? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Getting integration tests into eclipse
use intellij? On 11 July 2011 14:19, Benson Margulies bimargul...@gmail.com wrote: Anyone got a trick for getting integration tests, complete with @'s, into eclipse? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Trying to address JXR-84, in world of hurt with plugin test harness
Trying to get velocity 1.5 into here. I started by changing the dep in maven-jxr. That led to strange errors suggesting crossed versions of velocity. So I tried to upgrade the version of the doxia-site-renderer. And now I'm really confused. Anybody recognize the below? --- T E S T S --- Running org.apache.maven.plugin.jxr.JxrReportTest - this realm = plexus.core Number of imports: 0 - --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.056 sec FAILURE! Results : Tests in error: testDefaultConfiguration(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testPom(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testNoJavadocLink(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testAggregate(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testNoJavadocDir(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testExclude(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testInclude(org.apache.maven.plugin.jxr.JxrReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:jxr', it could not be started testSourceDir(org.apache.maven.plugin.jxr.JxrTestReportTest): Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-jxr-plugin:2.3-SNAPSHOT:test-jxr', it could not be started Tests run: 9, Failures: 0, Errors: 8, Skipped: 0 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
Yeah it took me two days of that pain to get m-dependency-p to a state where I could release it On 11 July 2011 15:52, Benson Margulies bimargul...@gmail.com wrote: I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
not with doxia but with other classes... not happy with that test harness at all On 11 July 2011 16:10, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah it took me two days of that pain to get m-dependency-p to a state where I could release it On 11 July 2011 15:52, Benson Margulies bimargul...@gmail.com wrote: I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
More trouble with classpaths and velocity
Dependency:tree on my dev tree for the maven-jxr-plugin shows precisely one copy of velocity 1.5: org.apache.velocity:velocity:jar:1.5:compile. Any yet I'm stuck on the following in the integration tests, which seems pretty strongly to indicate more than one copy in more than one classloader. Embedded error: Error rendering Maven report: error while invoking generate The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. [INFO] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: More trouble with classpaths and velocity
If you are running m3 then dependency:tree may be incorrect. On 11 July 2011 16:35, Benson Margulies bimargul...@gmail.com wrote: Dependency:tree on my dev tree for the maven-jxr-plugin shows precisely one copy of velocity 1.5: org.apache.velocity:velocity:jar:1.5:compile. Any yet I'm stuck on the following in the integration tests, which seems pretty strongly to indicate more than one copy in more than one classloader. Embedded error: Error rendering Maven report: error while invoking generate The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. [INFO] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: More trouble with classpaths and velocity
Nope, I'm giving m3 a wide berth while I'm working on plugins. On Mon, Jul 11, 2011 at 11:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If you are running m3 then dependency:tree may be incorrect. On 11 July 2011 16:35, Benson Margulies bimargul...@gmail.com wrote: Dependency:tree on my dev tree for the maven-jxr-plugin shows precisely one copy of velocity 1.5: org.apache.velocity:velocity:jar:1.5:compile. Any yet I'm stuck on the following in the integration tests, which seems pretty strongly to indicate more than one copy in more than one classloader. Embedded error: Error rendering Maven report: error while invoking generate The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. [INFO] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Getting integration tests into eclipse
Depends on what your running them with. Testng test groups? I modify them with an @Listener, it servers multiple purposes for us. First it makes sure there are no misspelled groups, then if eclipse-testng jar is on the classpath, it runs all groups, ignoring the group configuration. We also us it to server other purposes, like maintaining a pool of webdriver instances, as most the time spent in a webdriver test is startup and shutdown of the browser. Rex On Mon, Jul 11, 2011 at 6:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use intellij? On 11 July 2011 14:19, Benson Margulies bimargul...@gmail.com wrote: Anyone got a trick for getting integration tests, complete with @'s, into eclipse? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Getting integration tests into eclipse
the @'s in question are resource substitution @'s used by the maven-invoker-plugin. On Mon, Jul 11, 2011 at 12:01 PM, Rex Hoffman r...@e-hoffman.org wrote: Depends on what your running them with. Testng test groups? I modify them with an @Listener, it servers multiple purposes for us. First it makes sure there are no misspelled groups, then if eclipse-testng jar is on the classpath, it runs all groups, ignoring the group configuration. We also us it to server other purposes, like maintaining a pool of webdriver instances, as most the time spent in a webdriver test is startup and shutdown of the browser. Rex On Mon, Jul 11, 2011 at 6:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use intellij? On 11 July 2011 14:19, Benson Margulies bimargul...@gmail.com wrote: Anyone got a trick for getting integration tests, complete with @'s, into eclipse? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Getting integration tests into eclipse
*you're On Mon, Jul 11, 2011 at 9:01 AM, Rex Hoffman r...@e-hoffman.org wrote: Depends on what your running them with. Testng test groups? I modify them with an @Listener, it servers multiple purposes for us. First it makes sure there are no misspelled groups, then if eclipse-testng jar is on the classpath, it runs all groups, ignoring the group configuration. We also us it to server other purposes, like maintaining a pool of webdriver instances, as most the time spent in a webdriver test is startup and shutdown of the browser. Rex On Mon, Jul 11, 2011 at 6:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use intellij? On 11 July 2011 14:19, Benson Margulies bimargul...@gmail.com wrote: Anyone got a trick for getting integration tests, complete with @'s, into eclipse? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Jira rights for Robert
yep, this looks much better now. Thanks for the time to resolve this. -Robert From: aherit...@gmail.com Date: Mon, 11 Jul 2011 10:21:29 +0200 Subject: Re: Jira rights for Robert To: dev@maven.apache.org On Mon, Jul 11, 2011 at 9:47 AM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: 2011/7/11 Arnaud Héritier aherit...@gmail.com: Hi Robert, There is a problem of sync (I think) between xircles and Jira. I just added you manually in maven-developers group in Jira and I opened an issue on codehaus side (http://jira.codehaus.org/browse/HAUS-2099) I'm happy to use http://issues.apache.org if that would make things easier... Ben fixed the issue 5 min after I opened it :-) Someone is working on such migration I think but it won't be easy due to the number of projects and the set of customizations we mage in codehaus instance Welcome :-) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
SinkEventAttributes was added in Doxia-1.1, so there is apparently a mixup with some some plugin/component that uses the old doxia-1.0. Not sure it helps, but here are some notes about upgrading from doxia-1.0 to 1.1: http://maven.apache.org/doxia/whatsnew-1.1.html http://maven.apache.org/doxia/developers/maven-integration.html HTH, -Lukas Benson Margulies wrote: I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
Lukas, Thanks, I'm past that. Now I'm stalled on Velocity itself pitching fits. I fear that plexus-velocity versus jxr is a muddle. --benson On Mon, Jul 11, 2011 at 1:36 PM, Lukas Theussl ltheu...@apache.org wrote: SinkEventAttributes was added in Doxia-1.1, so there is apparently a mixup with some some plugin/component that uses the old doxia-1.0. Not sure it helps, but here are some notes about upgrading from doxia-1.0 to 1.1: http://maven.apache.org/doxia/whatsnew-1.1.html http://maven.apache.org/doxia/developers/maven-integration.html HTH, -Lukas Benson Margulies wrote: I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JXR jenkins job
I think this job needs some help: https://builds.apache.org/job/maven-jxr/6/console - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
What is the principle of the tccl (thread context class loader) in maven?
The maven-jxr-plugin uses doxia-site-renderer. This, in turn, uses plexus-velocity, which in turn uses velocity version 1.5. So, you would think that it would be a piece of cake to make JXR use the same thing. But I got errors indicating that velocity was ending up with a class loader straddle and two copies of a critical interface in two class loaders. And, indeed, a bit of poking around, shows that (a) Velocity uses the thread context class loader to load the resource manager, and (b) that was set to some Realm or another, but not the one into which the plugin itself had been loaded. So, when Velocity explicitly asked to load the resource manager class into the tccl, it ended up with a second copy. So, I wrapped the call from the plugin into JXR itself in a try/finally to set and restore the tccl, and things worked. Is there something I'm missing? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
