[jira] Commented: (MCHANGES-60) The jira report should handle the nonProxyHosts specified in settings.xml
[ http://jira.codehaus.org/browse/MCHANGES-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105391 ] Marcus Schulte commented on MCHANGES-60: Separator character should be the pipe (|). Wildcards should be supported. See http://maven.apache.org/guides/mini/guide-proxies.html . This Bug (yes it *is* a bug ;) ) renders the plugin unusable for us, because our proxy refuses to proxy internal servers. > The jira report should handle the nonProxyHosts specified in settings.xml > - > > Key: MCHANGES-60 > URL: http://jira.codehaus.org/browse/MCHANGES-60 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: jira-report >Affects Versions: 2.0-beta-2 > Environment: A network with a proxy to access the outside, and a JIRA > inside the network. >Reporter: Pierre-Antoine Grégoire > > These nonProxyHosts can be retrieved with the > settings.getActiveProxy().getNonProxyHosts(); > This returns a String containing a (usually?)comma-separated list of > nonProxyHosts. > If the jira URL matches one of these hosts, it should not use any proxy of > course ;). > I haven't found a nonProxyHosts concept in commons-httpclient, so it should > be checked in the determineProxy Method of AbstractJiraDownloader. > This is quickly fixed and would be very useful ;) > Thanks in advance -- 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: (MECLIPSE-319) Make eclipse:rad work with manifests without "Class-Path:"-entries
Make eclipse:rad work with manifests without "Class-Path:"-entries -- Key: MECLIPSE-319 URL: http://jira.codehaus.org/browse/MECLIPSE-319 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Reporter: Mikko Koponen Priority: Minor Attachments: manifest-classpath-null-check.patch, rad-manifest-problem-log.txt So... We have a project with somewhat bad manifest files, and we'd like to use the rad goal. The plugin fails for existing manifests that don't have Class-Path entries, attached is an error log. The - also attached - patch fixes this. -- 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: (MRM-483) verify thread safety of Configuration object
verify thread safety of Configuration object Key: MRM-483 URL: http://jira.codehaus.org/browse/MRM-483 Project: Archiva Issue Type: Bug Reporter: Brett Porter Deng discovered a thread-safety bug in the re-initialisation of the Configuration object when saving and consequently re-initialising. While that has been fixed, and DefaultArchivaConfiguration is now thread safe, it does pass out the shared Configuration object. We need to audit places that the object may be modified in a way that is not thread safe (if it is being modified, it should not be used by another thread until the save() method has completed and those threads have called get() again - perhaps anything that intends to modify it should get back a copy of the configuration object instead). -- 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-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105398 ] nicolas de loof commented on CONTINUUM-605: --- Is there any work in progress on this issue for continuum 1.1 ? This feature is a requirement for me as a CruiseControl user. I'm also trying Hudson that provides this feature, but is not 100% maven2 compliant. > Add a RecipientSource that derives addresses from the change list > - > > Key: CONTINUUM-605 > URL: http://jira.codehaus.org/browse/CONTINUUM-605 > Project: Continuum > Issue Type: New Feature > Components: Notification Subsystem >Reporter: John Didion > Fix For: Future > > Attachments: change-list-recipient-source.diff, > ChangeListRecipientSource.diff > > > CruiseControl has the nice feature of only sending notification email to > those users who submitted the changes in the build. I missed that feature > when switching to Continuum, so I implemented it. It compiles a list of scm > ids from the change list, then matches them against the developers in the POM > to get email addresses. It delegates to the default RecipientSource if there > is no change list. -- 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-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105401 ] Brett Porter commented on CONTINUUM-605: I'll ping the dev list. > Add a RecipientSource that derives addresses from the change list > - > > Key: CONTINUUM-605 > URL: http://jira.codehaus.org/browse/CONTINUUM-605 > Project: Continuum > Issue Type: New Feature > Components: Notification Subsystem >Reporter: John Didion > Fix For: Future > > Attachments: change-list-recipient-source.diff, > ChangeListRecipientSource.diff > > > CruiseControl has the nice feature of only sending notification email to > those users who submitted the changes in the build. I missed that feature > when switching to Continuum, so I implemented it. It compiles a list of scm > ids from the change list, then matches them against the developers in the POM > to get email addresses. It delegates to the default RecipientSource if there > is no change list. -- 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: (MSITE-252) Links to submodules under the "Modules" menu is wrong
Links to submodules under the "Modules" menu is wrong - Key: MSITE-252 URL: http://jira.codehaus.org/browse/MSITE-252 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0 Environment: Ubuntu 7.0.4, Maven 2.0.7 Reporter: Erik Drolshammer Under the "Modules" menu there are links to the submodules. All this links are "http://maven.apache.org/index.html";. These should be relative links to each submodule. -- 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: (MNGSITE-17) Mailto link for repository mailing list is incorrect
[ http://jira.codehaus.org/browse/MNGSITE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105416 ] Tom Cort commented on MNGSITE-17: - [EMAIL PROTECTED] exists, perhaps that's the proper address? > Mailto link for repository mailing list is incorrect > > > Key: MNGSITE-17 > URL: http://jira.codehaus.org/browse/MNGSITE-17 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Geir Hedemark > > URI is > http://maven.apache.org/guides/mini/guide-central-repository-upload.html . > Mailto link is [EMAIL PROTECTED] > From my mailbox: > Hi. This is the qmail-send program at mail.sonatype.com. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > <[EMAIL PROTECTED]>: > Sorry, no mailbox here by that name. (#5.1.1) -- 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: (MAVENUPLOAD-1677) Please sync with maven-har repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105415 ] Tom Cort commented on MAVENUPLOAD-1677: --- I'm now subscribed to [EMAIL PROTECTED] > Please sync with maven-har repo > --- > > Key: MAVENUPLOAD-1677 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1677 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tom Cort > > Please sync with maven-har's repo. The shell can be found at > http://maven-har.sourceforge.net/net.sf.maven-har.sh > The repo contains jars for binary, source and javadoc, release 0.9. > I can't subscribe to the Maven repository mailing list for the same reason > mentioned in http://jira.codehaus.org/browse/MNGSITE-17 -- 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: (MASSEMBLY-232) NPE - MASSEMBLY-222 fix broken?
[ http://jira.codehaus.org/browse/MASSEMBLY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Bowsher updated MASSEMBLY-232: -- Attachment: MASSEMBLY-232-testcase.tar.bz2 Attached: MASSEMBLY-232-testcase.tar.bz2, containing: - MASSEMBLY-232-testcase/pom.xml - MASSEMBLY-232-testcase/assembly.xml > NPE - MASSEMBLY-222 fix broken? > --- > > Key: MASSEMBLY-232 > URL: http://jira.codehaus.org/browse/MASSEMBLY-232 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 >Reporter: Max Bowsher >Priority: Blocker > Attachments: MASSEMBLY-232-testcase.tar.bz2 > > > Something, most likely the fix to MASSEMBLY-222, has broken the plugin - > running "mvn package" with the attached trivial pom.xml and assembly.xml > fails with a NullPointerException. -- 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: (MASSEMBLY-232) NPE - MASSEMBLY-222 fix broken?
NPE - MASSEMBLY-222 fix broken? --- Key: MASSEMBLY-232 URL: http://jira.codehaus.org/browse/MASSEMBLY-232 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Max Bowsher Priority: Blocker Attachments: MASSEMBLY-232-testcase.tar.bz2 Something, most likely the fix to MASSEMBLY-222, has broken the plugin - running "mvn package" with the attached trivial pom.xml and assembly.xml fails with a NullPointerException. -- 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: (MSITE-252) Links to submodules under the "Modules" menu is wrong
[ http://jira.codehaus.org/browse/MSITE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105419 ] Erik Drolshammer commented on MSITE-252: ltheussl found the reason for this strange behaviour. The links use the element if defined and the output then looks like; Modules http://maven.apache.org/index.html";>moduleA http://maven.apache.org/index.html";>moduleB http://maven.apache.org/index.html";>moduleC If the -element is removed from all the poms, the links are fine. :) > Links to submodules under the "Modules" menu is wrong > - > > Key: MSITE-252 > URL: http://jira.codehaus.org/browse/MSITE-252 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0 > Environment: Ubuntu 7.0.4, Maven 2.0.7 >Reporter: Erik Drolshammer > > Under the "Modules" menu there are links to the submodules. All this links > are "http://maven.apache.org/index.html";. These should be relative links to > each submodule. -- 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-1398) Freemarker error on add M2 page
[ http://jira.codehaus.org/browse/CONTINUUM-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CONTINUUM-1398: - Attachment: CONTINUUM-1398.trace Stack trace attached. > Freemarker error on add M2 page > --- > > Key: CONTINUUM-1398 > URL: http://jira.codehaus.org/browse/CONTINUUM-1398 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: > http://vmbuild1.apache.org/continuum/addMavenTwoProject!input.action >Reporter: Henri Yandell > Attachments: CONTINUUM-1398.trace > > > Only happens when clicked on from the left hand menu. -- 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-1403) Error on edit project group page
Error on edit project group page Key: CONTINUUM-1403 URL: http://jira.codehaus.org/browse/CONTINUUM-1403 Project: Continuum Issue Type: Bug Components: Web interface Environment: http://vmbuild1.apache.org/continuum/editProjectGroup.action Reporter: Henri Yandell Attachments: CONTINUUM-1403.trace When clicking Edit on the Group page -- 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-1403) Error on edit project group page
[ http://jira.codehaus.org/browse/CONTINUUM-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CONTINUUM-1403: - Attachment: CONTINUUM-1403.trace Attaching stack traces. > Error on edit project group page > > > Key: CONTINUUM-1403 > URL: http://jira.codehaus.org/browse/CONTINUUM-1403 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: > http://vmbuild1.apache.org/continuum/editProjectGroup.action >Reporter: Henri Yandell > Attachments: CONTINUUM-1403.trace > > > When clicking Edit on the Group page -- 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: (SCM-336) Usage or custom port number results in incorrect cvsroot string in .cvspass file
Usage or custom port number results in incorrect cvsroot string in .cvspass file Key: SCM-336 URL: http://jira.codehaus.org/browse/SCM-336 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0 Environment: Continuum 1.1 beta-2 with java cvs client (default in this version) Reporter: Siarhei Dudzin Priority: Blocker When a project SCM url contains custom port number the .cvspass is not created properly - it has the custom port number appended to the default (2401) one. For example a URL scm:cvs:pserver:@:9280/CVS/ would result in 24019280 as port number in .cvspass file which results in inability to use SCM with customized port number when using java cvs client -- 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: (MSITE-252) Links to submodules under the "Modules" menu is wrong
[ http://jira.codehaus.org/browse/MSITE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-252. --- Assignee: Lukas Theussl Resolution: Won't Fix Closing won't fix as I think this behavior is correct. In the above example, the same http://maven.apache.org element was used in all module poms, hence the same absolute links were generated. > Links to submodules under the "Modules" menu is wrong > - > > Key: MSITE-252 > URL: http://jira.codehaus.org/browse/MSITE-252 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0 > Environment: Ubuntu 7.0.4, Maven 2.0.7 >Reporter: Erik Drolshammer >Assignee: Lukas Theussl > > Under the "Modules" menu there are links to the submodules. All this links > are "http://maven.apache.org/index.html";. These should be relative links to > each submodule. -- 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-1404) M2 Multi module projects still build non-recursively
M2 Multi module projects still build non-recursively Key: CONTINUUM-1404 URL: http://jira.codehaus.org/browse/CONTINUUM-1404 Project: Continuum Issue Type: Bug Components: Web - UI Environment: http://vmbuild1.apache.org/continuum/ Reporter: Henri Yandell When creating an M2 project with the 'multi module projects' checkbox ticked, the build should not contain '--non-recursive'. -- 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-424) Do not add again the same project
[ http://jira.codehaus.org/browse/CONTINUUM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105431 ] Henri Yandell commented on CONTINUUM-424: - Or build from different branches that happen to have the same poms. > Do not add again the same project > - > > Key: CONTINUUM-424 > URL: http://jira.codehaus.org/browse/CONTINUUM-424 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0 >Reporter: Vincent Massol > Fix For: Future > > > I added some projects using a POM URL. Then I hit F5 in my browser to refresh > the view and all the projects were added again... -- 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-1405) Sort by project name on Group page
Sort by project name on Group page -- Key: CONTINUUM-1405 URL: http://jira.codehaus.org/browse/CONTINUUM-1405 Project: Continuum Issue Type: Improvement Components: Web - UI Environment: http://vmbuild1.apache.org/continuum/projectGroupSummary.action?projectGroupId=22 Reporter: Henri Yandell -- 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-1406) No way to tell if a project is being built with the multi-module checkbox or not
No way to tell if a project is being built with the multi-module checkbox or not Key: CONTINUUM-1406 URL: http://jira.codehaus.org/browse/CONTINUUM-1406 Project: Continuum Issue Type: Improvement Components: Web interface Environment: http://vmbuild1.apache.org/continuum/projectGroupSummary.action?projectGroupId=22 Reporter: Henri Yandell I think JCI is multi module, and I know VFS is, but there's no obvious way to tell either on the group page or on the project page. -- 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-135) Error parsing javadoc version when used with IBM jdk 1.4.2
[ http://jira.codehaus.org/browse/MJAVADOC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105433 ] Marcel Schutte commented on MJAVADOC-135: - The following output shows why the AbstractJavadocMojo.getJavadocVersion() method fails: c:\>jvm sun14 c:\>javadoc -J-fullversion java full version "1.4.2_12-b03" c:\>jvm ibm14 c:\>javadoc -J-fullversion javadoc full version "J2RE 1.4.2 IBM Windows 32 build cn1420-20040626" Calling version.substring( 0, 3 ) on the latter will produce J2R and the subsequent NumberFormatException. > Error parsing javadoc version when used with IBM jdk 1.4.2 > -- > > Key: MJAVADOC-135 > URL: http://jira.codehaus.org/browse/MJAVADOC-135 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: IBM JDK 1.4.2 >Reporter: Manuel Santillán > > Error parsing javadocVersion in plugin 2.3 when using IBM JDK. Plugin works > fine in version 2.2. > java.lang.NumberFormatException: For input string: "J2R" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:63) > at > java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1230) > at java.lang.Float.parseFloat(Float.java:246) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2966) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > 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] > > [INFO] Total time: 18 seconds > [INFO] Finished at: Mon Jul 23 10:57:16 CEST 2007 > [INFO] Final Memory: 12M/512M > [INFO] > -- 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: (MRELEASE-271) perform goal sometimes fails with multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105436 ] ttest commented on MRELEASE-271: It seems like I'm having the same problem here. I also want to do a multi-module release but it fails with similar symptoms. > perform goal sometimes fails with multi-module projects > --- > > Key: MRELEASE-271 > URL: http://jira.codehaus.org/browse/MRELEASE-271 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-6 > Environment: XP >Reporter: David Hoffer > Attachments: MavenReleaseFailure.zip, SuccessfulReleaseBuild.txt > > > We have a multi-module maven project that has recently started failing in the > release:perform goal. > We have just added a couple more modules but do not know if that is the cause > of the failure. It seems that the release:perform fails to compile the > source after the SCM tag and checkout. The failure says that it cannot find > a dependent jar but it is that jar that it is supposed to be building and > releasing! I updated to use the latest 2.0-beta-6 release plugin version but > this did not help. > Upon receiving feedback in the maven users group that others have seen this > behavior I followed their advise and added > clean install to my > parent pom which did fix the problem. > Why is the release goal failing now? When do I and when do I not need these > changes to my pom? I will attach pom and build logs in hopes this can be > fixed soon, let me know if you need additional information. > -Dave -- 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: (ARCHETYPE-91) create is prompting for a package
[ http://jira.codehaus.org/browse/ARCHETYPE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105441 ] Brian Fox commented on ARCHETYPE-91: it seems that the confusion is around using "packaging" both in the maven context and in the java package. I think if the prompt said "Java Package" it would be less confusing. > create is prompting for a package > - > > Key: ARCHETYPE-91 > URL: http://jira.codehaus.org/browse/ARCHETYPE-91 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: NG-1.0-alpha-1 >Reporter: Brian Fox >Assignee: Raphaël Piéroni > > shouldn't the package type of the created project be the same as the one in > the archetype? It doesn't make sense to take a war, make an archetype and > then allow the user to generate it as a jar. -- 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-1407) JDO Error while adding Commons Performance
JDO Error while adding Commons Performance -- Key: CONTINUUM-1407 URL: http://jira.codehaus.org/browse/CONTINUUM-1407 Project: Continuum Issue Type: Bug Components: Web interface Environment: http://vmbuild1.apache.org/continuum/addMavenTwoProject.action# Reporter: Henri Yandell Attachments: AddProjectError.trace Performance url: http://svn.apache.org/repos/asf/commons/sandbox/performance/trunk/pom.xml -- 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: (MPCASTOR-14) update dependency to org.codehaus.castor and upgrade plugin to SourceGeneratorMain
update dependency to org.codehaus.castor and upgrade plugin to SourceGeneratorMain -- Key: MPCASTOR-14 URL: http://jira.codehaus.org/browse/MPCASTOR-14 Project: Maven 1.x Castor Plugin Issue Type: Improvement Reporter: nicolas de loof Priority: Minor Attachments: castor.patch Castor has moved to codehaus, and many deprecated methods have been removed. 0.9.5 generated code is not compatible with latests castor builds. the pactch updates dependencies and use the SourceGeneratorMain class (SourceGenerator is deprecated) -- 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: (MASSEMBLY-233) Custom ContainerDescriptorHandler integration tests don't work in Maven 2.0.7
Custom ContainerDescriptorHandler integration tests don't work in Maven 2.0.7 - Key: MASSEMBLY-233 URL: http://jira.codehaus.org/browse/MASSEMBLY-233 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: John Casey Priority: Critical It seems that Maven 2.0.7 is not looking for plugin-level dependencies for the assembly plugin. The output doesn't reflect these dependencies at all. Therefore, the custom container-descriptor handlers are not being loaded. I'm disabling these integration tests until I can straighten this out. -- 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-1408) CLONE -Problems running multi-module build with maven2
CLONE -Problems running multi-module build with maven2 -- Key: CONTINUUM-1408 URL: http://jira.codehaus.org/browse/CONTINUUM-1408 Project: Continuum Issue Type: Task Components: Web interface Affects Versions: 1.0.1 Environment: linux debian Reporter: Siarhei Dudzin Hello! Maybe a similar problem has been posted, but i´ve got problems running a multi-module maven2 build. I´ve uploaded a small pom hirachy per URL as recommended, the initialization of the sub modules in continuum has worked as wanted, all poms defined in the modules element (below!) are located correctly. The root pom has packaging type "pom" and a few modules are included in the pom´s 'modules' element. ../../signatur ../library ../weblib ../portal ../appserver/serverapp/Base ../appserver/serverapp/UserManagement ../appserver/serverapp/TemplateBeans ../release/xml/infosets ../release/xml/udFields When i run the build, following exception occurs: Reason: Could not find the model file '/home/maven/tmp/continuum-1.0.1/apps/continuum/working-directory/37/../../signatur/pom.xml'. Since continuum creates a flat directory structure with automatically created numbers as folder names, the corresponding module can not be found at this location and the build stops. My question is, if there is a way to determine the checkout folder, or have i misunderstood anything? I would be glad to establish continuum im my company, but i´m running out of time. Would be nice, if someone can give me an advice. Greetings, Wolfgang Klein -- 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-1408) CLONE -Problems running multi-module build with maven2
[ http://jira.codehaus.org/browse/CONTINUUM-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105447 ] Siarhei Dudzin commented on CONTINUUM-1408: --- The original issue was closed while the problem is still reproducable upto version 1.1-beta-2. > CLONE -Problems running multi-module build with maven2 > -- > > Key: CONTINUUM-1408 > URL: http://jira.codehaus.org/browse/CONTINUUM-1408 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.0.1 > Environment: linux debian >Reporter: Siarhei Dudzin > > Hello! > Maybe a similar problem has been posted, but i´ve got > problems running a multi-module maven2 build. > I´ve uploaded a small pom hirachy per URL as recommended, > the initialization of the sub modules in continuum has worked as wanted, > all poms defined in the modules element (below!) are located correctly. > The root pom has packaging type "pom" and a few modules are > included in the pom´s 'modules' element. > > > ../../signatur > ../library > ../weblib > ../portal > ../appserver/serverapp/Base > ../appserver/serverapp/UserManagement > ../appserver/serverapp/TemplateBeans > ../release/xml/infosets > ../release/xml/udFields > > > When i run the build, following exception occurs: > Reason: Could not find the model file > '/home/maven/tmp/continuum-1.0.1/apps/continuum/working-directory/37/../../signatur/pom.xml'. > > Since continuum creates a flat directory structure with automatically created > numbers as folder names, the corresponding > module can not be found at this location and the build stops. > My question is, if there is a way to determine the checkout folder, or have i > misunderstood anything? > I would be glad to establish continuum im my company, but i´m running out of > time. > Would be nice, if someone can give me an advice. > Greetings, > Wolfgang Klein -- 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-1679) Upload c3p0:c3p0:jar:0.9.1.2 to ibiblio
Upload c3p0:c3p0:jar:0.9.1.2 to ibiblio Key: MAVENUPLOAD-1679 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1679 Project: maven-upload-requests Issue Type: Task Reporter: Christian Nelson http://xian.slac.com/misc/c3p0-0.9.1.2-bundle.jar http://c3p0.sourceforge.net/ c3p0 is an easy-to-use library for augmenting traditional (DriverManager-based) JDBC drivers with JNDI-bindable DataSources, including DataSources that implement Connection and Statement Pooling, as described by the jdbc3 spec and jdbc2 std extension. -- 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: (DOXIA-116) DocBook Simple module "book" type Sink
[ http://jira.codehaus.org/browse/DOXIA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed DOXIA-116. Assignee: John Casey Resolution: Fixed Fix Version/s: (was: 1.0) 1.0-alpha-9 applied, after some rework. It seems that this patch had grown stale. Thanks, Eric. > DocBook Simple module "book" type Sink > -- > > Key: DOXIA-116 > URL: http://jira.codehaus.org/browse/DOXIA-116 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Docbook Simple >Reporter: Eric Redmond >Assignee: John Casey > Fix For: 1.0-alpha-9 > > Attachments: doxia-module-docbook-simple.diff, mylar-context.zip, > mylar-context.zip > > > Extended the "DockBookSink" class to handle "book" type, rather than just > "article". Each book "chapter" is a parsed Source. -- 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: (MSANDBOX-32) Docbook Rendered for Doxia Book
[ http://jira.codehaus.org/browse/MSANDBOX-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MSANDBOX-32. -- Assignee: John Casey Resolution: Fixed applied, thanks. > Docbook Rendered for Doxia Book > --- > > Key: MSANDBOX-32 > URL: http://jira.codehaus.org/browse/MSANDBOX-32 > Project: Maven 2.x Sandbox > Issue Type: New Feature > Components: doxia >Reporter: Eric Redmond >Assignee: John Casey > Attachments: doxia-book-docbook.diff, mylar-context.zip > > > Uses Docbook Sink to render a doxia book in docbook format -- 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-1409) A build does not say which build definition it came from
A build does not say which build definition it came from Key: CONTINUUM-1409 URL: http://jira.codehaus.org/browse/CONTINUUM-1409 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Henri Yandell Looking at http://vmbuild1.apache.org/continuum/buildResult.action?buildId=2126&projectId=186 - I can't tell which of the two build definitions built it. -- 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-1410) Project with two default build definitions
Project with two default build definitions -- Key: CONTINUUM-1410 URL: http://jira.codehaus.org/browse/CONTINUUM-1410 Project: Continuum Issue Type: Bug Components: Web interface Environment: http://vmbuild1.apache.org/continuum/projectView.action?projectGroupId=22&projectId=186 Reporter: Henri Yandell Commons has a group build definition that is JVM 1.4. The Performance project has a custom build definition that specifies JVM 1.5. Both are default. The group build definition still shows in the project. By the look of it, the group build definition is not running, so the one default overrides the other. -- 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: (MWAR-112) The package RELEASE version of jar files are named jarname-RELEASE.jar
The package RELEASE version of jar files are named jarname-RELEASE.jar -- Key: MWAR-112 URL: http://jira.codehaus.org/browse/MWAR-112 Project: Maven 2.x War Plugin Issue Type: Bug Environment: Maven version: 2.0.7 Java version: 1.5.0_11 OS name: "windows xp" version: "5.1" arch: "x86" Reporter: Chandra Patni Priority: Critical Suppose, I have dependency mygroup mylib RELEASE In a war packaging, if I run mvn package, the war file contains mylib-RELEASE.jar Similarly, if you run mvn clean compile war:exploded, the exploded dir contains mylib-RELEASE.jar It packages dereferenced value of RELEASE if I do, mvn clean compile mvn war:exploded -- 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: (MCHANGES-60) The jira report should handle the nonProxyHosts specified in settings.xml
[ http://jira.codehaus.org/browse/MCHANGES-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105470 ] Dennis Lundberg commented on MCHANGES-60: - I don't have access to a proxy, so it's difficult for me to test this. Patches are always welcome. I can apply them and push out new SNAPSHOTS. To me this is an improvement, but that's a matter of opinion :-) In my book a bug is an advertised feature that doesn't work as advertised. > The jira report should handle the nonProxyHosts specified in settings.xml > - > > Key: MCHANGES-60 > URL: http://jira.codehaus.org/browse/MCHANGES-60 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: jira-report >Affects Versions: 2.0-beta-2 > Environment: A network with a proxy to access the outside, and a JIRA > inside the network. >Reporter: Pierre-Antoine Grégoire > > These nonProxyHosts can be retrieved with the > settings.getActiveProxy().getNonProxyHosts(); > This returns a String containing a (usually?)comma-separated list of > nonProxyHosts. > If the jira URL matches one of these hosts, it should not use any proxy of > course ;). > I haven't found a nonProxyHosts concept in commons-httpclient, so it should > be checked in the determineProxy Method of AbstractJiraDownloader. > This is quickly fixed and would be very useful ;) > Thanks in advance -- 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: (MNGSITE-17) Mailto link for repository mailing list is incorrect
[ http://jira.codehaus.org/browse/MNGSITE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-17. -- Assignee: Dennis Lundberg Resolution: Fixed Fixed in r568749 in subversion. > Mailto link for repository mailing list is incorrect > > > Key: MNGSITE-17 > URL: http://jira.codehaus.org/browse/MNGSITE-17 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Geir Hedemark >Assignee: Dennis Lundberg > > URI is > http://maven.apache.org/guides/mini/guide-central-repository-upload.html . > Mailto link is [EMAIL PROTECTED] > From my mailbox: > Hi. This is the qmail-send program at mail.sonatype.com. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > <[EMAIL PROTECTED]>: > Sorry, no mailbox here by that name. (#5.1.1) -- 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-1411) Link to display build surefire report doesn't work (in fact displaying surefire report per build is false)
Link to display build surefire report doesn't work (in fact displaying surefire report per build is false) -- Key: CONTINUUM-1411 URL: http://jira.codehaus.org/browse/CONTINUUM-1411 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1-beta-2 Reporter: Olivier Lamy Priority: Critical Since 1.1-beta-2, the surefire report link in a build result page is not displayed anymore. But in fact, It has never worked or it's confusing. Because the link is in the BuildResult and in fact the surefire -report is the last surefire report (because we don't save all surefire reports for all builds). Try the Surefire Report in this two build result : http://maven.zones.apache.org/continuum/buildResult.action?buildId=7072&projectId=44 http://maven.zones.apache.org/continuum/buildResult.action?buildId=16143&projectId=44 My proposal is to move this link to the buildResults page and call the link Last Surefire Report. Or we can backup all surefire reports (probably too huge) Thoughs ? -- Olivier -- 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-1411) Link to display build surefire report doesn't work (in fact displaying surefire report per build is false)
[ http://jira.codehaus.org/browse/CONTINUUM-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1411: Fix Version/s: 1.1-beta-3 > Link to display build surefire report doesn't work (in fact displaying > surefire report per build is false) > -- > > Key: CONTINUUM-1411 > URL: http://jira.codehaus.org/browse/CONTINUUM-1411 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: Olivier Lamy >Priority: Critical > Fix For: 1.1-beta-3 > > > Since 1.1-beta-2, the surefire report link in a build result page is not > displayed anymore. > But in fact, It has never worked or it's confusing. Because the link is in > the BuildResult and in fact the surefire -report is the last surefire report > (because we don't save all surefire reports for all builds). > Try the Surefire Report in this two build result : > http://maven.zones.apache.org/continuum/buildResult.action?buildId=7072&projectId=44 > http://maven.zones.apache.org/continuum/buildResult.action?buildId=16143&projectId=44 > My proposal is to move this link to the buildResults page and call the link > Last Surefire Report. > Or we can backup all surefire reports (probably too huge) > Thoughs ? > -- > Olivier -- 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: (SUREFIRE-339) Surefire plugin error message does not indicate the source of the error.
[ http://jira.codehaus.org/browse/SUREFIRE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105475 ] md commented on SUREFIRE-339: - where can I find the snapshot version of this plugin with the bug fix? > Surefire plugin error message does not indicate the source of the error. > > > Key: SUREFIRE-339 > URL: http://jira.codehaus.org/browse/SUREFIRE-339 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven 2.0.6 > jdk 1.5.0_08 > Windows 2003 >Reporter: md >Assignee: Brett Porter > Fix For: 2.3.1 > > > I have been getting test failures. But maven provides no hints as to the root > cause of the failures. I have tried using the -X and the -e options, but all > I get is this. I don't konw if this is a maven issue or a surefire plugin > issue. But, the exceptions should have enough data on what tests failed. This > has made it impossible for us to track down the issue. This doesn't happend > on developer machines. It only happens on teh build machine that we are > trying to setup. > The command we ran was: > mvn -e clean test > [ERROR] BUILD FAILURE > INFO] > INFO] There are test failures. > INFO] > INFO] Trace > rg.apache.maven.BuildFailureException: There are test failures. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) >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) > aused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. >at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:425) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) >... 16 more -- 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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-core-integration-testing-2.diff "New" test case (that is only update to currently existing test that make the current it-120 covering the problem too). (I'm author of it-120 - so I am sure this patch will not destroy the idea of original test case) > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, > MNG-2871-core-integration-testing-2.diff, > MNG-2871-core-integration-tests.diff, root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:test (selected for test) > [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected > for compile) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Skipping disabled repository central > [DEBUG] ejb3: using locally installed snapshot > [DEBUG] Trying repository Newitech-snapshots-repository > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Trying repository Newitech-publiczne > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven > Snapshots (http://people.apache.org/maven-snapshot-repository) > [DEBUG] Trying repository codehausSnapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) > [DEBUG] Skipping disabled repository central > [DEBUG] Unable to download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ > -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file > Path to dependency: > 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT > 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT > pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT > from the specified remote repositories: > Maven Snapshots (http://people.apache.org/maven-snapshot-repository), > central (http://repo1.maven.org/maven2), > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), > Newitech-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > --
[jira] Created: (MASSEMBLY-234) Artifacts not deployed
Artifacts not deployed
--
Key: MASSEMBLY-234
URL: http://jira.codehaus.org/browse/MASSEMBLY-234
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Environment: Windows XP, Maven 2.0.7, Java 1.5.0_09, latest version of
all conspiring Maven plugins
Reporter: Brian Williams
I attached my two assembly descriptors to the package phase, they get created
correctly, but only the original JAR of my project gets deployed when I run
"mvn deploy". Each of my descriptors makes a ZIP containing the JAR my project
compiles plus other resources (don't ask me why they don't want them as part of
the JAR).
When I declared version 2.1 for the assembly plugin, my two assemblies deployed
with my original JAR. This is the relevant section of my POM.xml:
{{
maven-assembly-plugin
2.1
package
assembly/windows.xml
assembly/linux.xml
assembly
}}
--
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-1411) Link to display build surefire report doesn't work (in fact displaying surefire report per build is false)
[ http://jira.codehaus.org/browse/CONTINUUM-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105479 ] Brett Porter commented on CONTINUUM-1411: - linked issue for the latter part. We should take care of it not appearing urgently if that's the case. > Link to display build surefire report doesn't work (in fact displaying > surefire report per build is false) > -- > > Key: CONTINUUM-1411 > URL: http://jira.codehaus.org/browse/CONTINUUM-1411 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 1.1-beta-3 > > > Since 1.1-beta-2, the surefire report link in a build result page is not > displayed anymore. > But in fact, It has never worked or it's confusing. Because the link is in > the BuildResult and in fact the surefire -report is the last surefire report > (because we don't save all surefire reports for all builds). > Try the Surefire Report in this two build result : > http://maven.zones.apache.org/continuum/buildResult.action?buildId=7072&projectId=44 > http://maven.zones.apache.org/continuum/buildResult.action?buildId=16143&projectId=44 > My proposal is to move this link to the buildResults page and call the link > Last Surefire Report. > Or we can backup all surefire reports (probably too huge) > Thoughs ? > -- > Olivier -- 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-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105481 ] David Valeri commented on MRM-243: -- While the below info may be known to some, I couldn't find any details on the cause of this issue and needed it fixed. I have intermittently duplicated the issue on Windows XP and Windows Server 2003. By using a combination of Unlocker and the debugger monitoring finalize of FileInputStream, It appears that the InputStreams being opened in Plexus WebDAV's ReplacementGetMethod#sendResource are not closed and cause the error when the streams are not garbage collected before the PUT request is made by Maven. The involvement of the garbage collector would explain the intermittent behavior of the error. However, I can't figure out why the condition doesn't correct itself after a period of time as the open streams should eventually be closed upon garbage collection. The exception is generated on line 76 of DAVOutputStream in the Could.it WebDAV implementation. The exception occurs when replacing the existing (and sometimes locked) file with the temporary file that was created during the upload. While the Could.it WebDAV implementation of PUT is positively anal about ensuring that the output streams are closed, their GET implementation (and the Plexus WebDAV implementation ReplacementGetMethod) is lax on closing the InputStreams used to read the resource. I patched the Plexus WebDAV implementation by ensuring that the streams created in ReplacementGetMethod#sendResource are explicitly closed and have been running with the patch for a couple days without experiencing the issue. Long story short, the issue appears to be caused by a bug in plexus-webdav-1.0-alpha-3. I submitted a bug report at http://jira.codehaus.org/browse/PLXCOMP-81 and a quick patch that appears to fix the issue. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Brett Porter > Fix For: 1.0-beta-2 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MRESOURCES-47) POM properties cannot be accessed within a filter file
POM properties cannot be accessed within a filter file
--
Key: MRESOURCES-47
URL: http://jira.codehaus.org/browse/MRESOURCES-47
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: William Ferguson
Fix For: 2.3
Attachments: project.zip
Before applying a filter, the maven-resources-plugin evaluates
1) POM structural elements such as ${project.version}
2) System properties such as ${my.system.property}
that are referred to within *filter* files.
However, it does *not* evaluate any POM (or profile) property such as
${my.pom.property} at the same time.
Consequently it is not possible to define filter tokens that use POM properties.
Without this patch we would either need to have many more POM properties or
would have lots of fine grained and typically non-intuitive tokens distributed
amongst our resources.
IMHO this patch will bring the resolution mechanism for filter files in line
with property resolution mechanism in general.
I have attached a zipped project containing :
SomeResource.txt
my.filter
Look at SomeResource.txt after being processed with filtering. Note the
unresolved tokens for ${projectProperty} and ${profileProperty} for the "filter
resolution" cases. Ie the POM property values of the filter tokens were never
evaluated.
--
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: (MRESOURCES-47) POM properties cannot be accessed within a filter file
[
http://jira.codehaus.org/browse/MRESOURCES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MRESOURCES-47:
---
Attachment: MRESOURCES-47-maven-resources-plugin.patch
Here's the patch for this issue, including several test cases.
NB I have changed as little as possible to make the patch as clear as possible.
IMO applying the patch would then allow for substantial refactoring.
> POM properties cannot be accessed within a filter file
> --
>
> Key: MRESOURCES-47
> URL: http://jira.codehaus.org/browse/MRESOURCES-47
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: William Ferguson
> Fix For: 2.3
>
> Attachments: MRESOURCES-47-maven-resources-plugin.patch, project.zip
>
>
> Before applying a filter, the maven-resources-plugin evaluates
> 1) POM structural elements such as ${project.version}
> 2) System properties such as ${my.system.property}
> that are referred to within *filter* files.
> However, it does *not* evaluate any POM (or profile) property such as
> ${my.pom.property} at the same time.
> Consequently it is not possible to define filter tokens that use POM
> properties.
> Without this patch we would either need to have many more POM properties or
> would have lots of fine grained and typically non-intuitive tokens
> distributed amongst our resources.
> IMHO this patch will bring the resolution mechanism for filter files in line
> with property resolution mechanism in general.
> I have attached a zipped project containing :
> SomeResource.txt
> my.filter
> Look at SomeResource.txt after being processed with filtering. Note the
> unresolved tokens for ${projectProperty} and ${profileProperty} for the
> "filter resolution" cases. Ie the POM property values of the filter tokens
> were never evaluated.
--
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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-maven-project.diff Clean patch for this issue. > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, > MNG-2871-core-integration-testing-2.diff, > MNG-2871-core-integration-tests.diff, MNG-2871-maven-project.diff, root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:test (selected for test) > [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected > for compile) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Skipping disabled repository central > [DEBUG] ejb3: using locally installed snapshot > [DEBUG] Trying repository Newitech-snapshots-repository > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Trying repository Newitech-publiczne > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven > Snapshots (http://people.apache.org/maven-snapshot-repository) > [DEBUG] Trying repository codehausSnapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) > [DEBUG] Skipping disabled repository central > [DEBUG] Unable to download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ > -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file > Path to dependency: > 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT > 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT > pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT > from the specified remote repositories: > Maven Snapshots (http://people.apache.org/maven-snapshot-repository), > central (http://repo1.maven.org/maven2), > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), > Newitech-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) pl.waw.tabor:ejb3:ejb-client:client:1.
[jira] Commented: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105485 ] Piotr Tabor commented on MNG-2871: -- Clean (i hope) view of this issue: The problem could be called "internal dependencies" in reactor when everything is build by phase lower then "package". The real jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in "package" phase. So if we call "mvn test" for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail. I see there two options: a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call "mvn test"' to do the tests... call mvn package instead. at least we can add warning in a such a case: "Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may resolve your problem." If we decide to this solution, I can prepare such a patch. or b) Apply currently attached patches (MNG-2871-maven-project.diff, MNG-2871-core-integration-testing-2.diff) that will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact). I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need. The problem is most annoying because maven-release-plugin calls "mvn test" after upgrading version's number... So it leads to "mvn release:prepare" failure in case of ejb-client dependencies. > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, > MNG-2871-core-integration-testing-2.diff, > MNG-2871-core-integration-tests.diff, MNG-2871-maven-project.diff, root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:test (selected for test) > [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected > for compile) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Skipping disabled repository central > [DEBUG] ejb3: using locally installed snapshot > [DEBUG] Trying repository Newitech-snapshots-repository > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Trying repository Newitech-publiczne > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven > Snapshots (http://people.apache.org/maven-snapshot-repository) > [DEBUG] Trying repository codehausSnapshots > Downloading:
[jira] Issue Comment Edited: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105485 ] Piotr Tabor edited comment on MNG-2871 at 8/22/07 9:44 PM: --- Clean (i hope) view of this issue: The problem could be called "internal dependencies" in reactor when everything is build by phase lower then "package". The real jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in "package" phase. So if we call "mvn test" for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail. I see there two options: a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call "mvn test"' to do the tests... call mvn package instead. at least we can add warning in a such a case: "Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may resolve your problem." If we decide to this solution, I can prepare such a patch. or b) Apply currently attached patches (MNG-2871-maven-project.diff, MNG-2871-core-integration-testing-2.diff) that will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact). I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need (declared ejb-client but we will link to whole jar). The problem is most annoying because maven-release-plugin calls "mvn test" after upgrading version's number... So it leads to "mvn release:prepare" failure in case of ejb-client dependencies. was: Clean (i hope) view of this issue: The problem could be called "internal dependencies" in reactor when everything is build by phase lower then "package". The real jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in "package" phase. So if we call "mvn test" for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail. I see there two options: a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call "mvn test"' to do the tests... call mvn package instead. at least we can add warning in a such a case: "Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may resolve your problem." If we decide to this solution, I can prepare such a patch. or b) Apply currently attached patches (MNG-2871-maven-project.diff, MNG-2871-core-integration-testing-2.diff) that will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact). I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need. The problem is most annoying because maven-release-plugin calls "mvn test" after upgrading version's number... So it leads to "mvn release:prepare" failure in case of ejb-client dependencies. > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, > MNG-2871-core-integration-testing-2.diff, > MNG-2871-core-integration-tests.diff, MNG-2871-maven-project.diff, root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configurat
[jira] Issue Comment Edited: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out
[ http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105495 ] Teodoro Cue Jr. edited comment on CONTINUUM-1387 at 8/23/07 1:18 AM: - Using Jesse's solution, I was able to add a new remove() method on plexus-taskqueue. Then use that method on DefaultContinuum to remove the task in the checkout queue. Patch attached. But it is dependent on PLXCOMP-82. was: Using Jesse's solution, I was able to add a new remove() method on plexus-taskqueue and used that on DefaultContinuum to remove the task on the checkout queue. Patch attached. But it is dependent on PLXCOMP-82. > Can't initiate a build of a new project in continuum until all modules have > been checked out > > > Key: CONTINUUM-1387 > URL: http://jira.codehaus.org/browse/CONTINUUM-1387 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Wendy Smoak >Assignee: Teodoro Cue Jr. > Attachments: CONTINUUM-1387.patch > > > When a multi-module project is added to continuum, a working copy of each > module is extracted from subversion. > Typically after adding a project I want to kick off a build. > If I initiate the build before all the modules are extracted, the ones that > have not yet been fully extracted will not be queued for build. Only those > already fully extracted will be built. -- 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-1387) Can't initiate a build of a new project in continuum until all modules have been checked out
[ http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodoro Cue Jr. updated CONTINUUM-1387: --- Attachment: CONTINUUM-1387.patch Using Jesse's solution, I was able to add a new remove() method on plexus-taskqueue and used that on DefaultContinuum to remove the task on the checkout queue. Patch attached. But it is dependent on PLXCOMP-82. > Can't initiate a build of a new project in continuum until all modules have > been checked out > > > Key: CONTINUUM-1387 > URL: http://jira.codehaus.org/browse/CONTINUUM-1387 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Wendy Smoak >Assignee: Teodoro Cue Jr. > Attachments: CONTINUUM-1387.patch > > > When a multi-module project is added to continuum, a working copy of each > module is extracted from subversion. > Typically after adding a project I want to kick off a build. > If I initiate the build before all the modules are extracted, the ones that > have not yet been fully extracted will not be queued for build. Only those > already fully extracted will be built. -- 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
