[jira] Commented: (SUREFIRE-313) build fails with ClassNotFoundException, BUT the class IS there!
[
http://jira.codehaus.org/browse/SUREFIRE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106860
]
Anders Hammar commented on SUREFIRE-313:
The problem is how the URLs for the class loader are being encoded. This is
done in {{org.apache.maven.surefire.util.UrlUtils.getURL(File)}}.
If that method is changed into the one below it works for me (using a path for
my maven project that includes non plain English chars):
{code:title=UrlUtils.java|borderStyle=solid}
...
public static URL getURL( File file )
throws MalformedURLException
{
// encode any characters that do not comply with RFC 2396
// this is primarily to handle Windows where the user's home directory
contains spaces,
// but also to handle non plain English characters
URI uri = file.toURI();
return uri.toURL();
}
{code}
I'm not familiar with creating patch files. Anyone who can help me?
Also, a complete list of other plugins with the same problem would be great so
that the same fix could be submitted for those.
> build fails with ClassNotFoundException, BUT the class IS there!
>
>
> Key: SUREFIRE-313
> URL: http://jira.codehaus.org/browse/SUREFIRE-313
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, Junit 4.x support
>Affects Versions: 2.3
> Environment: Windows XP SP2, Java SE 6, Maven 2.0.5
>Reporter: Ivan Mikushin
> Fix For: 2.4
>
> Attachments: mvn-junit4.log, mvn-pojo-test.log, pom.xml
>
>
> JUnit 4 and POJO tests give ClassNotFoundException exceptions in *test* phase
> of the build (pom.xml is attached).
> The console output gives a hint: JUnit 3.8.1 is appended to the
> surefire-booter forked JVM classpath instead of JUnit 4 (I tried it with
> junit-4.0, 4.1 and 4.2). When I try a POJO test case I get the same error.
> Also attached are the outputs from the command lines for JUnit4 and POJO test
> cases
> {{mvn -X clean test > mvn.log}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2788) Anchor tags on POM amd Settings reference pages are broken in Firefox
[ http://jira.codehaus.org/browse/MNG-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106863 ] Dennis Lundberg commented on MNG-2788: -- Fixed in svn. Still need to deploy the site. > Anchor tags on POM amd Settings reference pages are broken in Firefox > - > > Key: MNG-2788 > URL: http://jira.codehaus.org/browse/MNG-2788 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: General >Affects Versions: 2.0.4 > Environment: Firefox 2.0.0.1 on Windows XP SP2. >Reporter: Ryan Breidenbach >Assignee: Dennis Lundberg >Priority: Trivial > Fix For: Documentation Deficit > > Attachments: pom.html.diff > > > The TOC anchors at the top of the POM and Settings Reference pages do not > work in Firefox. It appears that all of the anchor links are capitalized > while the anchor labels are all lower case. Also, some of the links contain > spaces while the labels contain underscores. This is causing the links to > fail in Firefox. > http://maven.apache.org/pom.html > http://maven.apache.org/settings.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3074) Anchor links in several documentations do not work
[ http://jira.codehaus.org/browse/MNG-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106862 ] Dennis Lundberg commented on MNG-3074: -- Fixed in svn. Still need to deploy the site. > Anchor links in several documentations do not work > -- > > Key: MNG-3074 > URL: http://jira.codehaus.org/browse/MNG-3074 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: General >Reporter: Rick Janda >Assignee: Dennis Lundberg >Priority: Minor > > In the online documentation User Centre, the anchor links from the table of > contents at the beginning of the Settings Reference and the POM Reference do > not work at all. Also the anchor links to the different sections at the > beginning of the Getting Started Guide do not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1712) java exchange connector (jec-1.53_12.jar) - correction
java exchange connector (jec-1.53_12.jar) - correction -- Key: MAVENUPLOAD-1712 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1712 Project: maven-upload-requests Issue Type: Wish Reporter: eli hasson new JEC version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3200) Add support for -DremoteRepositories property to maven command
Add support for -DremoteRepositories property to maven command --- Key: MNG-3200 URL: http://jira.codehaus.org/browse/MNG-3200 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.7 Reporter: Farrukh Najmi Currently there is no way to specify to mvn command line to pickup additional remote repositories. It is desirable to add support for this in mvn command line similar to how it is supported in maven-archetype-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MJAVADOC-145) If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[ http://jira.codehaus.org/browse/MJAVADOC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MNG-3167 to MJAVADOC-145: - Affects Version/s: (was: 2.0.7) 2.3 Key: MJAVADOC-145 (was: MNG-3167) Project: Maven 2.x Javadoc Plugin (was: Maven 2) > If Javadoc is set to aggregate, the build fails inside a Maven plugin module > > > Key: MJAVADOC-145 > URL: http://jira.codehaus.org/browse/MJAVADOC-145 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Howard M. Lewis Ship >Priority: Critical > Attachments: ComponentReport.java, maven.out, pom.xml, pom.xml > > > If your project contains a Maven plugin, then it is impossible to build > aggregated Javadoc. > As the output (attached) shows, Maven seems to recusively build (what's with > all those "skipping" messages?). When it reaches the plugin: > [INFO] Error during page generation > Embedded error: Error rendering Maven report: Error extracting plugin > descriptor: 'Goal: component-report already exists in the plugin descriptor > for prefix: tapestry-component-report > Existing implementation is: org.apache.tapestry.mojo.ComponentReport > Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport' > I can get by this with the -fn (fail never) option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-145) If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[ http://jira.codehaus.org/browse/MJAVADOC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106865 ] Lukas Theussl commented on MJAVADOC-145: This seems to be a regression. We just had the same problem in doxia [1], it works with v 2.2. [1] http://www.nabble.com/can%27t-build-site-tf4408106s177.html > If Javadoc is set to aggregate, the build fails inside a Maven plugin module > > > Key: MJAVADOC-145 > URL: http://jira.codehaus.org/browse/MJAVADOC-145 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Howard M. Lewis Ship >Priority: Critical > Attachments: ComponentReport.java, maven.out, pom.xml, pom.xml > > > If your project contains a Maven plugin, then it is impossible to build > aggregated Javadoc. > As the output (attached) shows, Maven seems to recusively build (what's with > all those "skipping" messages?). When it reaches the plugin: > [INFO] Error during page generation > Embedded error: Error rendering Maven report: Error extracting plugin > descriptor: 'Goal: component-report already exists in the plugin descriptor > for prefix: tapestry-component-report > Existing implementation is: org.apache.tapestry.mojo.ComponentReport > Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport' > I can get by this with the -fn (fail never) option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106876 ] Brian Jackson commented on MASSEMBLY-64: Anyone else that just wants to know how to customize the jar-with-dependencies descriptor to fix this problem (like I did) here's what you need: jar-with-dependencies jar false true runtime **/META-INF/*.RSA **/META-INF/*.DSA **/META-INF/*.SF **/META-INF/*.rsa **/META-INF/*.dsa **/META-INF/*.sf target/classes > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Geoffrey De Smet >Assignee: Allan Ramirez > Fix For: 2.1 > > Attachments: MASSEMBLY-64-maven-assembly-plugin.patch > > Original Estimate: 5 hours > Time Spent: 1 hour, 30 minutes > Remaining Estimate: 3 hours, 30 minutes > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106876 ] Brian Jackson edited comment on MASSEMBLY-64 at 9/9/07 11:40 AM: - Anyone else that just wants to know how to customize the jar-with-dependencies descriptor to fix this problem (like I did) here's what you need: jar-with-dependencies jar false true runtime /META-INF/*.RSA /META-INF/*.DSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.dsa /META-INF/*.sf target/classes was: Anyone else that just wants to know how to customize the jar-with-dependencies descriptor to fix this problem (like I did) here's what you need: jar-with-dependencies jar false true runtime **/META-INF/*.RSA **/META-INF/*.DSA **/META-INF/*.SF **/META-INF/*.rsa **/META-INF/*.dsa **/META-INF/*.sf target/classes > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Geoffrey De Smet >Assignee: Allan Ramirez > Fix For: 2.1 > > Attachments: MASSEMBLY-64-maven-assembly-plugin.patch > > Original Estimate: 5 hours > Time Spent: 1 hour, 30 minutes > Remaining Estimate: 3 hours, 30 minutes > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1038) Build definitions should list what type they are (ant, maven, maven2, shell)
[ http://jira.codehaus.org/browse/CONTINUUM-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106878 ] Emmanuel Venisse commented on CONTINUUM-1038: - Yes. Without it in beta-3, we'll wait 1.2 > Build definitions should list what type they are (ant, maven, maven2, shell) > > > Key: CONTINUUM-1038 > URL: http://jira.codehaus.org/browse/CONTINUUM-1038 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Kindgren updated MJAR-30: --- Attachment: MJAR-30-maven-jar-plugin.patch Another try at this one, now with correct paths. Have renamed the tests so that they refer to the issue that they are testing. I have also updated the usage documentation to show how to include/exclude files from the produced jar. The tests verifies both of the issues MJAR-30 and MJAR-80. The MJAR-13 issue seems to be a duplicate of MJAR-80, so that should be covered in the tests as well. > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Kindgren updated MJAR-30: --- Attachment: MJAR-30-maven-jar-plugin-1.patch > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106880 ] Johan Kindgren edited comment on MJAR-30 at 9/9/07 12:47 PM: - Have renamed the tests so that they refer to the issue that they are testing. I have also updated the usage documentation to show how to include/exclude files from the produced jar. The tests verifies both of the issues MJAR-30 and MJAR-80. The MJAR-13 issue seems to be a duplicate of MJAR-80, so that should be covered in the tests as well. I slipped up twice creating the patch, but 'MJAR-30-maven-jar-plugin-1.patch' should be the one to use. was: Another try at this one, now with correct paths. Have renamed the tests so that they refer to the issue that they are testing. I have also updated the usage documentation to show how to include/exclude files from the produced jar. The tests verifies both of the issues MJAR-30 and MJAR-80. The MJAR-13 issue seems to be a duplicate of MJAR-80, so that should be covered in the tests as well. > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-29) APT - local anchor doesn't work
[
http://jira.codehaus.org/browse/DOXIA-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated DOXIA-29:
-
Fix Version/s: 1.0-alpha-9
> APT - local anchor doesn't work
> ---
>
> Key: DOXIA-29
> URL: http://jira.codehaus.org/browse/DOXIA-29
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 1.0-alpha-5
> Environment: Using maven 2.0 on windows XP
>Reporter: Olivier Berlanger
>Assignee: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.0-alpha-9
>
>
> In APT documents, the local anchor definition {anchor} and references
> {{anchor}} are not correctly processed.
> Also, there is no anchor generated automatically for section titles (as
> mentionned in APT doc)
> Sample page : http://doxia.codehaus.org/format.html
> --> try to click on the only internal link named "document structure" it has
> been generated as an external link.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-43) Can't put text in front of figure block
[ http://jira.codehaus.org/browse/DOXIA-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106883 ] Dennis Lundberg commented on DOXIA-43: -- What is the use case for putting text in front of a figure block? Isn't a figure caption enough? The "image-as-list-item-bullet" can, and should, be solved by using css. > Can't put text in front of figure block > --- > > Key: DOXIA-43 > URL: http://jira.codehaus.org/browse/DOXIA-43 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Hugo Palma >Priority: Minor > > It would be great if i could put some text in front of a figure block. Right > now i can't place any text in the same line as the image. > It would also be great if i could indent the figure block. For instance, if i > want to create list items that display an image in front of each item. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-142) Allow snippet macro contents to be output as-is, instead of verbatim
[
http://jira.codehaus.org/browse/DOXIA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated DOXIA-142:
--
Fix Version/s: 1.0-beta-1
> Allow snippet macro contents to be output as-is, instead of verbatim
>
>
> Key: DOXIA-142
> URL: http://jira.codehaus.org/browse/DOXIA-142
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-alpha-8
>Reporter: Dennis Lundberg
> Fix For: 1.0-beta-1
>
> Attachments: snippet-non-verbatim.patch
>
>
> It would be extremely useful to be able to use the snippet macro to "include"
> ready made content. That is not possible because the SnippetMacro class
> outputs the content as verbatim escaped text. This could be allowed by adding
> a new parameter "verbatim" to the snippet macro that defaults to "true" to
> preserve the current behavior.
> Consider this code example
> {code}
> verbatim="false"/>
> {code}
> It would take the snippet "mytable" from the specified file and insert it
> "as-is".
> If you like this idea I will apply the patch and add examples to the
> documentation as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.
[ http://jira.codehaus.org/browse/DOXIA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106884 ] Dennis Lundberg commented on DOXIA-68: -- Dave and Martin, do you consider this issue solved? > Adding twiki plugin as build extension makes goal site:site fail. > - > > Key: DOXIA-68 > URL: http://jira.codehaus.org/browse/DOXIA-68 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-alpha-8 > Environment: WinXp, Java5 >Reporter: Martin Zeltner > Fix For: 1.0 > > > When I add the twiki module as an extension in my pom.xml the goal site:site > will fail. > Extension config snippet: > -- > > > > > doxia-module-twiki > org.apache.maven.doxia > 1.0-alpha-9-SNAPSHOT > > > > -- > Console output: > -- > mvn site:site -X > + Error stacktraces are turned on. > Maven version: 2.1-SNAPSHOT > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building EL4J module core > [INFO]task-segment: [site:site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error getting reports from the plugin > 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find the mojo > 'org.apache.maven.plugins:maven-jxr-plugin:2.1-SNAPSHOT:jxr' in the plugin > 'org.apache > .maven.plugins:maven-jxr-plugin' > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports > from the plugin 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find > the mojo 'org.apache.maven.plugins:maven-jxr-p > lugin:2.1-SNAPSHOT:jxr' in the plugin > 'org.apache.maven.plugins:maven-jxr-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:689) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.ja
[jira] Commented: (SUREFIRE-313) build fails with ClassNotFoundException, BUT the class IS there!
[
http://jira.codehaus.org/browse/SUREFIRE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106885
]
Anders Hammar commented on SUREFIRE-313:
My bad. When reading the documentation more carefully I see that pre-1.4 JDKs
should be supported. My fix above includes JDK 1.4+ stuff.
> build fails with ClassNotFoundException, BUT the class IS there!
>
>
> Key: SUREFIRE-313
> URL: http://jira.codehaus.org/browse/SUREFIRE-313
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, Junit 4.x support
>Affects Versions: 2.3
> Environment: Windows XP SP2, Java SE 6, Maven 2.0.5
>Reporter: Ivan Mikushin
> Fix For: 2.4
>
> Attachments: mvn-junit4.log, mvn-pojo-test.log, pom.xml
>
>
> JUnit 4 and POJO tests give ClassNotFoundException exceptions in *test* phase
> of the build (pom.xml is attached).
> The console output gives a hint: JUnit 3.8.1 is appended to the
> surefire-booter forked JVM classpath instead of JUnit 4 (I tried it with
> junit-4.0, 4.1 and 4.2). When I try a POJO test case I get the same error.
> Also attached are the outputs from the command lines for JUnit4 and POJO test
> cases
> {{mvn -X clean test > mvn.log}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-146) Compile error using Linux + IntelliJ (quotedpath'test) - please rename
Compile error using Linux + IntelliJ (quotedpath'test) - please rename -- Key: MJAVADOC-146 URL: http://jira.codehaus.org/browse/MJAVADOC-146 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Johannes Schneider IntelliJ Idea does not compile the plugin because of the following path: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ I know that this is an IntelliJ bug. But since the "'" is not very common in source paths, I suggest to rename is to something like "quotedpath-test". So please run a short svn mv https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath-test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-146) Compile error using Linux + IntelliJ (quotedpath'test) - please rename
[ http://jira.codehaus.org/browse/MJAVADOC-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106890 ] Dennis Lundberg commented on MJAVADOC-146: -- Without having looked into it, I think that the whole purpose of this test is to have the character ' in the path. So renaming the directory would defeat the meaning of the test. > Compile error using Linux + IntelliJ (quotedpath'test) - please rename > -- > > Key: MJAVADOC-146 > URL: http://jira.codehaus.org/browse/MJAVADOC-146 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Johannes Schneider > > IntelliJ Idea does not compile the plugin because of the following path: > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > I know that this is an IntelliJ bug. But since the "'" is not very common in > source paths, I suggest to rename is to something like "quotedpath-test". > So please run a short > svn mv > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath-test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-146) Compile error using Linux + IntelliJ (quotedpath'test) - please rename
[ http://jira.codehaus.org/browse/MJAVADOC-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Schneider updated MJAVADOC-146: Attachment: Renamed_quotedpath'test.patch I created a patch and renamed all occurrences within the test code. Running the tests results in 17 errors - but those errors also happened before applying the patch. So I think the patch didn't break anything... But I am not sure... > Compile error using Linux + IntelliJ (quotedpath'test) - please rename > -- > > Key: MJAVADOC-146 > URL: http://jira.codehaus.org/browse/MJAVADOC-146 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Johannes Schneider > Attachments: Renamed_quotedpath'test.patch > > > IntelliJ Idea does not compile the plugin because of the following path: > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > I know that this is an IntelliJ bug. But since the "'" is not very common in > source paths, I suggest to rename is to something like "quotedpath-test". > So please run a short > svn mv > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath-test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-146) Compile error using Linux + IntelliJ (quotedpath'test) - please rename
[ http://jira.codehaus.org/browse/MJAVADOC-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106892 ] Johannes Schneider commented on MJAVADOC-146: - Dennis: Arghl - of couse... I should just have read the directory name Ok, so forget about this entry and please just close it > Compile error using Linux + IntelliJ (quotedpath'test) - please rename > -- > > Key: MJAVADOC-146 > URL: http://jira.codehaus.org/browse/MJAVADOC-146 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Johannes Schneider > Attachments: Renamed_quotedpath'test.patch > > > IntelliJ Idea does not compile the plugin because of the following path: > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > I know that this is an IntelliJ bug. But since the "'" is not very common in > source paths, I suggest to rename is to something like "quotedpath-test". > So please run a short > svn mv > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath-test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-146) Compile error using Linux + IntelliJ (quotedpath'test) - please rename
[ http://jira.codehaus.org/browse/MJAVADOC-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Schneider closed MJAVADOC-146. --- Resolution: Won't Fix Stupid, stupid, stupid > Compile error using Linux + IntelliJ (quotedpath'test) - please rename > -- > > Key: MJAVADOC-146 > URL: http://jira.codehaus.org/browse/MJAVADOC-146 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Johannes Schneider > Attachments: Renamed_quotedpath'test.patch > > > IntelliJ Idea does not compile the plugin because of the following path: > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > I know that this is an IntelliJ bug. But since the "'" is not very common in > source paths, I suggest to rename is to something like "quotedpath-test". > So please run a short > svn mv > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath'test/ > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/test/resources/unit/quotedpath-test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-313) build fails with ClassNotFoundException, BUT the class IS there!
[
http://jira.codehaus.org/browse/SUREFIRE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106885
]
Anders Hammar edited comment on SUREFIRE-313 at 9/9/07 2:44 PM:
My bad. When reading the documentation more carefully I see that pre-1.4 JDKs
should be supported. My fix above includes JDK 1.4+ stuff.
EDIT: Why do we need to be compatible with JDK 1.3? Maven 2 requires JDK 1.4 to
execute, so I don't see the need for this plugin to support JDK 1.3. Or am I
missing something?
was:
My bad. When reading the documentation more carefully I see that pre-1.4 JDKs
should be supported. My fix above includes JDK 1.4+ stuff.
> build fails with ClassNotFoundException, BUT the class IS there!
>
>
> Key: SUREFIRE-313
> URL: http://jira.codehaus.org/browse/SUREFIRE-313
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, Junit 4.x support
>Affects Versions: 2.3
> Environment: Windows XP SP2, Java SE 6, Maven 2.0.5
>Reporter: Ivan Mikushin
> Fix For: 2.4
>
> Attachments: mvn-junit4.log, mvn-pojo-test.log, pom.xml
>
>
> JUnit 4 and POJO tests give ClassNotFoundException exceptions in *test* phase
> of the build (pom.xml is attached).
> The console output gives a hint: JUnit 3.8.1 is appended to the
> surefire-booter forked JVM classpath instead of JUnit 4 (I tried it with
> junit-4.0, 4.1 and 4.2). When I try a POJO test case I get the same error.
> Also attached are the outputs from the command lines for JUnit4 and POJO test
> cases
> {{mvn -X clean test > mvn.log}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106894 ] Jochen Wiedmann commented on WAGON-82: -- > Firstly, I can't get that change into Maven trunk/branch until wagon would be > released with it's changes. Agreed, but I do not have any idea, how to solve the problem without any API changes. The current API depends on the assumptions that a) there is exactly one protocol being used by the wagon provider and b) the Wagon user is responsible to know which protocol that is. Both assumptions are, IMO, plainly wrong, as the webdav provider obviously demonstrates. > However, the upshot of the patch is that the webdav wagon ignores the proxy > that is passed in. I can't follow you here. The old proxy configuration is still in place and the patch should take care that the old proxy configuration is used, if no ProxyInfo is present. > I think it would be better to take the earlier solution provided by Jochen > where: > a) we fix the wagon manager to pass the correct proxy in (presumably it's > giving dav instead of http - surely we can figure that out), or otherwise You refer to the solution proposed by Joakim, not Jochen? It is up to you to determine whether such an ugly workaround should be installed. My strategy would clearly be to push out a wagon release ASAP (perhaps even a version 1.0-beta-2.1, which could be identical to 1.0-beta-2, apart from this patch) and use that in the Maven core, if 1.0-beta-3-SNAPSHOT is undesirable. > b) pass in all the proxies and let the wagon decide which to use. That is, IMO, exactly, what the ProxyInfo does. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Assignee: Brett Porter >Priority: Blocker > Attachments: WAGON-82-maven-artifact-manager.patch, > WAGON-82-tested-maven-artifact-manager.patch, WAGON-82-tested-wagon.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1427) Ability to choose the build definition for 'Build all projects' and 'Build Project(s)'
[ http://jira.codehaus.org/browse/CONTINUUM-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1427: Summary: Ability to choose the build definition for 'Build all projects' and 'Build Project(s)' (was: Ability to choose the build definition for 'Build all projects') > Ability to choose the build definition for 'Build all projects' and 'Build > Project(s)' > -- > > Key: CONTINUUM-1427 > URL: http://jira.codehaus.org/browse/CONTINUUM-1427 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: George Gastaldi >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > > Currently the default build definition is used when the 'Build all projects' > button is clicked. > It should be possible to choose a different build definition. > Show in the 'Group Actions' section, so only group-level build definitions > should be shown. > Place a drop down list right next to the 'Build all projects' button -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1427) Ability to choose the build definition for 'Build all projects' and 'Build Project(s)'
[ http://jira.codehaus.org/browse/CONTINUUM-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1427. --- Resolution: Fixed svn rev 574073. > Ability to choose the build definition for 'Build all projects' and 'Build > Project(s)' > -- > > Key: CONTINUUM-1427 > URL: http://jira.codehaus.org/browse/CONTINUUM-1427 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: George Gastaldi >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > > Currently the default build definition is used when the 'Build all projects' > button is clicked. > It should be possible to choose a different build definition. > Show in the 'Group Actions' section, so only group-level build definitions > should be shown. > Place a drop down list right next to the 'Build all projects' button -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-71) Include transitive dependencies in convergence report
[ http://jira.codehaus.org/browse/MPIR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPIR-71: Fix Version/s: 2.2 > Include transitive dependencies in convergence report > - > > Key: MPIR-71 > URL: http://jira.codehaus.org/browse/MPIR-71 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Reporter: Dennis Lundberg > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-35) Site Plugin should work from Template. Plugin Should not generate Markup from Java
[ http://jira.codehaus.org/browse/MPIR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPIR-35: Fix Version/s: 2.2 > Site Plugin should work from Template. Plugin Should not generate Markup > from Java > --- > > Key: MPIR-35 > URL: http://jira.codehaus.org/browse/MPIR-35 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Tim O'Brien > Fix For: 2.2 > > > The site plugin currently generates markup from Java. There is logic in the > team list report that prints HTML and Javascript directly to a StringBuffer > and there is no facility for customization. Because of this, every single > site that uses the project info reports ends up with the same text. Google > for the text of the team-list plugin and there are at least 18,000 matching > pages. > There needs to be a facility for customization. I propose that the default > report is published from a velocity template loaded form the classpath, but > the site plugin checks for the presence of an overriding velocity template in > a know path (or from a URL). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-17) Create XML documents containing report data.
[ http://jira.codehaus.org/browse/MPIR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPIR-17: Fix Version/s: 2.2 > Create XML documents containing report data. > > > Key: MPIR-17 > URL: http://jira.codehaus.org/browse/MPIR-17 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3 >Reporter: Chris Hagmann > Fix For: 2.2 > > Original Estimate: 10 hours > Remaining Estimate: 10 hours > > It would be a huge improvement if each report was written as as XML document > before optionally rendering it. If you did that, then other plugins could use > those XML reports, apply XSLT or whatever to generate their own version of a > report. It would make the whole reporting thing much more flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3179) [regression] incorrect handling of build errors in the reactor
[ http://jira.codehaus.org/browse/MNG-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3179: --- Fix Version/s: (was: 2.1) 2.1-alpha-1 This along with general error reporting needs to be done before alpha-1. > [regression] incorrect handling of build errors in the reactor > -- > > Key: MNG-3179 > URL: http://jira.codehaus.org/browse/MNG-3179 > Project: Maven 2 > Issue Type: Bug > Components: Command Line, Reactor and workspace >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: Jason van Zyl >Priority: Minor > Fix For: 2.1-alpha-1 > > > example: introduce an error into the Maven trunk build (I removed the jdom > dependency from maven-model to cause compile failures), and run "mvn clean > install". > You get the error in the project, then the list of reactor projects with > success/fail/not built, then the errors again, then: > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] BUILD ERRORS > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon Sep 03 10:18:07 EST 2007 > [INFO] Final Memory: 20M/37M > [INFO] > > FATAL ERROR: Unable to configure the Maven application > For more information, run with the -e flag > I expect that: > * the build failures should only be output once in the --fail-fast mode > * it should be BUILD FAILURES, not BUILD ERRORS > * the FATAL ERROR message should not be present at the end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3181) JDOM artifact filtering is causing problems
[ http://jira.codehaus.org/browse/MNG-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106903 ] Jason van Zyl commented on MNG-3181: There are two problems. 1) The JDOM in the root loader causes the release plugin grief 2) The JDOM pulled in by the webdav extension causes the release plugin grief The problem is that JDOM uses Class.forName (bad) and it's in the root loader and trying to grab something from Jaxen which is in the release plugin loader which causes things to blow. I have no idea how this is working. Things might all be getting jammed in the same classloader, but JDOM and Jaxen are definitely in different classloaders in 2.1 and we get the following. Exception in thread "main" java.lang.NoClassDefFoundError: org/jaxen/JaxenException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.jdom.xpath.XPath.newInstance(XPath.java:126) I have removed JDOM from the core and put the JDOM stuff required for the embedder in a maven-embedder-extras package and this makes more sense as it is an extra and prevents the core from being polluted. But the webdav extension is a problem, currently being loaded in the root loader makes it not work. My theory is that the extension manager was not blocking the loading of artifacts by adding extension artifacts to the filter manager and the classloader was loading child first. We tried to be more standard with later versions of classworlds but i think we need to load child first and let duplicate artifacts find their way into plugin classloaders. > JDOM artifact filtering is causing problems > --- > > Key: MNG-3181 > URL: http://jira.codehaus.org/browse/MNG-3181 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > For example in the release plug that requires JDOM which uses Jaxen. We are > cutting off resolution of Jaxen so the release plugin fails. Anything that > requires Jaxen via JDOM will fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1439) Group Summary page display error
Group Summary page display error Key: CONTINUUM-1439 URL: http://jira.codehaus.org/browse/CONTINUUM-1439 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-beta-3 Environment: continuum/trunk r574073 20070909 Reporter: Wendy Smoak After adding some shell script type projects, the Group Summary page only displays up to the 'Choose a BuildDefinition' drop down. I left the definition blank on the last thing I added, which I think was a build definition using a shell script. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-472) Re-enabled metadata tests in archiva-proxy
[ http://jira.codehaus.org/browse/MRM-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-472. -- Assignee: Joakim Erdfelt Resolution: Fixed > Re-enabled metadata tests in archiva-proxy > -- > > Key: MRM-472 > URL: http://jira.codehaus.org/browse/MRM-472 > Project: Archiva > Issue Type: Sub-task > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-463) Metadata merging doesn't work.
[ http://jira.codehaus.org/browse/MRM-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-463. -- Resolution: Fixed Code has been commit'd to subversion. > Metadata merging doesn't work. > -- > > Key: MRM-463 > URL: http://jira.codehaus.org/browse/MRM-463 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-2 > > > When dealing with metadata.xml files and proxying the merging of metadata is > not performed correctly. > Often ending up with a metadata.xml file with no versions specified. > Tasks > 1) Re-enabled metadata tests in the archiva-proxy module. > 2) Fix the proxy code (and possibly the tests) to ensure metadata.xml files > are merged correctly. > 3) Create tests for 1 managed to multiple remote repos all with metadata.xml > for the same groupId:artifactId > 4) Create tests for versionless and versioned metadata.xml files. > Note: Consider using the VersionComparator to obtain a unique list of sorted > (by version) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-473) Fix the proxy code (and possibly the tests) to ensure proper merging of metadata.xml files.
[ http://jira.codehaus.org/browse/MRM-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-473. -- Assignee: Joakim Erdfelt Resolution: Fixed > Fix the proxy code (and possibly the tests) to ensure proper merging of > metadata.xml files. > --- > > Key: MRM-473 > URL: http://jira.codehaus.org/browse/MRM-473 > Project: Archiva > Issue Type: Sub-task >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-432) Proxy Connectors are unable to download artifacts with alpha numerical version numbers
[ http://jira.codehaus.org/browse/MRM-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106906 ] Joakim Erdfelt commented on MRM-432: The problem is most definately within the BidirectionalRepositoryLayout routines. It appears that the version id is not correctly identified. I've made some progress in this regard, but there are still test cases that are failing. Check SVN trunk for the commented test cases. Search for "TODO: Re-enabled in the future." > Proxy Connectors are unable to download artifacts with alpha numerical > version numbers > -- > > Key: MRM-432 > URL: http://jira.codehaus.org/browse/MRM-432 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-alpha-2 > Environment: Solaris 5.9, java 1.5.0_11, maven 2.0.7 >Reporter: Mathias Arens >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-2 > > > Archiva is unable to download this artifact: > > ch.ethz.ganymed > ganymed-ssh2 > build210 > > although it is in the central repository. I can download the artifact if a > switch the central mirror of, just downloading the artifact directly over > maven. I didn't had any problems with all the other artifacts from the > central repository. > I assume that there is a problem with alpha numerical version numbers. But > it's just a guess. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2248) Maven should get the source and javadoc jars from a repository if they are available
[ http://jira.codehaus.org/browse/MNG-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2248: -- Fix Version/s: (was: 2.1) 2.x > Maven should get the source and javadoc jars from a repository if they are > available > > > Key: MNG-2248 > URL: http://jira.codehaus.org/browse/MNG-2248 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Aaron Freeman >Priority: Minor > Fix For: 2.x > > > It would be nice if the component that downloads a binary jar file from a > repositroy would also download any available source or javadoc jars. > Currently the only way to do this is by using the eclipse plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2310) Add switch to display plugin versions
[ http://jira.codehaus.org/browse/MNG-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2310. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 2.1) I think the combo of help:describe + dependencies plugin + help:effective-pom (when specifying versions) give this now, plus it is in the log output. > Add switch to display plugin versions > - > > Key: MNG-2310 > URL: http://jira.codehaus.org/browse/MNG-2310 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.4 >Reporter: Mark Hobson >Assignee: Brett Porter > > There's no easy way to find out what plugin versions maven is currently using > without delving into the local repo. It'd be nice if there was a cli switch > to list the installed plugins and their version numbers. > This may be worth adding to the -v switch, or perhaps in a new switch > depending on the verbosity. Depending on the implementation details, this > may make more sense being added to the help plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2319) strange issue when trying to generate a site which uses the multi project and assembly stuff
[ http://jira.codehaus.org/browse/MNG-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2319: -- Fix Version/s: (was: 2.1) 2.0.x not sure if it's already fixed, but we should definitely be defending against NPEs and reporting something properly. > strange issue when trying to generate a site which uses the multi project and > assembly stuff > > > Key: MNG-2319 > URL: http://jira.codehaus.org/browse/MNG-2319 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: james strachan > Fix For: 2.0.x > > > Grab a checkout of ActiveMQ and try > mvn clean install site:site -Dmaven.test.skip=true > And you get this - which seems to be related to maven's insistence on > rebuilding everything again when it tries to build the 'assembly' module. > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building ActiveMQ > [INFO] > > [INFO] Skipping missing optional mojo: > org.apache.maven.plugins:maven-site-plugin:attach-descriptor > [INFO] No goals needed for project - skipping > [INFO] > > [INFO] Building ActiveMQ :: JAAS > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > at org.apache.maven.project.MavenProject.(MavenProject.java:251) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:886) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:729) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] - > If you try just to make the site via > mvn clean site:site -Dmaven.test.skip=true > then you get... > [INFO] > > [INFO] Building ActiveMQ :: Assembly > [INFO]task-segment: [clean, site:site] > [INFO] > > [INFO] snapshot incubator-activemq:maven-bundle-plugin:4.0-SNAPSHOT: checking > for updates from codehaus.snapshots > [INFO] snapshot incubator-activemq:maven-bundle-plugin:4.0-SNAPSHOT: checking > for updates from maven-csharp-plugins > [WARNING] *** CHECKSUM FAILED - Invalid checksum file - RETRYING > [WARNING] *** CHECKSUM FAILED - Invalid checksum file - IGNORING > [INFO] [clean:clean] > [INFO] Deleting directory /workspace/eclipse/activemq/assembly/target > [INFO] Deleting dir
[jira] Updated: (MNG-2464) [regression] maven 2.1 uses snapshot repository to look for plugins
[ http://jira.codehaus.org/browse/MNG-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2464: -- Affects Version/s: 2.1-alpha-1 Fix Version/s: (was: 2.1) 2.1-alpha-1 pretty old - may already be fixed - bringing up to 2.1-alpha-1 to confirm > [regression] maven 2.1 uses snapshot repository to look for plugins > --- > > Key: MNG-2464 > URL: http://jira.codehaus.org/browse/MNG-2464 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0-alpha-1, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > Attachments: mvn2.0.4.log, mvn2.1.log > > > Building components trunk with 2.0.4 and 2.1-SNAPSHOT from > http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
