[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: assembly idjar-with-dependencies/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet outputDirectory/outputDirectory outputFileNameMapping/outputFileNameMapping unpacktrue/unpack scoperuntime/scope unpackOptions excludes exclude**/META-INF/*.RSA/exclude exclude**/META-INF/*.DSA/exclude exclude**/META-INF/*.SF/exclude exclude**/META-INF/*.rsa/exclude exclude**/META-INF/*.dsa/exclude exclude**/META-INF/*.sf/exclude /excludes /unpackOptions /dependencySet /dependencySets fileSets fileSet directorytarget/classes/directory outputDirectory/outputDirectory /fileSet /fileSets /assembly 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest mainClassggg.GGGStandaloneApp/mainClass addClasspathtrue/addClasspath /manifest /archive /configuration /plugin plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptorIdjar-with-dependencies/descriptorId archive !-- Please document this -- manifest mainClassggg.GGGStandaloneApp/mainClass /manifest /archive /configuration /plugin 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: assembly idjar-with-dependencies/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet outputDirectory/outputDirectory outputFileNameMapping/outputFileNameMapping unpacktrue/unpack scoperuntime/scope unpackOptions excludes exclude/META-INF/*.RSA/exclude exclude/META-INF/*.DSA/exclude exclude/META-INF/*.SF/exclude exclude/META-INF/*.rsa/exclude exclude/META-INF/*.dsa/exclude exclude/META-INF/*.sf/exclude /excludes /unpackOptions /dependencySet /dependencySets fileSets fileSet directorytarget/classes/directory outputDirectory/outputDirectory /fileSet /fileSets /assembly 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: assembly idjar-with-dependencies/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet outputDirectory/outputDirectory outputFileNameMapping/outputFileNameMapping unpacktrue/unpack scoperuntime/scope unpackOptions excludes exclude**/META-INF/*.RSA/exclude exclude**/META-INF/*.DSA/exclude exclude**/META-INF/*.SF/exclude exclude**/META-INF/*.rsa/exclude exclude**/META-INF/*.dsa/exclude exclude**/META-INF/*.sf/exclude /excludes /unpackOptions /dependencySet /dependencySets fileSets fileSet directorytarget/classes/directory outputDirectory/outputDirectory /fileSet /fileSets /assembly 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest mainClassggg.GGGStandaloneApp/mainClass addClasspathtrue/addClasspath /manifest /archive /configuration /plugin plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptorIdjar-with-dependencies/descriptorId archive !-- Please document this -- manifest mainClassggg.GGGStandaloneApp/mainClass /manifest /archive /configuration /plugin 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
[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}
macro name=snippet id=mytable file=src/site/snippets/snippets.xml
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: -- build extensions !-- Site -- extension artifactIddoxia-module-twiki/artifactId groupIdorg.apache.maven.doxia/groupId version1.0-alpha-9-SNAPSHOT/version /extension /extensions /build -- 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
[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-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: dependency groupIdch.ethz.ganymed/groupId artifactIdganymed-ssh2/artifactId versionbuild210/version /dependency 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.init(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 directory /workspace/eclipse/activemq/assembly/target/classes [INFO] Deleting directory
