[jira] Closed: (SCM-393) Add option to pass in a list of profiles to scm:bootstrap
[ http://jira.codehaus.org/browse/SCM-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-393. Resolution: Fixed Revision: 681929 Author: dantran Date: 7:48:19 PM, Friday, August 01, 2008 Message: SCM-393: Add option to pass in a list of profiles to scm:bootstrap Modified : /maven/scm/trunk/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/BootstrapMojo.java tested with internal build system. > Add option to pass in a list of profiles to scm:bootstrap > - > > Key: SCM-393 > URL: http://jira.codehaus.org/browse/SCM-393 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 1.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.1 > > > Currently we can only passing in one profile using a backdoor > ex: mvn scm:bootstrap -DconnectionUrl=xyz -Dgoals="goal1,goal2,-PmyProfiles" > The new option will do this > mvn scm:bootstrap -DconnectionUrl=xyz -Dprofiles=profile1,profile2,profile2 > -Dgoals=goal1,goal2 -- 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: (SCM-393) Add option to pass in a list of profiles to scm:bootstrap
[ http://jira.codehaus.org/browse/SCM-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-393: - Summary: Add option to pass in a list of profiles to scm:bootstrap (was: Add option to pass in a list of profiles scm:bootstrap) > Add option to pass in a list of profiles to scm:bootstrap > - > > Key: SCM-393 > URL: http://jira.codehaus.org/browse/SCM-393 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 1.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.1 > > > Currently we can only passing in one profile using a backdoor > ex: mvn scm:bootstrap -DconnectionUrl=xyz -Dgoals="goal1,goal2,-PmyProfiles" > The new option will do this > mvn scm:bootstrap -DconnectionUrl=xyz -Dprofiles=profile1,profile2,profile2 > -Dgoals=goal1,goal2 -- 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: (SCM-393) Add option to pass in a list of profiles scm:bootstrap
[ http://jira.codehaus.org/browse/SCM-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-393: - Fix Version/s: 1.1 Component/s: maven-plugin Summary: Add option to pass in a list of profiles scm:bootstrap (was: Add option to passing a list of profiles into scm:bootstrap) > Add option to pass in a list of profiles scm:bootstrap > -- > > Key: SCM-393 > URL: http://jira.codehaus.org/browse/SCM-393 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 1.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.1 > > > Currently we can only passing in one profile using a backdoor > ex: mvn scm:bootstrap -DconnectionUrl=xyz -Dgoals="goal1,goal2,-PmyProfiles" > The new option will do this > mvn scm:bootstrap -DconnectionUrl=xyz -Dprofiles=profile1,profile2,profile2 > -Dgoals=goal1,goal2 -- 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-393) Add option to passing a list of profiles into scm:bootstrap
Add option to passing a list of profiles into scm:bootstrap --- Key: SCM-393 URL: http://jira.codehaus.org/browse/SCM-393 Project: Maven SCM Issue Type: New Feature Affects Versions: 1.1 Reporter: Dan Tran Currently we can only passing in one profile using a backdoor ex: mvn scm:bootstrap -DconnectionUrl=xyz -Dgoals="goal1,goal2,-PmyProfiles" The new option will do this mvn scm:bootstrap -DconnectionUrl=xyz -Dprofiles=profile1,profile2,profile2 -Dgoals=goal1,goal2 -- 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-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith --- Key: MAVENUPLOAD-2164 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 Project: Maven Upload Requests Issue Type: Wish Reporter: Joern Huxhorn "de.huxhorn.sulky","[EMAIL PROTECTED]:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern Huxhorn","[EMAIL PROTECTED]",, "de.huxhorn.lilith","[EMAIL PROTECTED]:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern Huxhorn","[EMAIL PROTECTED]",, This request is actually about two projects, sulky and lilith. I added both URLs - as project and contributor URL. I sincerely hope that I've done everything correctly since this is my very first submission to the central maven repository. I own the domain huxhorn.de as you can verify on http://www.denic.de Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de I'm also the sole developer registered in the respective sourceforge projects http://sf.net/projects/sulky and http://sf.net/projects/lilith Since this form *requires* an upload bundle URL I entered a URL to the comma separated sync file... Please let me know if everything is OK or if somethings still wrong/missing. Thank you. -- 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: (MPH-30) help:describe should accept "cmd" argument
[ http://jira.codehaus.org/browse/MPH-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPH-30. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 fixed in r681903, snapshot deployed. > help:describe should accept "cmd" argument > -- > > Key: MPH-30 > URL: http://jira.codehaus.org/browse/MPH-30 > Project: Maven 2.x Help Plugin > Issue Type: New Feature >Reporter: Dan Fabulich >Assignee: Vincent Siveton > Fix For: 2.1 > > > In a lot of cases, people want help about Maven commands without really > knowing exactly what their plugin's artifactId/groupId is. Many people at my > work are perennially unclear about the distinction between a lifecycle phase > like "compile" and a plugin goal like "compiler:compile". > help:describe should allow the user to specify an arbitrary command with > "cmd", they could then type "mvn help:describe -Dcmd=install" to get > information about the install lifecycle phase, or "mvn help:describe > -Dcmd=compiler:compile" to get information about the compiler plugin's > compile goal. -- 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: (MEV-593) update .ssh/known_hosts for vraptor.org
update .ssh/known_hosts for vraptor.org --- Key: MEV-593 URL: http://jira.codehaus.org/browse/MEV-593 Project: Maven Evangelism Issue Type: Wish Reporter: Fabio Kung Our server has changed and we've lost the old rsa fingerprint. Could you please update your /home/maven/.ssh/known_hosts vraptor.org entry to 0c:f9:fa:87:1d:a6:41:fe:e1:47:d2:7c:ed:a6:a6:c1 ? I'm receiving the following rsync failure: --- Some repositories were not synchronized --- groupId: org.vraptor Error: @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 0c:f9:fa:87:1d:a6:41:fe:e1:47:d2:7c:ed:a6:a6:c1. Please contact your system administrator. Add correct host key in /home/maven/.ssh/known_hosts to get rid of this message. Offending key in /home/maven/.ssh/known_hosts:15 RSA host key for vraptor.org has changed and you have requested strict checking. Host key verification failed. rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(453) [receiver=2.6.9] Error synchronizing metadata. Exit code: 12 Thanks. -- 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-3122) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml
[
http://jira.codehaus.org/browse/MNG-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143911#action_143911
]
Sander Verhagen commented on MNG-3122:
--
I'm figuring out if I'm suffering from the same issue, or something different?
A lot of duplication going on in active-profiles output. I'm using an entirely
default settings.xml.
{{C:\SVN_WA\unity-Sources\rootproject\rootprojectdesktop>mvn
help:active-profiles}}
{{[INFO] Scanning for projects...}}
{{[INFO] Reactor build order:}}
{{[INFO] rootprojectdesktop}}
{{[INFO] orbitservices}}
{{[INFO] webuiapplet}}
{{[INFO] Searching repository for plugin with prefix: 'help'.}}
{{[INFO]
}}
{{[INFO] Building rootprojectdesktop}}
{{[INFO]task-segment: [help:active-profiles] (aggregator-style)}}
{{[INFO]
}}
{{[INFO] [help:active-profiles]}}
{{[INFO]}}
{{Active Profiles for Project
'com.wps.rd.unity:rootprojectdesktop:pom:0.0.5-SNAPSHOT':}}
{{The following profiles are active:}}
{{- profile-version-latest (source: pom)}}
{{Active Profiles for Project
'com.wps.rd.unity:orbitservices:jar:0.0.5-SNAPSHOT':}}
{{The following profiles are active:}}
{{- profile-version-latest (source: pom)}}
{{- profile-version-latest (source: pom)}}
{{Active Profiles for Project
'com.wps.rd.unity:webuiapplet:jar:0.0.1-SNAPSHOT':}}
{{The following profiles are active:}}
{{- profile-version-latest (source: pom)}}
{{- profile-version-latest (source: pom)}}
{{- profile-version-latest (source: pom)}}
{{[INFO]
}}
{{[INFO] BUILD SUCCESSFUL}}
{{[INFO]
}}
{{[INFO] Total time: 1 second}}
{{[INFO] Finished at: Fri Aug 01 23:17:50 CEST 2008}}
{{[INFO] Final Memory: 3M/127M}}
{{[INFO]
}}
As a comparison:
{{C:\SVN_WA\unity-Sources\rootproject\rootprojectdesktop>mvn
help:active-profiles -N}}
{{[INFO] Scanning for projects...}}
{{[INFO] Searching repository for plugin with prefix: 'help'.}}
{{[INFO]
}}
{{[INFO] Building rootprojectdesktop}}
{{[INFO]task-segment: [help:active-profiles] (aggregator-style)}}
{{[INFO]
}}
{{[INFO] [help:active-profiles]}}
{{[INFO]}}
{{Active Profiles for Project
'com.wps.rd.unity:rootprojectdesktop:pom:0.0.5-SNAPSHOT':}}
{{The following profiles are active:}}
{{- profile-version-latest (source: pom)}}
{{[INFO]
}}
{{[INFO] BUILD SUCCESSFUL}}
{{[INFO]
}}
{{[INFO] Total time: 1 second}}
{{[INFO] Finished at: Fri Aug 01 23:19:00 CEST 2008}}
{{[INFO] Final Memory: 3M/127M}}
{{[INFO]
}}
> MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile
> defined in LOCAL_HOME/.m2/settings.xml
>
>
> Key: MNG-3122
> URL: http://jira.codehaus.org/browse/MNG-3122
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.7
>Reporter: Ian Berry
> Fix For: 2.0.x
>
> Attachments: duplicateActiveProfiles.JPG,
> duplicateActiveProfiles.zip, settings.xml
>
>
> MavenProject:getActiveProfiles() is returning duplicate activeByDefault
> profiles defined in LOCAL_HOME/.m2/settings.xml.
> Attached settings.xml resides in LOCAL_HOME/.m2.
> Below is part of the output of a buildInformation plugin i am writing, which
> shows profile WLS8 twice.
>
>
>default-repositories
>settings.xml
>
>
> WLS8
> settings.xml
>
>
> WLS8
> settings.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] Issue Comment Edited: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143909#action_143909 ] joakime edited comment on MNG-3580 at 8/1/08 4:01 PM: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs on the following IBM JDK / JRE's ... $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 /* Sorry about the multi-edits, my old keyboard apparently didn't survive the move without some gremlins :-( */ was (Author: joakime): I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildIntern
[jira] Issue Comment Edited: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143909#action_143909 ] joakime edited comment on MNG-3580 at 8/1/08 3:59 PM: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 was (Author: joakime): I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs with the IBM JDK 1.6.0 SR2 on Win32 And it also occurs with IBM JDK 1.5.0 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings
[jira] Reopened: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt reopened MNG-3580: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs with the IBM JDK 1.6.0 SR2 on Win32 And it also occurs with IBM JDK 1.5.0 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) > at java.lang.reflect.Method.invoke(Method.java:612) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >
[jira] Updated: (MECLIPSE-472) Bad dependencies (version & list) in .classpath whereas compilation (and dependency:tree) use the rigth one
[
http://jira.codehaus.org/browse/MECLIPSE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-472:
-
Fix Version/s: 2.5.2
> Bad dependencies (version & list) in .classpath whereas compilation (and
> dependency:tree) use the rigth one
>
>
> Key: MECLIPSE-472
> URL: http://jira.codehaus.org/browse/MECLIPSE-472
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.5.1
>Reporter: Olivier Lamy
>Assignee: Arnaud Heritier
>Priority: Critical
> Fix For: 2.5.2
>
> Attachments: screenshot-1.jpg
>
>
> Maven compilation and dependency:tree display
> org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20
> Whereas the generated .classpath contains path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> Related continuum dev email
> http://continuum.markmail.org/message/6eiyt6vgdqycc4hm?q=
> Step to reproduce :
> {code}
> svn co -r679899 https://svn.apache.org/repos/asf/continuum/trunk continuum
> && cd continuum && mvn eclipse:eclipse &&grep plexus-compone
> continuum-core/.classpath
> .
>path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> {code}
--
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-3694) plugin parameters injecting ${project.compileSourceRoots} get uninterpolated source directories
[
http://jira.codehaus.org/browse/MNG-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3694.
---
Assignee: John Casey
Resolution: Fixed
Fix Version/s: 2.0.10
fixed for RC5
> plugin parameters injecting ${project.compileSourceRoots} get uninterpolated
> source directories
> ---
>
> Key: MNG-3694
> URL: http://jira.codehaus.org/browse/MNG-3694
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.10
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> This is the cause of the javadoc plugin error in 2.0.10-RC4. It seems that
> the project's compileSourceRoots list is injected into the plugin
> configuration BEFORE the project's concrete state is calculated. This leads
> to uninterpolated compileSourceRoots being injected.
> At least, this appears to be the case.
> To reproduce:
> mvn -Dtest=foo integration-test -DfailIfNoTests=false
> -Dinvoker.mavenOpts="-Xdebug -Xnoagent -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
> -Dinvoker.test=MJAVADOC-172
> {noformat}
> brett_: reactor projects are not concrete
> [10:42am] brett_: project itself is fine, reactorProjects are not
> [10:42am] jdcasey_: any project references should be made concrete, I added
> that in DefaultMavenProjectBuilder.calculateConcreteState(..)
> [10:42am] jdcasey_: brett: does it only happen in @aggregator mode?
> [10:44am] brett_: no
> [10:44am] brett_: it has @execute phase, but not @aggregator
> [10:44am] jdcasey_: hmm
> [10:44am] brett_: but it's not project references as such
> [10:44am] jdcasey_: brett: is it running as a report when this happens, or as
> a mojo?
> [10:44am] brett_: it's ${reactorProjects}
> [10:44am] jdcasey_: oh?
> [10:44am] jdcasey_: oh
> [10:44am] brett_: as a mojo
> [10:44am] jdcasey_: damn
> [10:45am] jdcasey_: I guess I'll need to calculate concrete state for the
> whole reactor each time? ugh. I mean...ugh.
> [10:45am] jdcasey_: that'll be slow
> [10:46am] brett_: wouldn't they be made concrete once after complete loading?
> [10:47am] jdcasey_: brett_: if any of the information in the build section
> changes as a result of plugin execution, those changes wouldn't be reflected
> in subsequent plugin executions
> [10:47am] jdcasey_: like outputDirectory, for one big example
> [10:47am] jdcasey_: that's what started all this
> [10:47am] jdcasey_: theoretically, we could probably leave the
> compileSourceRoots alone, but instrumentors could need that to change as well
> [10:48am] jdcasey_: for forking, you know?
> [10:48am] brett_: yeah
> [10:48am] jdcasey_: brett_: the problem in 2.0.9 is that our interpolation
> got a little too good, and didn't leave enough for the
> PluginParameterExpressionEvaluator
> [10:48am] jdcasey_:
> [10:48am] jdcasey_: tricky, to say the least
> [10:49am] brett_: when is th eproject made concrete now?
> [10:50am] jdcasey_: brett: just before plugin execution, inside
> executeMojo(), and then it's rolled back to dynamic state just after
> [10:50am] jdcasey_: also, just before grabbing the report instance, and then
> rolled back just before the report instance is passed back
> [10:51am] jdcasey_: it actually doesn't seem to have imposed too great a
> penalty so far, but this could be harder
> [10:51am] jdcasey_: not sure
> [10:51am] jdcasey_: we really need to get this aggregation stuff figured
> out...${reactorProjects} was always meant to be used with an aggregator,
> IIRC...
> [10:52am] brett_: yeah - and it is an aggregator, just conditionally
> [10:52am] jdcasey_: yup, I know
> [10:52am] brett_: so maybe you could make them concrete on lookup from the
> plugin parameter expression evaluator?
> [10:53am] jdcasey_: brett_: the problem is, there's nothing stopping a mojo
> from using ${session} and then pulling the reactor projects from there...
> [10:53am] jdcasey_: hmm, maybe
> [10:53am] brett_: right
> [10:54am] brett_: maybe the reactor projects can be concerete copies?
> [10:54am] brett_: since they will only be used before they are built
> [10:54am] jdcasey_: so I'd need to watch ${project.*} and ${session.*} and
> make the current project +refs concrete in the first case, and all projects
> concrete in the second...
> [10:55am] jdcasey_: then, after the mojo is executed and/or report instance
> is passed back, restore dynamism for all reactor projects
> [10:55am] brett_: I'd need to think it through, but they should be able to be
> made concrete up front since the aggregator runs first and they only get
> modified in their later builds
> [10:56am] brett_: avoid messing with the lookup
> [10:56am] jdcasey_: the lookup?
> [10:56am] bre
[jira] Updated: (MRELEASE-220) Add property to keep released versions for dependencies
[ http://jira.codehaus.org/browse/MRELEASE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRELEASE-220: - Fix Version/s: (was: 2.0-beta-8) Remove Fix Version, since there has been no response from users. > Add property to keep released versions for dependencies > --- > > Key: MRELEASE-220 > URL: http://jira.codehaus.org/browse/MRELEASE-220 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Daniel Beland >Assignee: Emmanuel Venisse > > When I release a project with many modules with internal dependencies. > I would like those dependencies to keep the released version rather than the > next development version. > ie: I only release some modules at a time (those that were changed only since > last release). > So when my webapp is released, I want it to become SNAPSHOT again(as it is > done already) but want the internal dependencies to keep the released version. > I want to update them manually whenever I change one. -- 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: (MRELEASE-214) scm:tag with scmCommentPrefix
[ http://jira.codehaus.org/browse/MRELEASE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRELEASE-214. Resolution: Fixed Fix Version/s: (was: 2.0-beta-8) 2.0-beta-7 According to Nick this was fixed in beta-7. > scm:tag with scmCommentPrefix > - > > Key: MRELEASE-214 > URL: http://jira.codehaus.org/browse/MRELEASE-214 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.0-beta-5 > Environment: macosx >Reporter: fabio melen >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-7 > > > My svn repository use a pre-commit hook in order to check the commit message > and to validate it (Trac integration). So I'd like that the scm:tag, invoked > from release:prepare, inherits the scmCommentPrefix value. > ciao > fabio -- 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-3694) plugin parameters injecting ${project.compileSourceRoots} get uninterpolated source directories
plugin parameters injecting ${project.compileSourceRoots} get uninterpolated
source directories
---
Key: MNG-3694
URL: http://jira.codehaus.org/browse/MNG-3694
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.10
Reporter: John Casey
This is the cause of the javadoc plugin error in 2.0.10-RC4. It seems that the
project's compileSourceRoots list is injected into the plugin configuration
BEFORE the project's concrete state is calculated. This leads to uninterpolated
compileSourceRoots being injected.
At least, this appears to be the case.
To reproduce:
mvn -Dtest=foo integration-test -DfailIfNoTests=false
-Dinvoker.mavenOpts="-Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
-Dinvoker.test=MJAVADOC-172
{noformat}
brett_: reactor projects are not concrete
[10:42am] brett_: project itself is fine, reactorProjects are not
[10:42am] jdcasey_: any project references should be made concrete, I added
that in DefaultMavenProjectBuilder.calculateConcreteState(..)
[10:42am] jdcasey_: brett: does it only happen in @aggregator mode?
[10:44am] brett_: no
[10:44am] brett_: it has @execute phase, but not @aggregator
[10:44am] jdcasey_: hmm
[10:44am] brett_: but it's not project references as such
[10:44am] jdcasey_: brett: is it running as a report when this happens, or as a
mojo?
[10:44am] brett_: it's ${reactorProjects}
[10:44am] jdcasey_: oh?
[10:44am] jdcasey_: oh
[10:44am] brett_: as a mojo
[10:44am] jdcasey_: damn
[10:45am] jdcasey_: I guess I'll need to calculate concrete state for the whole
reactor each time? ugh. I mean...ugh.
[10:45am] jdcasey_: that'll be slow
[10:46am] brett_: wouldn't they be made concrete once after complete loading?
[10:47am] jdcasey_: brett_: if any of the information in the build section
changes as a result of plugin execution, those changes wouldn't be reflected in
subsequent plugin executions
[10:47am] jdcasey_: like outputDirectory, for one big example
[10:47am] jdcasey_: that's what started all this
[10:47am] jdcasey_: theoretically, we could probably leave the
compileSourceRoots alone, but instrumentors could need that to change as well
[10:48am] jdcasey_: for forking, you know?
[10:48am] brett_: yeah
[10:48am] jdcasey_: brett_: the problem in 2.0.9 is that our interpolation got
a little too good, and didn't leave enough for the
PluginParameterExpressionEvaluator
[10:48am] jdcasey_:
[10:48am] jdcasey_: tricky, to say the least
[10:49am] brett_: when is th eproject made concrete now?
[10:50am] jdcasey_: brett: just before plugin execution, inside executeMojo(),
and then it's rolled back to dynamic state just after
[10:50am] jdcasey_: also, just before grabbing the report instance, and then
rolled back just before the report instance is passed back
[10:51am] jdcasey_: it actually doesn't seem to have imposed too great a
penalty so far, but this could be harder
[10:51am] jdcasey_: not sure
[10:51am] jdcasey_: we really need to get this aggregation stuff figured
out...${reactorProjects} was always meant to be used with an aggregator, IIRC...
[10:52am] brett_: yeah - and it is an aggregator, just conditionally
[10:52am] jdcasey_: yup, I know
[10:52am] brett_: so maybe you could make them concrete on lookup from the
plugin parameter expression evaluator?
[10:53am] jdcasey_: brett_: the problem is, there's nothing stopping a mojo
from using ${session} and then pulling the reactor projects from there...
[10:53am] jdcasey_: hmm, maybe
[10:53am] brett_: right
[10:54am] brett_: maybe the reactor projects can be concerete copies?
[10:54am] brett_: since they will only be used before they are built
[10:54am] jdcasey_: so I'd need to watch ${project.*} and ${session.*} and make
the current project +refs concrete in the first case, and all projects concrete
in the second...
[10:55am] jdcasey_: then, after the mojo is executed and/or report instance is
passed back, restore dynamism for all reactor projects
[10:55am] brett_: I'd need to think it through, but they should be able to be
made concrete up front since the aggregator runs first and they only get
modified in their later builds
[10:56am] brett_: avoid messing with the lookup
[10:56am] jdcasey_: the lookup?
[10:56am] brett_: ppee
[10:56am] jdcasey_: hmm
[10:57am] brett_: think it over
[10:57am] brett_: night!
[10:57am] jdcasey_: the reactor projects list isn't filled with static
instances, though...and it won't run up front unless it declares @aggregator
{noformat}
--
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/j
[jira] Closed: (MNG-3693) Updating project POM via project.setFile(..) changes project basedir, and project classpath when used as a dependency in a reactor
[
http://jira.codehaus.org/browse/MNG-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3693.
---
Assignee: John Casey
Resolution: Fixed
> Updating project POM via project.setFile(..) changes project basedir, and
> project classpath when used as a dependency in a reactor
> --
>
> Key: MNG-3693
> URL: http://jira.codehaus.org/browse/MNG-3693
> Project: Maven 2
> Issue Type: Bug
> Components: POM, Reactor and workspace
>Affects Versions: 2.0.10
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> When a reactor build contains an interproject dependency, and the dependency
> project's build switches the project's POM file, the dependent project may
> get the wrong classpath for the dependency project as long as it references
> ${basedir}/target/classes.
> For example, the shade plugin produces a dependency-reduced POM, and sets it
> on the project instance using project.setFile(..). This act reorients the
> project's basedir according to the new POM, which can return the wrong
> location for the build.outputDirectory (since this is now based on
> build.directory, which is now based on basedir).
--
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: (MASSEMBLY-245) Manifest Section configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-245. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.2-beta-3 Fixed in r681782. New 2.2-beta-3-SNAPSHOT deployed. > Manifest Section configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer >Assignee: Dennis Lundberg > Fix For: 2.2-beta-3 > > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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: (MSHARED-50) Manifest sections are only added to the manifest when the archive is created
[ http://jira.codehaus.org/browse/MSHARED-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSHARED-50. -- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: maven-archiver-2.4 Fixed in r681754. > Manifest sections are only added to the manifest when the archive is created > > > Key: MSHARED-50 > URL: http://jira.codehaus.org/browse/MSHARED-50 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-archiver >Affects Versions: maven-archiver-2.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: maven-archiver-2.4 > > > Maven Assembly Plugin uses a MavenArchiveConfiguration object to get the > configuration from the POM. Then it uses MavenArchiver.getManifest( > MavenProject, MavenArchiveConfiguration ) to create a manifest. This is then > fed into PlexusArchiver. Currently Maven Archiver adds Manifest Sections to > the manifest Object *only* if an actual archive is created. So Maven Assembly > Plugin doesn't get this part of the configuration. I don't see any reason for > keeping this part from the user until they create an archive. -- 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-245) Manifest Section configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143893#action_143893 ] Dennis Lundberg commented on MASSEMBLY-245: --- Petar's configuration works if it is upgraded to 2.2-beta-2. Nicolas' configuration doesn't work. > Manifest Section configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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-245) Manifest Section configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-245: -- Summary: Manifest Section configuration does not work properly (was: Manifest configuration does not work properly) Manifest entries was fixed in 2.2-beta-2, but manifest sections doesn't work. > Manifest Section configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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-121) Custom manifest attributres are ignored.
[
http://jira.codehaus.org/browse/MASSEMBLY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143884#action_143884
]
Dennis Lundberg commented on MASSEMBLY-121:
---
Petar, what is it that isn't working for you?
Can you please supply us with your configuration.
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-plugin.patch, massembly121.zip
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
> ${project.build.directory}
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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: (MSHARED-50) Manifest sections are only added to the manifest when the archive is created
Manifest sections are only added to the manifest when the archive is created Key: MSHARED-50 URL: http://jira.codehaus.org/browse/MSHARED-50 Project: Maven Shared Components Issue Type: Bug Components: maven-archiver Affects Versions: maven-archiver-2.3 Reporter: Dennis Lundberg Maven Assembly Plugin uses a MavenArchiveConfiguration object to get the configuration from the POM. Then it uses MavenArchiver.getManifest( MavenProject, MavenArchiveConfiguration ) to create a manifest. This is then fed into PlexusArchiver. Currently Maven Archiver adds Manifest Sections to the manifest Object *only* if an actual archive is created. So Maven Assembly Plugin doesn't get this part of the configuration. I don't see any reason for keeping this part from the user until they create an archive. -- 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-3693) Updating project POM via project.setFile(..) changes project basedir, and project classpath when used as a dependency in a reactor
[
http://jira.codehaus.org/browse/MNG-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3693:
Fix Version/s: 2.0.10
Initially reported steps to reproduce:
svn co https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico
cd pico
mvn install
> Updating project POM via project.setFile(..) changes project basedir, and
> project classpath when used as a dependency in a reactor
> --
>
> Key: MNG-3693
> URL: http://jira.codehaus.org/browse/MNG-3693
> Project: Maven 2
> Issue Type: Bug
> Components: POM, Reactor and workspace
>Affects Versions: 2.0.10
>Reporter: John Casey
> Fix For: 2.0.10
>
>
> When a reactor build contains an interproject dependency, and the dependency
> project's build switches the project's POM file, the dependent project may
> get the wrong classpath for the dependency project as long as it references
> ${basedir}/target/classes.
> For example, the shade plugin produces a dependency-reduced POM, and sets it
> on the project instance using project.setFile(..). This act reorients the
> project's basedir according to the new POM, which can return the wrong
> location for the build.outputDirectory (since this is now based on
> build.directory, which is now based on basedir).
--
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-3693) Updating project POM via project.setFile(..) changes project basedir, and project classpath when used as a dependency in a reactor
Updating project POM via project.setFile(..) changes project basedir, and
project classpath when used as a dependency in a reactor
--
Key: MNG-3693
URL: http://jira.codehaus.org/browse/MNG-3693
Project: Maven 2
Issue Type: Bug
Components: POM, Reactor and workspace
Affects Versions: 2.0.10
Reporter: John Casey
When a reactor build contains an interproject dependency, and the dependency
project's build switches the project's POM file, the dependent project may get
the wrong classpath for the dependency project as long as it references
${basedir}/target/classes.
For example, the shade plugin produces a dependency-reduced POM, and sets it on
the project instance using project.setFile(..). This act reorients the
project's basedir according to the new POM, which can return the wrong location
for the build.outputDirectory (since this is now based on build.directory,
which is now based on basedir).
--
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-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MJAVADOC-211. - Resolution: Won't Fix Fix Version/s: (was: 2.5) > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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: (MECLIPSE-472) Bad dependencies (version & list) in .classpath whereas compilation (and dependency:tree) use the rigth one
[
http://jira.codehaus.org/browse/MECLIPSE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-472:
-
Attachment: screenshot-1.jpg
Dependencies are fine with m2eclipse
> Bad dependencies (version & list) in .classpath whereas compilation (and
> dependency:tree) use the rigth one
>
>
> Key: MECLIPSE-472
> URL: http://jira.codehaus.org/browse/MECLIPSE-472
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.5.1
>Reporter: Olivier Lamy
>Priority: Critical
> Attachments: screenshot-1.jpg
>
>
> Maven compilation and dependency:tree display
> org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20
> Whereas the generated .classpath contains path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> Related continuum dev email
> http://continuum.markmail.org/message/6eiyt6vgdqycc4hm?q=
> Step to reproduce :
> {code}
> svn co -r679899 https://svn.apache.org/repos/asf/continuum/trunk continuum
> && cd continuum && mvn eclipse:eclipse &&grep plexus-compone
> continuum-core/.classpath
> .
>path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> {code}
--
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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143868#action_143868 ] Seth Gottlieb commented on MPCHECKSTYLE-20: --- I have had this problem (using Ant) too and setting the path did not fix. It appears that the issue is that it cannot handle multiple @throws. I had @throws ServletException, IOException. When I changed it to just ServletException it worked fine. The major hint for me was that the error message had a comma on the end: 'Unable to get class information for @throws tag 'javax.servlet.ServletException,' > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- 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: (MECLIPSE-472) Bad dependencies (version & list) in .classpath whereas compilation (and dependency:tree) use the rigth one
[
http://jira.codehaus.org/browse/MECLIPSE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-472:
-
Summary: Bad dependencies (version & list) in .classpath whereas
compilation (and dependency:tree) use the rigth one (was: Bad dependency
version in .classpath whereas compilation (and dependency:tree) use the rigth
one )
> Bad dependencies (version & list) in .classpath whereas compilation (and
> dependency:tree) use the rigth one
>
>
> Key: MECLIPSE-472
> URL: http://jira.codehaus.org/browse/MECLIPSE-472
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.5.1
>Reporter: Olivier Lamy
>Priority: Critical
>
> Maven compilation and dependency:tree display
> org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20
> Whereas the generated .classpath contains path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> Related continuum dev email
> http://continuum.markmail.org/message/6eiyt6vgdqycc4hm?q=
> Step to reproduce :
> {code}
> svn co -r679899 https://svn.apache.org/repos/asf/continuum/trunk continuum
> && cd continuum && mvn eclipse:eclipse &&grep plexus-compone
> continuum-core/.classpath
> .
>path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> {code}
--
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: (MECLIPSE-472) Bad dependency version in .classpath whereas compilation (and dependency:tree) use the rigth one
[
http://jira.codehaus.org/browse/MECLIPSE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143866#action_143866
]
Arnaud Heritier commented on MECLIPSE-472:
--
The number of dependencies is also wrong.
For example, we have a project with those dependencies :
{code}
[INFO] [dependency:list]
[INFO]
[INFO] The following files have been resolved:
[INFO]com.sun.facelets:jsf-facelets:jar:1.1.14:compile
[INFO]commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO]commons-digester:commons-digester:jar:1.8:compile
[INFO]javax.persistence:persistence-api:jar:1.0:provided
[INFO]junit:junit:jar:3.8.1:test
[INFO]org.jboss.el:jboss-el:jar:2.0.1.GA:compile
[INFO]org.jboss.seam:jboss-seam:jar:2.0.2.SP1:compile
[INFO]org.jboss.seam:jboss-seam-debug:jar:2.0.2.SP1:compile
[INFO]org.jboss.seam:jboss-seam-ui:jar:2.0.2.SP1:compile
[INFO]org.richfaces.framework:richfaces-api:jar:3.1.4.GA:compile
[INFO]org.richfaces.framework:richfaces-impl:jar:3.1.4.GA:compile
[INFO]org.richfaces.ui:richfaces-ui:jar:3.1.4.GA:compile
[INFO]org.testng:testng:jar:jdk15:5.8:test
{code}
The tree of dependencies is :
{code}
[INFO] [dependency:tree]
[INFO] fr.test.seam.archetype.simple:web:war:1.0-SNAPSHOT
[INFO] +- com.sun.facelets:jsf-facelets:jar:1.1.14:compile
[INFO] +- org.richfaces.framework:richfaces-api:jar:3.1.4.GA:compile
[INFO] | \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] +- org.richfaces.framework:richfaces-impl:jar:3.1.4.GA:compile
[INFO] | \- commons-digester:commons-digester:jar:1.8:compile
[INFO] +- org.richfaces.ui:richfaces-ui:jar:3.1.4.GA:compile
[INFO] +- org.jboss.seam:jboss-seam:jar:2.0.2.SP1:compile
[INFO] | \- org.jboss.el:jboss-el:jar:2.0.1.GA:compile
[INFO] +- org.jboss.seam:jboss-seam-debug:jar:2.0.2.SP1:compile
[INFO] +- org.jboss.seam:jboss-seam-ui:jar:2.0.2.SP1:compile
[INFO] +- javax.persistence:persistence-api:jar:1.0:provided
[INFO] \- org.testng:testng:jar:jdk15:5.8:test
[INFO]\- junit:junit:jar:3.8.1:test
{code}
But in the .classpath we have :
{code}
{code}
> Bad dependency version in .classpath whereas compilation (and
> dependency:tree) use the rigth one
> -
>
> Key: MECLIPSE-472
> URL: http://jira.codehaus.org/browse/MECLIPSE-472
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.5.1
>Reporter: Olivier Lamy
>Priority: Critical
>
> Maven compilation and dependency:tree display
> org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20
> Whereas the generated .classpath contains path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> Related continuum dev email
> http://continuum.markmail.org/message/6eiyt6vgdqycc4hm?q=
> Step to reproduce :
> {code}
> svn co -r679899 https://svn.apache.org/repos/asf/continuum/trunk continuum
> && cd continuum && mvn eclipse:eclipse &&grep plexus-compone
> continuum-core/.classpath
> .
>path="M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar"/>
> {code}
--
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] Reopened: (MJAVADOC-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MJAVADOC-211: --- > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143863#action_143863 ] Vincent Siveton commented on MJAVADOC-211: -- bq: ah, now I see it's assigning to the protected outputDirectory. That is confusing Sorry about that. It is why we have MJAVADOC-205 ;) > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-211) create the report output directory if it doesn't exist
[
http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143862#action_143862
]
Vincent Siveton commented on MJAVADOC-211:
--
FYI the output mkdir is handle by the javadoc tool itself
See
http://www.docjar.com/docs/api/com/sun/tools/doclets/internal/toolkit/Configuration.html#generalValidOptions(String,%20DocErrorReporter)
{noformat}
...
if (!destDir.exists()) {
//Create the output directory (in case it doesn't exist yet)
reporter.printNotice(getText("doclet.dest_dir_create",
destdirname));
(new File(destdirname)).mkdirs();
{noformat}
> create the report output directory if it doesn't exist
> --
>
> Key: MJAVADOC-211
> URL: http://jira.codehaus.org/browse/MJAVADOC-211
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 2.5
>
>
> currently, the javadoc report relies on maven to have created the reporting
> base directory first. This need not be the case.
--
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-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143861#action_143861 ] Brett Porter commented on MJAVADOC-211: --- ah, now I see it's assigning to the protected outputDirectory. That is confusing :) Sorry about that. > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-3622) upgrade to wagon 1.0-beta-4
[ http://jira.codehaus.org/browse/MNG-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MNG-3622: - Summary: upgrade to wagon 1.0-beta-4 (was: upgrade to wagon beta-3) > upgrade to wagon 1.0-beta-4 > --- > > Key: MNG-3622 > URL: http://jira.codehaus.org/browse/MNG-3622 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.0.10 > > > I am scheduling this for 2.1-alpha-1, but I will also look into the > possibility of including it in 2.0.10 after consulting the dev 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: (MJAVADOC-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143859#action_143859 ] Brett Porter commented on MJAVADOC-211: --- the report directory (target/site/apidocs) is not the same as the output directory considered above (target/apidocs). While it should already exist, it's best for the plugin to act independently. I'll move it from the getter to the execute method thogh. > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-3622) upgrade to wagon beta-3
[ http://jira.codehaus.org/browse/MNG-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3622. --- Assignee: John Casey (was: Brett Porter) Resolution: Fixed Upgraded to 1.0-beta-4 to fix proxying problems. > upgrade to wagon beta-3 > --- > > Key: MNG-3622 > URL: http://jira.codehaus.org/browse/MNG-3622 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.0.10 > > > I am scheduling this for 2.1-alpha-1, but I will also look into the > possibility of including it in 2.0.10 after consulting the dev 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: (MJAVADOC-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143857#action_143857 ] Benjamin Bentmann commented on MJAVADOC-211: Crazy timing bq. Anyway, your commit is a safe one. Getters with side-effects, hm... > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-211) create the report output directory if it doesn't exist
[
http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143855#action_143855
]
Vincent Siveton commented on MJAVADOC-211:
--
This was already catched in the AbstractJavadocMojo#executeReport( Locale
unusedLocale )
{noformat}
...
File javadocOutputDirectory = new File( getOutputDirectory() );
if ( javadocOutputDirectory.exists() &&
!javadocOutputDirectory.isDirectory() )
{
throw new MavenReportException( "IOException: " +
getOutputDirectory() + " is not a directory." );
}
if ( javadocOutputDirectory.exists() &&
!javadocOutputDirectory.canWrite() )
{
throw new MavenReportException( "IOException: " +
getOutputDirectory() + " is not writable." );
}
{noformat}
So, if the output was not created the javadoc plugin should failed.
Anyway, your commit is a safe one. Thanks!
> create the report output directory if it doesn't exist
> --
>
> Key: MJAVADOC-211
> URL: http://jira.codehaus.org/browse/MJAVADOC-211
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 2.5
>
>
> currently, the javadoc report relies on maven to have created the reporting
> base directory first. This need not be the case.
--
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-211) create the report output directory if it doesn't exist
[
http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143854#action_143854
]
Benjamin Bentmann commented on MJAVADOC-211:
>From {{AbstractJavadocMojo.java:1471}}
{code:java}
// --
// Javadoc output directory as File
// --
File javadocOutputDirectory = new File( getOutputDirectory() );
if ( javadocOutputDirectory.exists() && !javadocOutputDirectory.isDirectory() )
{
throw new MavenReportException( "IOException: " + getOutputDirectory() + "
is not a directory." );
}
if ( javadocOutputDirectory.exists() && !javadocOutputDirectory.canWrite() )
{
throw new MavenReportException( "IOException: " + getOutputDirectory() + "
is not writable." );
}
javadocOutputDirectory.mkdirs();
{code}
i.e. there is already a call to {{mkdirs()}. So I wonder whether this issue was
really present or just a side effect of the (still present) failures with RC4.
> create the report output directory if it doesn't exist
> --
>
> Key: MJAVADOC-211
> URL: http://jira.codehaus.org/browse/MJAVADOC-211
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 2.5
>
>
> currently, the javadoc report relies on maven to have created the reporting
> base directory first. This need not be the case.
--
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-245) Manifest configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143851#action_143851 ] zaccret edited comment on MASSEMBLY-245 at 8/1/08 8:27 AM: -- Issue MASSEMBLY-121 not seems to be fixed was (Author: zaccret): 175 not seems to be fixed > Manifest configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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-211) create the report output directory if it doesn't exist
[ http://jira.codehaus.org/browse/MJAVADOC-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MJAVADOC-211. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.5 > create the report output directory if it doesn't exist > -- > > Key: MJAVADOC-211 > URL: http://jira.codehaus.org/browse/MJAVADOC-211 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.5 > > > currently, the javadoc report relies on maven to have created the reporting > base directory first. This need not be the case. -- 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-211) create the report output directory if it doesn't exist
create the report output directory if it doesn't exist -- Key: MJAVADOC-211 URL: http://jira.codehaus.org/browse/MJAVADOC-211 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Brett Porter Fix For: 2.5 currently, the javadoc report relies on maven to have created the reporting base directory first. This need not be the case. -- 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-245) Manifest configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143848#action_143848 ] Nicolas Dupont commented on MASSEMBLY-245: -- Same issue for me with 2.2beta2. Here is my pom.xml extract : maven-assembly-plugin section Foo com.Foo > Manifest configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143847#action_143847
]
Dave Sinclair commented on MWAR-116:
Pardon me, I got it to work. I had tried the @s around the
{artifact.artifactId}, but after looking at the source I realize it should be
only @[EMAIL PROTECTED] My bad! Thanks
> The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
>
>
> Key: MWAR-116
> URL: http://jira.codehaus.org/browse/MWAR-116
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Chris Moesel
>Assignee: Olivier Lamy
> Fix For: 2.1-alpha-2
>
> Attachments: mwar_93_webapp.zip
>
>
> I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
> the following to my POM:
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-alpha-1-SNAPSHOT
>
> ${artifactId}.${extension}
>
>
> This results in really oddly named files in my web-inf/lib now. A typical
> example:
> org.springframework-mywebapp.null
> So, the resulting files are really mapped more like: ${groupId of the
> dependency}-${artifactId of my war module}.null
> I've attached an example Maven 2 project that demonstrates this. Just run
> "mvn package" and look at the result in target.
--
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-3690) inheriting properties doesn't work if name of property is too long
[ http://jira.codehaus.org/browse/MNG-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143846#action_143846 ] Joseph Marques commented on MNG-3690: - sure, i'll see what i can pull together over the weekend. in the meantime, i'll tell you that I don't use the relativePath element explicitly in any of my poms, so it should default to "../pom.xml" from my testing, what i'm seeing happening is that it's someone reference an only version of the parent pom.xml. if i "mvn -N install" the parent, then the child will see the updated value. thanks in advance. > inheriting properties doesn't work if name of property is too long > -- > > Key: MNG-3690 > URL: http://jira.codehaus.org/browse/MNG-3690 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.9 >Reporter: Joseph Marques > > when i used a property that was 30 characters long, it wasn't propagated. > when i shortened it to only be 20, it worked. i don't know what the limit > is, but this was a very sly bug. -- 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: (SUREFIRE-510) surefire.test.class.path is not set when forkMode is always
surefire.test.class.path is not set when forkMode is always --- Key: SUREFIRE-510 URL: http://jira.codehaus.org/browse/SUREFIRE-510 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.4.2 Reporter: Carlo de Wolf -- 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-510) surefire.test.class.path is not set when forkMode is always
[ http://jira.codehaus.org/browse/SUREFIRE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143843#action_143843 ] Carlo de Wolf commented on SUREFIRE-510: Fixed in 2.4.3 > surefire.test.class.path is not set when forkMode is always > --- > > Key: SUREFIRE-510 > URL: http://jira.codehaus.org/browse/SUREFIRE-510 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4.2 >Reporter: Carlo de Wolf > -- 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-210) Unit tests fail on OS X
[ http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MJAVADOC-210. - Resolution: Fixed > Unit tests fail on OS X > --- > > Key: MJAVADOC-210 > URL: http://jira.codehaus.org/browse/MJAVADOC-210 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v > JDK 1.4 > 2.0.9 > --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v > Maven version: 2.0.9 > Java version: 1.4.2_16 > OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" > Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home >Reporter: John Casey >Assignee: Brett Porter >Priority: Critical > Fix For: 2.5 > > Attachments: build.log, MJAVADOC-210.patch, MJAVADOC-210_new.patch, > org.apache.maven.plugin.javadoc.JavadocReportTest.txt > > > I'm attaching the build console output and surefire output file for the > failing unit 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] Created: (MPIR-131) NPE in printArtifactsLocations() for blacklisted repo
NPE in printArtifactsLocations() for blacklisted repo - Key: MPIR-131 URL: http://jira.codehaus.org/browse/MPIR-131 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1 Environment: Linux (Sun JDK 1.6), Windows (IBM VM 1.4). No direct Internet access; going through local Artifactory repository. Reporter: Klaus Brunner Priority: Critical I'm getting NPEs when running the reports plugin at this location: [INFO] Generating "Dependencies" report. [WARNING] The repository url 'http://repo1.maven.org/maven2' is invalid - Repository 'central' will be blacklisted. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printArtifactsLocations(DependenciesRenderer.java:1182) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyRepositoryLocations(DependenciesRenderer.java:641) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239) Taking a brief look with the debugger, it appears that the totalByRepo map in DependenciesRenderer.printArtifactsLocations() is empty - so looking up any entry will of course return null and result in an NPE here: totalRow[idnum++] = totalByRepo.get( repokey ).toString(); Note that this used to work fine before the 2.1 release. -- 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-210) Unit tests fail on OS X
[ http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-210: - Fix Version/s: 2.5 > Unit tests fail on OS X > --- > > Key: MJAVADOC-210 > URL: http://jira.codehaus.org/browse/MJAVADOC-210 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v > JDK 1.4 > 2.0.9 > --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v > Maven version: 2.0.9 > Java version: 1.4.2_16 > OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" > Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home >Reporter: John Casey >Priority: Critical > Fix For: 2.5 > > Attachments: build.log, MJAVADOC-210.patch, MJAVADOC-210_new.patch, > org.apache.maven.plugin.javadoc.JavadocReportTest.txt > > > I'm attaching the build console output and surefire output file for the > failing unit 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-210) Unit tests fail on OS X
[ http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-210: - Attachment: MJAVADOC-210_new.patch Thanks Benjamin! I modified your patch to make getToolsJar() always returns tools.jar (win unix) or classes.jar (mac) based on [1]. John, could you review this patch since I have no QA env that uses Mac? [1] http://developer.apple.com/documentation/Java/Conceptual/Java14Development/02-JavaDevTools/JavaDevTools.html#//apple_ref/doc/uid/TP40001884-208117 > Unit tests fail on OS X > --- > > Key: MJAVADOC-210 > URL: http://jira.codehaus.org/browse/MJAVADOC-210 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v > JDK 1.4 > 2.0.9 > --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v > Maven version: 2.0.9 > Java version: 1.4.2_16 > OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" > Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home >Reporter: John Casey >Priority: Critical > Fix For: 2.5 > > Attachments: build.log, MJAVADOC-210.patch, MJAVADOC-210_new.patch, > org.apache.maven.plugin.javadoc.JavadocReportTest.txt > > > I'm attaching the build console output and surefire output file for the > failing unit 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: (MNG-3472) configuration possibilities to limit size of local repository
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143835#action_143835 ] Joerg Schaible commented on MNG-3472: - Maybe you should simply start reading docs for the Maven settings. *I* am sure that quite a lot of people do not keep the local repo in their profile ... ;-) > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: http://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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] Issue Comment Edited: (MNG-3472) configuration possibilities to limit size of local repository
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143833#action_143833 ] gskempes edited comment on MNG-3472 at 8/1/08 3:14 AM: --- Unfortunately this issue was closed, otherwise I would have voted. I think every software should address the problems it creates. Pointing to external tools is not a solution. A software cannot assume that disk space is limitless available. Because of many configuration changes yesterday, my windows profile was grown up to a size of 16 GB. I didn't notice. Since the profile is stored on the server, it will take more than 4.5 hours to login today (the network works only at 10 Mbit). Please reopen this issue and provide a solution. I'm sure you would do a favor to many people. was (Author: gskempes): Unfortunately this issue was closed, otherwise I would have voted. I think every software should address the problems it creates. Pointing to external tools is not a solution. A software cannot assume that disk space is limitless available. Because of many configuration changes yesterday, my windows profile was grown up to a size of 16 GB. I didn't notice. Since the profile is stored on the server, it will take more than 4.5 hours to login today (the network works only at 10 Mbit). Please reopen this issue and provide a solution. I'm sure you would a favor to many people. > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: http://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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-3472) configuration possibilities to limit size of local repository
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143833#action_143833 ] Georgios Skempes commented on MNG-3472: --- Unfortunately this issue was closed, otherwise I would have voted. I think every software should address the problems it creates. Pointing to external tools is not a solution. A software cannot assume that disk space is limitless available. Because of many configuration changes yesterday, my windows profile was grown up to a size of 16 GB. I didn't notice. Since the profile is stored on the server, it will take more than 4.5 hours to login today (the network works only at 10 Mbit). Please reopen this issue and provide a solution. I'm sure you would a favor to many people. > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: http://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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] Updated: (SUREFIRE-502) Specified classesDirectory is added to the end of the classpath
[
http://jira.codehaus.org/browse/SUREFIRE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M. Dahm updated SUREFIRE-502:
-
Attachment: SurefirePlugin.java
Well, here comes the code in a more readable fashion...
> Specified classesDirectory is added to the end of the classpath
> ---
>
> Key: SUREFIRE-502
> URL: http://jira.codehaus.org/browse/SUREFIRE-502
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.3
> Environment: Windows Vista SP1, Java 1.5.0_13, Maven 2.0.9
>Reporter: James Shiell
> Attachments: SUREFIRE-502.patch, SurefirePlugin.java
>
>
> When you specify a classesDirectory in the configuration element of the
> Surefire plugin definition the classesDirectory is appended to the end of the
> classpath rather than replacing the build output directory. This means
> included dependencies take precedence over your source code.
> The problem appears to be the following code:
> if ( !project.getBuild().getOutputDirectory().equals(
> classesDirectory.getAbsolutePath() ) )
> {
> classpathElements.remove( project.getBuild().getOutputDirectory()
> );
> classpathElements.add( classesDirectory.getAbsolutePath() );
> }
> The classes directory should replace the build output directory, e.g.
> if ( !project.getBuild().getOutputDirectory().equals(
> classesDirectory.getAbsolutePath() ) )
> {
> final int replacementIndex =
> classpathElements.indexOf(project.getBuild().getOutputDirectory());
> if (replacementIndex >= 0)
> {
>classpathElements.remove(
> project.getBuild().getOutputDirectory() );
>classpathElements.add( replacementIndex,
> classesDirectory.getAbsolutePath() );
>}
> else
>{
>classpathElements.add( classesDirectory.getAbsolutePath()
> );
>}
> }
--
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-502) Specified classesDirectory is added to the end of the classpath
[
http://jira.codehaus.org/browse/SUREFIRE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143830#action_143830
]
M. Dahm commented on SUREFIRE-502:
--
the original code looks like this:
getLog().debug("Test Classpath :");
// Check if we need to add configured classes/test classes directories here.
// If they are configured, we should remove the default to avoid conflicts.
// Check if we need to add configured classes/test classes directories
here.
// If they are configured, we should remove the default to avoid
conflicts.
if ( !project.getBuild().getOutputDirectory().equals(
classesDirectory.getAbsolutePath() ) )
{
getLog().debug( "Warning: changing classpath! " +
project.getBuild().getOutputDirectory() + " != " +
classesDirectory.getAbsolutePath() );
classpathElements.remove( project.getBuild().getOutputDirectory() );
classpathElements.add( classesDirectory.getAbsolutePath() );
}
if ( !project.getBuild().getTestOutputDirectory().equals(
testClassesDirectory.getAbsolutePath() ) )
{
getLog().debug( "Warning: changing classpath! " +
project.getBuild().getTestOutputDirectory() + " != " +
testClassesDirectory.getAbsolutePath() );
classpathElements.remove(
project.getBuild().getTestOutputDirectory() );
classpathElements.add( testClassesDirectory.getAbsolutePath() );
}
However there are two problems here:
1.) In a Windows environment (which I'm forced to use ... :-) the may be paths
with mixed separators like C:\foo\bar/target/classes.
This cause the above equals() to return false, also the paths may not be
different actually.
2.) The order of the classes and the test-classes folder may be swapped if both
if() apply
I'd suggest the following code which uses Files to compare the paths and
ensures that the test class path entry always comes first:
getLog().debug("Test Classpath :");
// Check if we need to add configured classes/test classes directories here.
// If they are configured, we should remove the default to avoid conflicts.
// Ensure that test classes always come first
final File outputDirectory = new
File(project.getBuild().getOutputDirectory());
classpathElements.remove(project.getBuild().getOutputDirectory());
final File testOutputDirectory = new
File(project.getBuild().getTestOutputDirectory());
classpathElements.remove(project.getBuild().getTestOutputDirectory());
if (outputDirectory.equals(classesDirectory)) {
// Add again at start of the list
classpathElements.add(0, outputDirectory.getAbsolutePath());
} else {
getLog().debug(
"Warning: changing classpath! " + outputDirectory.getAbsolutePath() +
" != " + classesDirectory.getAbsolutePath());
classpathElements.add(0, classesDirectory.getAbsolutePath());
}
if (testOutputDirectory.equals(testClassesDirectory)) {
// Add again at the very start of the list
classpathElements.add(0, testOutputDirectory.getAbsolutePath());
} else {
getLog().debug(
"Warning: changing classpath! " +
testOutputDirectory.getAbsolutePath() + " != "
+ testClassesDirectory.getAbsolutePath());
classpathElements.add(0, testClassesDirectory.getAbsolutePath());
}
Cheers
Markus
> Specified classesDirectory is added to the end of the classpath
> ---
>
> Key: SUREFIRE-502
> URL: http://jira.codehaus.org/browse/SUREFIRE-502
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.3
> Environment: Windows Vista SP1, Java 1.5.0_13, Maven 2.0.9
>Reporter: James Shiell
> Attachments: SUREFIRE-502.patch
>
>
> When you specify a classesDirectory in the configuration element of the
> Surefire plugin definition the classesDirectory is appended to the end of the
> classpath rather than replacing the build output directory. This means
> included dependencies take precedence over your source code.
> The problem appears to be the following code:
> if ( !project.getBuild().getOutputDirectory().equals(
> classesDirectory.getAbsolutePath() ) )
> {
> classpathElements.remove( project.getBuild().getOutputDirectory()
> );
> classpathElements.add( classesDirectory.getAbsolutePath() );
> }
> The classes directory should replace the build output directory, e.g.
> if ( !project.getBuild().getOutputDirectory().equals(
> classesDirectory.getAbsolutePath() ) )
> {
> final int replacementIndex =
> classpathElements.indexOf(project.getBuild().getOutputDirectory());
> if (replacementIndex >= 0)
> {
>classpathEleme
