[jira] Closed: (MPA-35) add Lukas Theussl to the PMC
[ http://jira.codehaus.org/browse/MPA-35?page=all ] Jason van Zyl closed MPA-35: Resolution: Fixed [EMAIL PROTECTED] board]$ svn commit committee-info.txt Sendingcommittee-info.txt Transmitting file data . Committed revision 6337. > add Lukas Theussl to the PMC > > > Key: MPA-35 > URL: http://jira.codehaus.org/browse/MPA-35 > Project: Maven Project Administration > Type: Task > Reporter: Brett Porter > Assignee: Jason van Zyl > > > Jason to add Lukas to the PMC roster in committee-info.txt 72 hours after the > creation of this issue. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-36) surefire property droppings in fork mode
surefire property droppings in fork mode Key: MSUREFIRE-36 URL: http://jira.codehaus.org/browse/MSUREFIRE-36 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Brett Porter Assigned to: Jason van Zyl when running surefire in fork mode (specifically, I'm using cobertura), the surefire.properties, surefire-classloader.properties and sometimes a file called "null" get left behind. I believe this might be when the tests fail but haven't investigated. I think these files should either be created in the tmpdir (preferred) or target, and set to delete on exit rather than delete on success. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Dec 23 06:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051223.06.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051223.06.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPA-22) Create site for surefire sub project
[ http://jira.codehaus.org/browse/MPA-22?page=all ] Jason van Zyl closed MPA-22: Resolution: Fixed Not much of a site, but a site nonetheless. > Create site for surefire sub project > > > Key: MPA-22 > URL: http://jira.codehaus.org/browse/MPA-22 > Project: Maven Project Administration > Type: Task > Components: sites > Reporter: Jason van Zyl > Assignee: Jason van Zyl > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPA-24) Setup a JIRA project for each Maven 2.x plug-in
[ http://jira.codehaus.org/browse/MPA-24?page=all ] Jason van Zyl closed MPA-24: Resolution: Fixed Yes. > Setup a JIRA project for each Maven 2.x plug-in > --- > > Key: MPA-24 > URL: http://jira.codehaus.org/browse/MPA-24 > Project: Maven Project Administration > Type: Task > Components: issue management > Reporter: Jason van Zyl > Assignee: Jason van Zyl > > > Jason is coordinating with Jeff Turner to setup a project for each Maven 2.x > plug-in. The SOAP interface will be used to automate the creation of these > project. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Dec 23 05:45:01 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20051223.054501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20051223.054501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPA-36) associate Maven svn with JIRA projects
associate Maven svn with JIRA projects -- Key: MPA-36 URL: http://jira.codehaus.org/browse/MPA-36 Project: Maven Project Administration Type: Task Components: issue management Reporter: Brett Porter Assigned to: Vincent Massol Let's do this so we can view related commits from JIRA. First need some advice on how it needs to be done: can we assign http://svn.apache.org/repos/asf/maven to all the Maven 1.x and Maven 2.x projects, or is this really bad for performance? It would still give the right results. If it needs to be separated, these are the patterns: MNG - maven/components (trunk and branches) and maven/site (if possible) MAVEN - maven/maven-1.x/core (trunk and branches) MPxxx - maven/maven-1.x/plugins/trunk/PLUGIN-NAME Mxxx - maven/plugins/trunk/PLUGIN-NAME WAGON, WAGONFTP, WAGONSSH, WAGONHTTP - maven/wagon (trunk and branches) SCM - maven/scm (trunk and branches) CONTINUUM - maven/continuum (trunk and branches) MRM - maven/repository-manager (trunk and branches) JXR - maven/jxr (trunk and branches) ARCHETYPE - maven/archetype (trunk and branches) DOXIA - maven/doxia (trunk and branches) SUREFIRE - maven/surefire (trunk and branches) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPA-20) create release issues for each plugin to track votes and preparedness
[ http://jira.codehaus.org/browse/MPA-20?page=comments#action_54105 ] Brett Porter commented on MPA-20: - is this still needed now that the projects exist? > create release issues for each plugin to track votes and preparedness > - > > Key: MPA-20 > URL: http://jira.codehaus.org/browse/MPA-20 > Project: Maven Project Administration > Type: Task > Components: issue management > Reporter: John Casey > Assignee: John Casey > Priority: Blocker > > > should be specific to one release of one plugin, and should incorporate links > to all outstanding issues for that 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPA-24) Setup a JIRA project for each Maven 2.x plug-in
[ http://jira.codehaus.org/browse/MPA-24?page=comments#action_54104 ] Brett Porter commented on MPA-24: - is this considered done? > Setup a JIRA project for each Maven 2.x plug-in > --- > > Key: MPA-24 > URL: http://jira.codehaus.org/browse/MPA-24 > Project: Maven Project Administration > Type: Task > Components: issue management > Reporter: Jason van Zyl > Assignee: Jason van Zyl > > > Jason is coordinating with Jeff Turner to setup a project for each Maven 2.x > plug-in. The SOAP interface will be used to automate the creation of these > project. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Dec 23 05:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051223.053001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051223.053001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1893) Cannot deploy artifacts using classifier
[ http://jira.codehaus.org/browse/MNG-1893?page=all ] Brett Porter closed MNG-1893: - Assign To: Brett Porter Resolution: Duplicate > Cannot deploy artifacts using classifier > > > Key: MNG-1893 > URL: http://jira.codehaus.org/browse/MNG-1893 > Project: Maven 2 > Type: Bug > Reporter: Miguel Griffa > Assignee: Brett Porter > Priority: Critical > > > The classifier concept is well understood in maven, beeing an elemnt of the > dependency. > However, a project that generates artifacs with classifiers, cannot be > deployed, nor installed: > install plugin seem to 'not see' the classifier: > this output might help: > [INFO] [jar:jar] > [INFO] Building jar: > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT-localdev.jar > [INFO] [install:install] > [INFO] Installing > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar to > /home/mgriffa/.m2/repository/transferval/tfv-core/2.1-SNAPSHOT/tfv-core-2.1-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact > Embedded error: Error installing artifact: File > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar does not > exist > jar:jar generates the artifact with the classifier, as told to do so, but > install misses it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1875) Cannot deploy artifact with classifier
[ http://jira.codehaus.org/browse/MNG-1875?page=comments#action_54103 ] Brett Porter commented on MNG-1875: --- can you compare your pom to maven-model's pom and see how it differs. It works there. > Cannot deploy artifact with classifier > -- > > Key: MNG-1875 > URL: http://jira.codehaus.org/browse/MNG-1875 > Project: Maven 2 > Type: Bug > Reporter: Miguel Griffa > Assignee: Brett Porter > > > Intro: > I have an artifact I want to deploy with different confs, I use profiles and > I want confs to be deployed, so I want somethings like > core-1.0.dev.jar > core-1.0.-test.jar > core-1.0.-prod.jar > profiles is the way to go. > The problem is how to set the name of the artifact with profiles. simple > overwriting finalName does not work, I was told to put the classifier in the > version, but this is incorrect, since all jars above should be in 1.0 dir. > putting the classifier in verison makes them appear in different version dirs. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSITE-44) make site reactor aware
[ http://jira.codehaus.org/browse/MSITE-44?page=all ] Brett Porter closed MSITE-44: - Resolution: Fixed > make site reactor aware > --- > > Key: MSITE-44 > URL: http://jira.codehaus.org/browse/MSITE-44 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Brett Porter > Assignee: Brett Porter > Priority: Blocker > Fix For: 2.0 > > Original Estimate: 8 hours >Time Spent: 16 hours > Remaining: 0 minutes > > there are a few things I'd like to do to make the sites more workable: > - it's good they can still build independantly > - however, if built from the parent, it would be good to go into aggregation > mode and pull in those separately built sites, do any dashboards and deploy > together > - some reports would aggregate themselves, as well as participate in the > dashboards (eg javadoc) > - I'd like the navigation to behave hierachically (sections of the parent > navigation marked as inherited remain on the child sites) > - this means that when building from independant projects they'd need to be > able to locate the parent site descriptor. This could be tricky without a USD > - should it fail if it is not a USD, or should the site descriptor be > published/referenced externally somehow? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Dec 23 05:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20051223.051501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20051223.051501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Dec 23 05:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051223.05.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051223.05.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Dec 23 04:45:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20051223.044500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=comments#action_54087 ] Gunnar Hillert commented on MSITE-25: - Could somebody maybe make a note under http://maven.apache.org/guides/mini/guide-deploy-ssh-external.html that this does not currently work for the site goal? Thinking that this feature is quite well documented I spent some substantial time looking for the issue on my end until I finally came accross this bug :-( Thanks! > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Alan Cabrera > Priority: Critical > Fix For: 2.0 > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
clover default?
Hi, I'm wondering what the default for clover should be: - everything as now, but set forkmode once when running the tests (this is how the cobertura plugin works - I have a patch for this if agreed) - set the thread interval settings by default so that forking is not required Thoughts? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-15) Output folders are not set correctly by 'Update Sources' action
[ http://jira.codehaus.org/browse/MNGECLIPSE-15?page=comments#action_54074 ] YOKOTA Takehiko commented on MNGECLIPSE-15: --- In fact, my strongest motivation to separate output folders per subprojects is to suppress Eclipse's warning messages about conflict of resources by copying into single output folder. So it may not be critical issue not to separate output folder, but lots of meaningless warning messages disturb development because they jam other important error messages up. > As a side note, when resources are placed in a separate folder we may use > resource folder as an output folder for Eclipse, so it won't even need to copy > anything. I'm sorry but I could not see what you meant. Could you please explain "use resource folder as an output folder for Eclipse" in detail? > Output folders are not set correctly by 'Update Sources' action > --- > > Key: MNGECLIPSE-15 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-15 > Project: Maven 2.x Plug-in for Eclipse > Type: Bug > Reporter: YOKOTA Takehiko > Assignee: Eugene Kuleshov > Attachments: patch.txt > > > Although source folders on build path are updated correctly by 'Update > Sources' action, > output folders are not updated at all. > For example, it is expected that output folder for 'src/test/java' and > 'src/test/resources' > is set to 'target/test-classes', but not set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPCHECKSTYLE-50) Check for System.out statement
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-50?page=all ] Lukas Theussl closed MPCHECKSTYLE-50: - Resolution: Won't Fix Jira is an issue tracking system, please use the mailing lists for asking questions like that. > Check for System.out statement > -- > > Key: MPCHECKSTYLE-50 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-50 > Project: maven-checkstyle-plugin > Type: Task > Reporter: Shahzad Chaudhry > > > Is there a checkstyle check for repoting warnings / errors if System.out > statements are used in src 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-268) Add relocation from acegisecurity to org.acegisecurity
[ http://jira.codehaus.org/browse/MEV-268?page=all ] Edwin Punzalan closed MEV-268: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to reach central repo. > Add relocation from acegisecurity to org.acegisecurity > -- > > Key: MEV-268 > URL: http://jira.codehaus.org/browse/MEV-268 > Project: Maven Evangelism > Type: Task > Reporter: Carlos Sanchez > Assignee: Edwin Punzalan > > > Add poms in acegisecurity for version 1.0.0-RC1 pointing to org.acegisecurity -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Fri Dec 23 00:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20051223.003001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20051223.003001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: helper mojo to add additional source root - where should it be?
ok, build-helper-maven-plugin will be in mojo's sandbox soon Thank you for all suggestions -Dan On 12/22/05, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > yep, that was what I was thinking > > On 12/22/05, dan tran <[EMAIL PROTECTED]> wrote: > > > > How about build-helper-maven-plugin? so we can focus on smaller scope? > > > > so we will have > > > > build-helper:add-source > > build-helper:add-resource. > > > > mojos to start with > > > > -D > > > > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > > > Jesse McConnell wrote: > > > > I would lean towards a generalized project utilities mojohosted > at > > > mojo > > > > that does things like add new source roots, do minor post compile > > phase > > > > compiling...little targeted functionalities implemented as mojo > > goals.. > > > > > > > > this has been kicked back and forth for quite some time now :) > > > > > > I still think a build per helper mojo would make more sense to provide > > > for growth in one particular area in the future. It easy to start > > > decoupled, and not so much fun in the future. I don't think smaller > > > builds for particular help mojos is all that bad. > > > > > > > jesse > > > > > > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > > > > >>Brian E. Fox wrote: > > > >> > > > >>>I saw an email about this recently but can't find it. I thought > > someone > > > >>>had a plugin ready to be posted. I'm not sure the projecthelp > plugin > > is > > > >>>the right place, that seems to be more for pom development and > > > debugging > > > >>>than something for use at runtime. That said, I don't have any good > > > >>>suggestions for a name. how about add-souce-root-maven-plugin...jk > > > >> > > > >>Yes, something with an appropriate name would be more helpful. > > Something > > > >>like maven-generated-sources-mojo or something like that. There are > > lots > > > >>of folks at mojo that would use this so maybe that's the most > > > >>appropriate place to house to give more people access to it. > > > >> > > > >> > > > >>>-Original Message- > > > >>>From: dan tran [mailto:[EMAIL PROTECTED] > > > >>>Sent: Thursday, December 22, 2005 1:54 AM > > > >>>To: dev@maven.apache.org > > > >>>Subject: helper mojo to add additional source root - where should > it > > > be? > > > >>> > > > >>>Hi folks, > > > >>> > > > >>>Many times, I encounter user asking for a mojo to add additional > > source > > > >>>root to their pom at run time. > > > >>> > > > >>>This mojo is quite simple as we all agree. Does it make sense that > > > >>>maven-project-helper-plugin supports this feature? > > > >>> > > > >>>If not, what would be a logical plugin name to house this mojo? > > > >>>project-helper-maven-plugin to be at > > > >>>mojo.codehaus.org. ? > > > >>> > > > >>>-Dan > > > >>> > > > >>> > > > >>> > > > > >>>- > > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >>-- > > > >> > > > >>jvz. > > > >> > > > >>Jason van Zyl > > > >>jason at maven.org > > > >>http://maven.apache.org > > > >> > > > >>Simplex sigillum veri. (Simplicity is the seal of truth.) > > > >> > > > > >>- > > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > jesse mcconnell > > > > jesseDOTmcconnellATgmailDOTcom > > > > > > > > > > > > > -- > > > > > > jvz. > > > > > > Jason van Zyl > > > jason at maven.org > > > http://maven.apache.org > > > > > > the course of true love never did run smooth ... > > > > > > -- Shakespeare > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom > >
[maven2 build trunk - SUCCESS - checkout] Fri Dec 23 00:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051223.00.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051223.00.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: helper mojo to add additional source root - where should it be?
yep, that was what I was thinking On 12/22/05, dan tran <[EMAIL PROTECTED]> wrote: > > How about build-helper-maven-plugin? so we can focus on smaller scope? > > so we will have > > build-helper:add-source > build-helper:add-resource. > > mojos to start with > > -D > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > Jesse McConnell wrote: > > > I would lean towards a generalized project utilities mojohosted at > > mojo > > > that does things like add new source roots, do minor post compile > phase > > > compiling...little targeted functionalities implemented as mojo > goals.. > > > > > > this has been kicked back and forth for quite some time now :) > > > > I still think a build per helper mojo would make more sense to provide > > for growth in one particular area in the future. It easy to start > > decoupled, and not so much fun in the future. I don't think smaller > > builds for particular help mojos is all that bad. > > > > > jesse > > > > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > > >>Brian E. Fox wrote: > > >> > > >>>I saw an email about this recently but can't find it. I thought > someone > > >>>had a plugin ready to be posted. I'm not sure the projecthelp plugin > is > > >>>the right place, that seems to be more for pom development and > > debugging > > >>>than something for use at runtime. That said, I don't have any good > > >>>suggestions for a name. how about add-souce-root-maven-plugin...jk > > >> > > >>Yes, something with an appropriate name would be more helpful. > Something > > >>like maven-generated-sources-mojo or something like that. There are > lots > > >>of folks at mojo that would use this so maybe that's the most > > >>appropriate place to house to give more people access to it. > > >> > > >> > > >>>-Original Message- > > >>>From: dan tran [mailto:[EMAIL PROTECTED] > > >>>Sent: Thursday, December 22, 2005 1:54 AM > > >>>To: dev@maven.apache.org > > >>>Subject: helper mojo to add additional source root - where should it > > be? > > >>> > > >>>Hi folks, > > >>> > > >>>Many times, I encounter user asking for a mojo to add additional > source > > >>>root to their pom at run time. > > >>> > > >>>This mojo is quite simple as we all agree. Does it make sense that > > >>>maven-project-helper-plugin supports this feature? > > >>> > > >>>If not, what would be a logical plugin name to house this mojo? > > >>>project-helper-maven-plugin to be at > > >>>mojo.codehaus.org. ? > > >>> > > >>>-Dan > > >>> > > >>> > > >>> > > >>>- > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > >>> > > >> > > >> > > >>-- > > >> > > >>jvz. > > >> > > >>Jason van Zyl > > >>jason at maven.org > > >>http://maven.apache.org > > >> > > >>Simplex sigillum veri. (Simplicity is the seal of truth.) > > >> > > >>- > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > -- > > > jesse mcconnell > > > jesseDOTmcconnellATgmailDOTcom > > > > > > > > > -- > > > > jvz. > > > > Jason van Zyl > > jason at maven.org > > http://maven.apache.org > > > > the course of true love never did run smooth ... > > > > -- Shakespeare > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Commented: (MNG-1893) Cannot deploy artifacts using classifier
[ http://jira.codehaus.org/browse/MNG-1893?page=comments#action_54069 ] Brett Porter commented on MNG-1893: --- how does your POM look? We successfully do this in maven-model/pom.xml, so I think this works. > Cannot deploy artifacts using classifier > > > Key: MNG-1893 > URL: http://jira.codehaus.org/browse/MNG-1893 > Project: Maven 2 > Type: Bug > Reporter: Miguel Griffa > Priority: Critical > > > The classifier concept is well understood in maven, beeing an elemnt of the > dependency. > However, a project that generates artifacs with classifiers, cannot be > deployed, nor installed: > install plugin seem to 'not see' the classifier: > this output might help: > [INFO] [jar:jar] > [INFO] Building jar: > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT-localdev.jar > [INFO] [install:install] > [INFO] Installing > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar to > /home/mgriffa/.m2/repository/transferval/tfv-core/2.1-SNAPSHOT/tfv-core-2.1-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact > Embedded error: Error installing artifact: File > /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar does not > exist > jar:jar generates the artifact with the classifier, as told to do so, but > install misses it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MANTRUN-34) StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
[ http://jira.codehaus.org/browse/MANTRUN-34?page=all ]
Marcel Schutte updated MANTRUN-34:
--
Attachment: CustomAntTask-extra-tests.zip
> StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
>
>
> Key: MANTRUN-34
> URL: http://jira.codehaus.org/browse/MANTRUN-34
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Environment: XP, sun 1.4.2 JDK, maven 2.0.1, maven-antrun-plugin
> 1.1-SNAPSHOT (built from svn HEAD)
> Reporter: Marcel Schutte
> Assignee: Jason van Zyl
> Attachments: AntPropertyHelper.patch, CustomAntTask-extra-tests.zip,
> CustomAntTask.zip
>
>
> A custom ant task that in its java implementation references 'basedir' throws
> a StringIndexOutOfBoundsException. Executions continues and the result is
> correct.
> The attached zip contains a M2 project that builds the jar with the ant task
> and then calls it with the antrun plugin. The result for me is:
> C:\Data\WSAD\POC\CustomAntTask>mvn package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - nl.ohra.test:CustomAntTask:jar:1.0-SNAPSHOT
> [INFO]task-segment: [package]
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> Compiling 1 source file to C:\Data\WSAD\POC\CustomAntTask\target\classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [jar:jar]
> [INFO] Building jar:
> C:\Data\WSAD\POC\CustomAntTask\target\CustomAntTask-1.0-SNAPSHOT.jar
> [INFO] [antrun:run {execution: testant}]
> [INFO] Executing tasks
> Trying to override old definition of datatype test
> [WARNING] Error evaluating expression 'basedir'
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1444)
> at java.lang.String.substring(String.java:1411)
> at
> org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:51)
> at
> org.apache.tools.ant.PropertyHelper.getPropertyHook(PropertyHelper.java:184)
> at
> org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:438)
> at org.apache.tools.ant.Project.getProperty(Project.java:474)
> at nl.ohra.test.TestTask.execute(TestTask.java:11)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> at org.apache.tools.ant.Task.perform(Task.java:364)
> at org.apache.tools.ant.Target.execute(Target.java:341)
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:103)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47
> 2)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1444)
> at java.lang.String.substring(String
[jira] Commented: (MANTRUN-34) StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
[ http://jira.codehaus.org/browse/MANTRUN-34?page=comments#action_54064 ]
Marcel Schutte commented on MANTRUN-34:
---
The attached file 'AntPropertyHelper.patch' contains a patch for this bug.
'basedir' was treated the same way as 'project.' properties were.
While testing this fix, I found another problem with properties of the
following format 'project..'. First AntPropertyHelper would trim this
to '.'. After that, ReflectionValueExtractor.evaluate(String, Object)
would trim this to '' because it delegates to
ReflectionValueExtractor.evaluate(String, Object, true). I've modified
AntPropertyHelper to always use the three-arg evaluate() method for clarity.
The basedir property is now resolved as 'mavenproject.getBasedir().getPath()'
Please use the attached project-zip 'CustomAntTask-extra-tests.zip' to test.
Before applying the patch the result for me is:
C:\work\CustomAntTask>mvn -Dproject.cmdline=commandlineparameter package
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - nl.ohra.test:CustomAntTask:jar:1.0-SNAPSHOT
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: C:\work\CustomAntTask\target\CustomAntTask-1.0-SNAPSHOT.jar
[INFO] [antrun:run {execution: testant}]
[INFO] Executing tasks
[echo] basedir:C:\work\CustomAntTask
[echo] sourceDirectory:src/main/java
sourceDirectory:null
project.cmdline:commandlineparameter
[WARNING] Error evaluating expression 'basedir'
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1768)
at java.lang.String.substring(String.java:1735)
at
org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:5
1)
at
org.apache.tools.ant.PropertyHelper.getPropertyHook(PropertyHelper.java:184)
at
org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:438)
at org.apache.tools.ant.Project.getProperty(Project.java:474)
at nl.ohra.test.TestTask.execute(TestTask.java:13)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:103)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:530)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
ycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1768)
at java.lang.String.substring(String.java:1735)
at
org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:5
1)
at
org.apache.tools.ant.PropertyHelper.getProp
[jira] Updated: (MANTRUN-34) StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
[ http://jira.codehaus.org/browse/MANTRUN-34?page=all ]
Marcel Schutte updated MANTRUN-34:
--
Attachment: AntPropertyHelper.patch
> StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
>
>
> Key: MANTRUN-34
> URL: http://jira.codehaus.org/browse/MANTRUN-34
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Environment: XP, sun 1.4.2 JDK, maven 2.0.1, maven-antrun-plugin
> 1.1-SNAPSHOT (built from svn HEAD)
> Reporter: Marcel Schutte
> Assignee: Jason van Zyl
> Attachments: AntPropertyHelper.patch, CustomAntTask.zip
>
>
> A custom ant task that in its java implementation references 'basedir' throws
> a StringIndexOutOfBoundsException. Executions continues and the result is
> correct.
> The attached zip contains a M2 project that builds the jar with the ant task
> and then calls it with the antrun plugin. The result for me is:
> C:\Data\WSAD\POC\CustomAntTask>mvn package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - nl.ohra.test:CustomAntTask:jar:1.0-SNAPSHOT
> [INFO]task-segment: [package]
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> Compiling 1 source file to C:\Data\WSAD\POC\CustomAntTask\target\classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [jar:jar]
> [INFO] Building jar:
> C:\Data\WSAD\POC\CustomAntTask\target\CustomAntTask-1.0-SNAPSHOT.jar
> [INFO] [antrun:run {execution: testant}]
> [INFO] Executing tasks
> Trying to override old definition of datatype test
> [WARNING] Error evaluating expression 'basedir'
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1444)
> at java.lang.String.substring(String.java:1411)
> at
> org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:51)
> at
> org.apache.tools.ant.PropertyHelper.getPropertyHook(PropertyHelper.java:184)
> at
> org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:438)
> at org.apache.tools.ant.Project.getProperty(Project.java:474)
> at nl.ohra.test.TestTask.execute(TestTask.java:11)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> at org.apache.tools.ant.Task.perform(Task.java:364)
> at org.apache.tools.ant.Target.execute(Target.java:341)
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:103)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47
> 2)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1444)
> at java.lang.String.substring(String.java:1411)
> at
> org.apache.m
RE: helper mojo to add additional source root - where should it be?
+1 -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 6:19 PM To: Maven Developers List Subject: Re: helper mojo to add additional source root - where should it be? How about build-helper-maven-plugin? so we can focus on smaller scope? so we will have build-helper:add-source build-helper:add-resource. mojos to start with -D On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Jesse McConnell wrote: > > I would lean towards a generalized project utilities mojohosted > > at > mojo > > that does things like add new source roots, do minor post compile > > phase compiling...little targeted functionalities implemented as mojo goals.. > > > > this has been kicked back and forth for quite some time now :) > > I still think a build per helper mojo would make more sense to provide > for growth in one particular area in the future. It easy to start > decoupled, and not so much fun in the future. I don't think smaller > builds for particular help mojos is all that bad. > > > jesse > > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > >>Brian E. Fox wrote: > >> > >>>I saw an email about this recently but can't find it. I thought > >>>someone had a plugin ready to be posted. I'm not sure the > >>>projecthelp plugin is the right place, that seems to be more for > >>>pom development and > debugging > >>>than something for use at runtime. That said, I don't have any good > >>>suggestions for a name. how about add-souce-root-maven-plugin...jk > >> > >>Yes, something with an appropriate name would be more helpful. > >>Something like maven-generated-sources-mojo or something like that. > >>There are lots of folks at mojo that would use this so maybe that's > >>the most appropriate place to house to give more people access to it. > >> > >> > >>>-Original Message- > >>>From: dan tran [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, December 22, 2005 1:54 AM > >>>To: dev@maven.apache.org > >>>Subject: helper mojo to add additional source root - where should > >>>it > be? > >>> > >>>Hi folks, > >>> > >>>Many times, I encounter user asking for a mojo to add additional > >>>source root to their pom at run time. > >>> > >>>This mojo is quite simple as we all agree. Does it make sense that > >>>maven-project-helper-plugin supports this feature? > >>> > >>>If not, what would be a logical plugin name to house this mojo? > >>>project-helper-maven-plugin to be at mojo.codehaus.org. ? > >>> > >>>-Dan > >>> > >>> > >>> > >>>--- > >>>-- To unsubscribe, e-mail: [EMAIL PROTECTED] For > >>>additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> > >> > >>-- > >> > >>jvz. > >> > >>Jason van Zyl > >>jason at maven.org > >>http://maven.apache.org > >> > >>Simplex sigillum veri. (Simplicity is the seal of truth.) > >> > >> > >>- To unsubscribe, e-mail: [EMAIL PROTECTED] For > >>additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > > jesse mcconnell > > jesseDOTmcconnellATgmailDOTcom > > > > > -- > > jvz. > > Jason van Zyl > jason at maven.org > http://maven.apache.org > > the course of true love never did run smooth ... > > -- Shakespeare > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: helper mojo to add additional source root - where should it be?
How about build-helper-maven-plugin? so we can focus on smaller scope? so we will have build-helper:add-source build-helper:add-resource. mojos to start with -D On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Jesse McConnell wrote: > > I would lean towards a generalized project utilities mojohosted at > mojo > > that does things like add new source roots, do minor post compile phase > > compiling...little targeted functionalities implemented as mojo goals.. > > > > this has been kicked back and forth for quite some time now :) > > I still think a build per helper mojo would make more sense to provide > for growth in one particular area in the future. It easy to start > decoupled, and not so much fun in the future. I don't think smaller > builds for particular help mojos is all that bad. > > > jesse > > > > On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > >>Brian E. Fox wrote: > >> > >>>I saw an email about this recently but can't find it. I thought someone > >>>had a plugin ready to be posted. I'm not sure the projecthelp plugin is > >>>the right place, that seems to be more for pom development and > debugging > >>>than something for use at runtime. That said, I don't have any good > >>>suggestions for a name. how about add-souce-root-maven-plugin...jk > >> > >>Yes, something with an appropriate name would be more helpful. Something > >>like maven-generated-sources-mojo or something like that. There are lots > >>of folks at mojo that would use this so maybe that's the most > >>appropriate place to house to give more people access to it. > >> > >> > >>>-Original Message- > >>>From: dan tran [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, December 22, 2005 1:54 AM > >>>To: dev@maven.apache.org > >>>Subject: helper mojo to add additional source root - where should it > be? > >>> > >>>Hi folks, > >>> > >>>Many times, I encounter user asking for a mojo to add additional source > >>>root to their pom at run time. > >>> > >>>This mojo is quite simple as we all agree. Does it make sense that > >>>maven-project-helper-plugin supports this feature? > >>> > >>>If not, what would be a logical plugin name to house this mojo? > >>>project-helper-maven-plugin to be at > >>>mojo.codehaus.org. ? > >>> > >>>-Dan > >>> > >>> > >>> > >>>- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> > >> > >>-- > >> > >>jvz. > >> > >>Jason van Zyl > >>jason at maven.org > >>http://maven.apache.org > >> > >>Simplex sigillum veri. (Simplicity is the seal of truth.) > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > > jesse mcconnell > > jesseDOTmcconnellATgmailDOTcom > > > > > -- > > jvz. > > Jason van Zyl > jason at maven.org > http://maven.apache.org > > the course of true love never did run smooth ... > > -- Shakespeare > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[jira] Created: (CONTINUUM-525) Ability to abort / kill a build manually or after a specified time elapsed
Ability to abort / kill a build manually or after a specified time elapsed -- Key: CONTINUUM-525 URL: http://jira.codehaus.org/browse/CONTINUUM-525 Project: Continuum Type: New Feature Components: Core system Reporter: Guillaume Nodet -- 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
Re: helper mojo to add additional source root - where should it be?
Jesse McConnell wrote: I would lean towards a generalized project utilities mojohosted at mojo that does things like add new source roots, do minor post compile phase compiling...little targeted functionalities implemented as mojo goals.. this has been kicked back and forth for quite some time now :) I still think a build per helper mojo would make more sense to provide for growth in one particular area in the future. It easy to start decoupled, and not so much fun in the future. I don't think smaller builds for particular help mojos is all that bad. jesse On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: Brian E. Fox wrote: I saw an email about this recently but can't find it. I thought someone had a plugin ready to be posted. I'm not sure the projecthelp plugin is the right place, that seems to be more for pom development and debugging than something for use at runtime. That said, I don't have any good suggestions for a name. how about add-souce-root-maven-plugin...jk Yes, something with an appropriate name would be more helpful. Something like maven-generated-sources-mojo or something like that. There are lots of folks at mojo that would use this so maybe that's the most appropriate place to house to give more people access to it. -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 1:54 AM To: dev@maven.apache.org Subject: helper mojo to add additional source root - where should it be? Hi folks, Many times, I encounter user asking for a mojo to add additional source root to their pom at run time. This mojo is quite simple as we all agree. Does it make sense that maven-project-helper-plugin supports this feature? If not, what would be a logical plugin name to house this mojo? project-helper-maven-plugin to be at mojo.codehaus.org. ? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-50) Check for System.out statement
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-50?page=comments#action_54063 ] Dennis Lundberg commented on MPCHECKSTYLE-50: - This question would be better to ask on one of the Checkstyle mailing lists. See http://sourceforge.net/mail/?group_id=29721 > Check for System.out statement > -- > > Key: MPCHECKSTYLE-50 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-50 > Project: maven-checkstyle-plugin > Type: Task > Reporter: Shahzad Chaudhry > > > Is there a checkstyle check for repoting warnings / errors if System.out > statements are used in src 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Thu Dec 22 22:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051222.22.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051222.22.txt
[jira] Commented: (WAGONFTP-8) ArrayIndexOutOfBoundsException upon deploy
[ http://jira.codehaus.org/browse/WAGONFTP-8?page=comments#action_54062 ] Michael Fiedler commented on WAGONFTP-8: I believe the scm url is http://svn.apache.org/repos/asf/maven/wagon/trunk. > ArrayIndexOutOfBoundsException upon deploy > -- > > Key: WAGONFTP-8 > URL: http://jira.codehaus.org/browse/WAGONFTP-8 > Project: wagon-ftp > Type: Bug > Environment: Win xp, sp2 > Reporter: Michael Fiedler > > > I am trying to deploy for the first time. I am using wagon-ftp, 1.0-alpha-4 > as an extension for a maven 2 deploy goal. The repository location (on the > host) is new and empty. > c:\...> .../bin/mvn clean:clean install deploy > ... > [INFO] [deploy:deploy] > [INFO] Retrieving previous build number from M2_repo_ftp > Uploading: > ftp://host/com/company/modules/1.0-SNAPSHOT/modules-1.0-20051202.165702-1.pom > 4K uploaded > [INFO] Retrieving previous metadata from M2_repo_ftp > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] 0 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 0 > at > org.apache.maven.wagon.providers.ftp.FtpWagon.fillInputData(FtpWagon.java:326) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:367) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:334) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:379) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:138) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-647) Upload Joda-Time 1.2
Upload Joda-Time 1.2 Key: MAVENUPLOAD-647 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-647 Project: maven-upload-requests Type: Task Reporter: Stephen Colebourne http://joda-time.sourceforge.net/joda-time-1.2-bundle.jar http://joda-time.sourceforge.net http://joda-time.sourceforge.net/team-list.html Please upload joda-time 1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: helper mojo to add additional source root - where should it be?
I would lean towards a generalized project utilities mojohosted at mojo that does things like add new source roots, do minor post compile phase compiling...little targeted functionalities implemented as mojo goals.. this has been kicked back and forth for quite some time now :) jesse On 12/22/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Brian E. Fox wrote: > > I saw an email about this recently but can't find it. I thought someone > > had a plugin ready to be posted. I'm not sure the projecthelp plugin is > > the right place, that seems to be more for pom development and debugging > > than something for use at runtime. That said, I don't have any good > > suggestions for a name. how about add-souce-root-maven-plugin...jk > > Yes, something with an appropriate name would be more helpful. Something > like maven-generated-sources-mojo or something like that. There are lots > of folks at mojo that would use this so maybe that's the most > appropriate place to house to give more people access to it. > > > > > -Original Message- > > From: dan tran [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 22, 2005 1:54 AM > > To: dev@maven.apache.org > > Subject: helper mojo to add additional source root - where should it be? > > > > Hi folks, > > > > Many times, I encounter user asking for a mojo to add additional source > > root to their pom at run time. > > > > This mojo is quite simple as we all agree. Does it make sense that > > maven-project-helper-plugin supports this feature? > > > > If not, what would be a logical plugin name to house this mojo? > > project-helper-maven-plugin to be at > > mojo.codehaus.org. ? > > > > -Dan > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > > jvz. > > Jason van Zyl > jason at maven.org > http://maven.apache.org > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Commented: (MWAR-7) Referenced projects' artifacts naming scheme behaves differently when ran from reactor
[ http://jira.codehaus.org/browse/MWAR-7?page=comments#action_54061 ]
Shinobu Kawai Yoshida commented on MWAR-7:
--
It would be great if the war plugin had a bundleFileName property like the ear
plugin.
> Referenced projects' artifacts naming scheme behaves differently when ran
> from reactor
> --
>
> Key: MWAR-7
> URL: http://jira.codehaus.org/browse/MWAR-7
> Project: Maven 2.x War Plugin
> Type: Bug
> Environment: maven-war-plugin versions 2.0-beta-1 and 2.0-beta-2
> Reporter: Cédric Vidal
>
>
> When running mvn install from a war packaged project, the referenced
> projects' artifacts are bundled into the WEB-INF/lib directory with the
> following naming scheme ${groupId}-${artifactId}-${version}.jar, but when
> running mvn install as part of the reactor, the referenced projects'
> artifacts are bundled into the WEB-INF/lib directory with the following
> naming scheme ${pom.build.finalName}.jar
> The naming scheme should be the same in the two situations for the sake of
> consistency, but also to avoid the disturbing (for the end user) situation
> where you end up having the same dependencies present twice with different
> names.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: helper mojo to add additional source root - where should it be?
Brian E. Fox wrote: I saw an email about this recently but can't find it. I thought someone had a plugin ready to be posted. I'm not sure the projecthelp plugin is the right place, that seems to be more for pom development and debugging than something for use at runtime. That said, I don't have any good suggestions for a name. how about add-souce-root-maven-plugin...jk Yes, something with an appropriate name would be more helpful. Something like maven-generated-sources-mojo or something like that. There are lots of folks at mojo that would use this so maybe that's the most appropriate place to house to give more people access to it. -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 1:54 AM To: dev@maven.apache.org Subject: helper mojo to add additional source root - where should it be? Hi folks, Many times, I encounter user asking for a mojo to add additional source root to their pom at run time. This mojo is quite simple as we all agree. Does it make sense that maven-project-helper-plugin supports this feature? If not, what would be a logical plugin name to house this mojo? project-helper-maven-plugin to be at mojo.codehaus.org. ? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Thu Dec 22 21:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051222.21.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051222.21.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 New sandbox plugin - dependency-maven-plugin
correct. On 12/22/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > Gotcha. I see no reason then not to include it. I'm not too familiar > with jarjar at this point, but from what I can see, it's jar a jar with > other jars included? > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 22, 2005 11:37 AM > To: Maven Developers List > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > Yes I see jarjar in sand box as well. But I think your dependency > plugin is a best candidate to implement jarjar. Here is the reason: > > - Jarjar requires a none transitive dependency. The only way to do > that is to put >required dependency in build configuration. You have that > facility/infrastructure >inplace. To implement jarjar in a separate plugin means it has to > repeat the code >you already have > > > -D > > > > > > > On 12/22/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > There's a jarjar in the sandbox. Not sure if or how it works, just saw > > > the name there. > > > > -Original Message- > > From: dan tran [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 21, 2005 11:59 PM > > To: Maven Developers List > > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > > > dont think we have jarjar yet!!! but on the second thought, this > > plugin > > + assembly together can create jarjar. > > > > -D > > > > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > > > Isn't there a jarjar plugin to do that already? > > > > > > -Original Message- > > > From: dan tran [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, December 21, 2005 6:48 PM > > > To: Maven Developers List > > > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > > > > > We should be able to enhance this plugin to provisde jarjar > > > functionality with no transtive dependency. > > > > > > -D > > > > > > > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi all, > > > > I want to announce a new plugin in the mojo sandbox: > > > > http://mojo.codehaus.org/dependency-maven-plugin/introduction.html > > > > > > > > This plugin can copy artifacts from the repository into a desired > > > > location and currently operates separately from the normal > > > dependancies. > > > > (perfect for things you need but don't want on the classpath) It > > > > can > > > > > > get the artifacts from the local or remote repositories and > > > > understands the dependancyManagement section. It can explode those > > > artifacts if desired. > > > > The plugin is currently in alpha state, hence the sandbox, but has > > > > > been used in production by team and possibly a few others. > > > > > > > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: M2 New sandbox plugin - dependency-maven-plugin
Gotcha. I see no reason then not to include it. I'm not too familiar with jarjar at this point, but from what I can see, it's jar a jar with other jars included? -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 11:37 AM To: Maven Developers List Subject: Re: M2 New sandbox plugin - dependency-maven-plugin Yes I see jarjar in sand box as well. But I think your dependency plugin is a best candidate to implement jarjar. Here is the reason: - Jarjar requires a none transitive dependency. The only way to do that is to put required dependency in build configuration. You have that facility/infrastructure inplace. To implement jarjar in a separate plugin means it has to repeat the code you already have -D On 12/22/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > There's a jarjar in the sandbox. Not sure if or how it works, just saw > the name there. > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 21, 2005 11:59 PM > To: Maven Developers List > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > dont think we have jarjar yet!!! but on the second thought, this > plugin > + assembly together can create jarjar. > > -D > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > Isn't there a jarjar plugin to do that already? > > > > -Original Message- > > From: dan tran [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 21, 2005 6:48 PM > > To: Maven Developers List > > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > > > We should be able to enhance this plugin to provisde jarjar > > functionality with no transtive dependency. > > > > -D > > > > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > I want to announce a new plugin in the mojo sandbox: > > > http://mojo.codehaus.org/dependency-maven-plugin/introduction.html > > > > > > This plugin can copy artifacts from the repository into a desired > > > location and currently operates separately from the normal > > dependancies. > > > (perfect for things you need but don't want on the classpath) It > > > can > > > > get the artifacts from the local or remote repositories and > > > understands the dependancyManagement section. It can explode those > > artifacts if desired. > > > The plugin is currently in alpha state, hence the sandbox, but has > > > been used in production by team and possibly a few others. > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHECKSTYLE-50) Check for System.out statement
Check for System.out statement -- Key: MPCHECKSTYLE-50 URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-50 Project: maven-checkstyle-plugin Type: Task Reporter: Shahzad Chaudhry Is there a checkstyle check for repoting warnings / errors if System.out statements are used in src 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1893) Cannot deploy artifacts using classifier
Cannot deploy artifacts using classifier Key: MNG-1893 URL: http://jira.codehaus.org/browse/MNG-1893 Project: Maven 2 Type: Bug Reporter: Miguel Griffa Priority: Critical The classifier concept is well understood in maven, beeing an elemnt of the dependency. However, a project that generates artifacs with classifiers, cannot be deployed, nor installed: install plugin seem to 'not see' the classifier: this output might help: [INFO] [jar:jar] [INFO] Building jar: /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT-localdev.jar [INFO] [install:install] [INFO] Installing /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar to /home/mgriffa/.m2/repository/transferval/tfv-core/2.1-SNAPSHOT/tfv-core-2.1-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact Embedded error: Error installing artifact: File /home/mgriffa/workspace/tfv-core/target/tfv-core-2.1-SNAPSHOT.jar does not exist jar:jar generates the artifact with the classifier, as told to do so, but install misses it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1892) not possible to attach transferlistener to embedder
not possible to attach transferlistener to embedder --- Key: MNG-1892 URL: http://jira.codehaus.org/browse/MNG-1892 Project: Maven 2 Type: Bug Components: maven-embedder Versions: 2.0.1 Reporter: Milos Kleint when loading projects using embedder, it will attempt to dowload the various dependencies. However from client code it's not possible to watch the process and show that in UI, it's only possible when executing project. I suggest a setter for TransferListener similar to the one for embedderlogger and use it for all operations of teh embedder. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCASTOR-7) Could not find org.exolab.castor.builder.SourceGenerator
[ http://jira.codehaus.org/browse/MPCASTOR-7?page=comments#action_54042 ] Gagan bajpai commented on MPCASTOR-7: - Hi Graham, This plugin seems to be still broken. Is there a round about way for fixing this issue? can you guide me to that please? is it somekind of class loader issue? > Could not find org.exolab.castor.builder.SourceGenerator > > > Key: MPCASTOR-7 > URL: http://jira.codehaus.org/browse/MPCASTOR-7 > Project: maven-castor-plugin > Type: Bug > Environment: Maven v1.0.2 > MacOSX v10.3.8 > JDK v1.4.2 > Reporter: Graham Leggett > > > After following the instructions for configuring castor, and getting the > following pregoal: > > > package="za.co.xxx.ia.eod" > types="j2"/> > > Castor source generation fails claiming that castor is missing from the > classpath. Checking the maven repository shows the castor jar is there, and > if you remove the castor jar, maven downloads the castor jar correctly. > Has anybody got the castor plugin to work within maven v1.0.2, or is the > castor plugin known to be broken? > Graham-Leggetts-Computer:~/src/standard/monaco-xml minfrin$ maven > java:compile __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > [propertyfile] Updating property file: > /Users/minfrin/src/standard/monaco-xml/src/conf/version.properties > build:start: > java:prepare-filesystem: > java:compile: > castor:prepare-filesystem: > [echo] Generating sources for src/xsd/eod.xsd > BUILD FAILED > File.. /Users/minfrin/.maven/cache/maven-castor-plugin-1.2/plugin.jelly > Element... ant:java > Line.. 92 > Column 38 > Could not find org.exolab.castor.builder.SourceGenerator. Make sure you have > it in your classpath > Total time: 4 seconds > Finished at: Mon Feb 21 12:20:15 SAST 2005 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMD-4) PMD should use "sensible" default rulesets
[ http://jira.codehaus.org/browse/MPMD-4?page=comments#action_54041 ] patrick OShea commented on MPMD-4: -- I've created http://jira.codehaus.org/browse/MPMD-8?rc=1 and uploaded a patch > PMD should use "sensible" default rulesets > -- > > Key: MPMD-4 > URL: http://jira.codehaus.org/browse/MPMD-4 > Project: Maven 2.x Pmd Plugin > Type: Task > Reporter: Dave Sag > Attachments: Locator.java, MNG-1158-maven-pmd-plugin.patch, > PmdReport.java.diff > > > When I add a PMD report to my pom.xml the PMD report claims that my class > 'Address' should have a constructor. > this is crazy talk - Address.java is an interface class. > i guess this is really a PMD bug but i find it hard to believe that such a > well established tool as PMD would still be throwing up bugs like this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1891) plugin execution in a profile
plugin execution in a profile - Key: MNG-1891 URL: http://jira.codehaus.org/browse/MNG-1891 Project: Maven 2 Type: Bug Components: POM Versions: 2.0, 2.0.1 Reporter: patrick OShea If there are multiple plugins declared in the same phase in a profile, they do not execute in the order they appear in the pom.xml (similar to MNG1499) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Thu Dec 22 17:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051222.17.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051222.17.txt
[jira] Commented: (MNGECLIPSE-15) Output folders are not set correctly by 'Update Sources' action
[ http://jira.codehaus.org/browse/MNGECLIPSE-15?page=comments#action_54039 ] Eugene Kuleshov commented on MNGECLIPSE-15: --- Takehiko, can you please respond to my comment about there separate resources would be needed? I am still not sure if it will be a good idea to have two parallel trees for Maven and Eclipse targets, especially when they all going into the same build and classpath. As a side note, when resources are placed in a separate folder we may use resource folder as an output folder for Eclipse, so it won't even need to copy anything. > Output folders are not set correctly by 'Update Sources' action > --- > > Key: MNGECLIPSE-15 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-15 > Project: Maven 2.x Plug-in for Eclipse > Type: Bug > Reporter: YOKOTA Takehiko > Assignee: Eugene Kuleshov > Attachments: patch.txt > > > Although source folders on build path are updated correctly by 'Update > Sources' action, > output folders are not updated at all. > For example, it is expected that output folder for 'src/test/java' and > 'src/test/resources' > is set to 'target/test-classes', but not set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-15) Output folders are not set correctly by 'Update Sources' action
[ http://jira.codehaus.org/browse/MNGECLIPSE-15?page=all ] YOKOTA Takehiko updated MNGECLIPSE-15: -- Attachment: patch.txt > Output folders are not set correctly by 'Update Sources' action > --- > > Key: MNGECLIPSE-15 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-15 > Project: Maven 2.x Plug-in for Eclipse > Type: Bug > Reporter: YOKOTA Takehiko > Assignee: Eugene Kuleshov > Attachments: patch.txt > > > Although source folders on build path are updated correctly by 'Update > Sources' action, > output folders are not updated at all. > For example, it is expected that output folder for 'src/test/java' and > 'src/test/resources' > is set to 'target/test-classes', but not set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 New sandbox plugin - dependency-maven-plugin
Yes I see jarjar in sand box as well. But I think your dependency plugin is a best candidate to implement jarjar. Here is the reason: - Jarjar requires a none transitive dependency. The only way to do that is to put required dependency in build configuration. You have that facility/infrastructure inplace. To implement jarjar in a separate plugin means it has to repeat the code you already have -D On 12/22/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > There's a jarjar in the sandbox. Not sure if or how it works, just saw > the name there. > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 21, 2005 11:59 PM > To: Maven Developers List > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > dont think we have jarjar yet!!! but on the second thought, this plugin > + assembly together can create jarjar. > > -D > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > Isn't there a jarjar plugin to do that already? > > > > -Original Message- > > From: dan tran [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 21, 2005 6:48 PM > > To: Maven Developers List > > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > > > We should be able to enhance this plugin to provisde jarjar > > functionality with no transtive dependency. > > > > -D > > > > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > I want to announce a new plugin in the mojo sandbox: > > > http://mojo.codehaus.org/dependency-maven-plugin/introduction.html > > > > > > This plugin can copy artifacts from the repository into a desired > > > location and currently operates separately from the normal > > dependancies. > > > (perfect for things you need but don't want on the classpath) It can > > > > get the artifacts from the local or remote repositories and > > > understands the dependancyManagement section. It can explode those > > artifacts if desired. > > > The plugin is currently in alpha state, hence the sandbox, but has > > > been used in production by team and possibly a few others. > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[jira] Commented: (MJAVADOC-38) Display "Copyright {year}" when inception year and current year are the same.
[ http://jira.codehaus.org/browse/MJAVADOC-38?page=comments#action_54037 ]
Brent Worden commented on MJAVADOC-38:
--
Forgive my Jira stupidity. The 2kb attachment is the correct patch. The other
patch is obsolete.
> Display "Copyright {year}" when inception year and current year are the same.
> -
>
> Key: MJAVADOC-38
> URL: http://jira.codehaus.org/browse/MJAVADOC-38
> Project: Maven 2.x Javadoc Plugin
> Type: Improvement
> Reporter: Brent Worden
> Assignee: Jason van Zyl
> Priority: Minor
> Attachments: MJAVADOC-38.diff, MJAVADOC-38.diff
>
>
> By default, the bottom property contains Copyright {inceptionYear}-{year}.
> If the inception year and current year are the same, something like Copyright
> 2005-2005 would be used. It would be nice to just display the year once, as
> in Copyright 2005.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-175) spring-1.2.pom invalid
[ http://jira.codehaus.org/browse/MEV-175?page=all ] Carlos Sanchez closed MEV-175: -- Assign To: Carlos Sanchez (was: Edwin Punzalan) Resolution: Fixed Removed dependencies, to get a complete list you can use 1.2.6 > spring-1.2.pom invalid > -- > > Key: MEV-175 > URL: http://jira.codehaus.org/browse/MEV-175 > Project: Maven Evangelism > Type: Bug > Reporter: Vladislav Pernin > Assignee: Carlos Sanchez > > > It seems that the file spring-1.2.pom locate there > ~/.m2/repository/springframework/spring/1.2/spring-1.2.pom is invalid. It > contains a lot of empty dependencies. > The servlet api dependency must be moved to javax.servlet and the dependency > on jca is broken. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin development questions
Best Regards Global Identity A/S, Jens Fournais CEO Bygstubben 3 | DK-2950 Vedbaek | Denmark Phone: +45 45 99 31 00 | E-mail: [EMAIL PROTECTED] Please visit our website at: http://www.elibitum.com
[jira] Created: (MEV-268) Add relocation from acegisecurity to org.acegisecurity
Add relocation from acegisecurity to org.acegisecurity -- Key: MEV-268 URL: http://jira.codehaus.org/browse/MEV-268 Project: Maven Evangelism Type: Task Reporter: Carlos Sanchez Assigned to: Edwin Punzalan Add poms in acegisecurity for version 1.0.0-RC1 pointing to org.acegisecurity -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-38) Display "Copyright {year}" when inception year and current year are the same.
[ http://jira.codehaus.org/browse/MJAVADOC-38?page=all ]
Brent Worden updated MJAVADOC-38:
-
Attachment: MJAVADOC-38.diff
> Display "Copyright {year}" when inception year and current year are the same.
> -
>
> Key: MJAVADOC-38
> URL: http://jira.codehaus.org/browse/MJAVADOC-38
> Project: Maven 2.x Javadoc Plugin
> Type: Improvement
> Reporter: Brent Worden
> Assignee: Jason van Zyl
> Priority: Minor
> Attachments: MJAVADOC-38.diff, MJAVADOC-38.diff
>
>
> By default, the bottom property contains Copyright {inceptionYear}-{year}.
> If the inception year and current year are the same, something like Copyright
> 2005-2005 would be used. It would be nice to just display the year once, as
> in Copyright 2005.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-161) acegisecurity lacks dependency for oro and commons-codec
[ http://jira.codehaus.org/browse/MEV-161?page=all ] Carlos Sanchez closed MEV-161: -- Resolution: Incomplete As no poms are provided I suggest using the org.acegisecurity:acegisecurity:1.0.0-RC1, whose poms are correct and will be available in the next hours > acegisecurity lacks dependency for oro and commons-codec > > > Key: MEV-161 > URL: http://jira.codehaus.org/browse/MEV-161 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Oliver Siegmar > Assignee: Carlos Sanchez > > > acegisecurity should have at least these dependencies: > > oro > oro > 2.0.8 > > > commons-codec > commons-codec > 1.3 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Thu Dec 22 15:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051222.15.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051222.15.txt
RE: M2 New sandbox plugin - dependency-maven-plugin
There's a jarjar in the sandbox. Not sure if or how it works, just saw the name there. -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 11:59 PM To: Maven Developers List Subject: Re: M2 New sandbox plugin - dependency-maven-plugin dont think we have jarjar yet!!! but on the second thought, this plugin + assembly together can create jarjar. -D On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > Isn't there a jarjar plugin to do that already? > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 21, 2005 6:48 PM > To: Maven Developers List > Subject: Re: M2 New sandbox plugin - dependency-maven-plugin > > We should be able to enhance this plugin to provisde jarjar > functionality with no transtive dependency. > > -D > > > On 12/21/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > I want to announce a new plugin in the mojo sandbox: > > http://mojo.codehaus.org/dependency-maven-plugin/introduction.html > > > > This plugin can copy artifacts from the repository into a desired > > location and currently operates separately from the normal > dependancies. > > (perfect for things you need but don't want on the classpath) It can > > get the artifacts from the local or remote repositories and > > understands the dependancyManagement section. It can explode those > artifacts if desired. > > The plugin is currently in alpha state, hence the sandbox, but has > > been used in production by team and possibly a few others. > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: helper mojo to add additional source root - where should it be?
I saw an email about this recently but can't find it. I thought someone had a plugin ready to be posted. I'm not sure the projecthelp plugin is the right place, that seems to be more for pom development and debugging than something for use at runtime. That said, I don't have any good suggestions for a name. how about add-souce-root-maven-plugin...jk -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 1:54 AM To: dev@maven.apache.org Subject: helper mojo to add additional source root - where should it be? Hi folks, Many times, I encounter user asking for a mojo to add additional source root to their pom at run time. This mojo is quite simple as we all agree. Does it make sense that maven-project-helper-plugin supports this feature? If not, what would be a logical plugin name to house this mojo? project-helper-maven-plugin to be at mojo.codehaus.org. ? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-38) Display "Copyright {year}" when inception year and current year are the same.
[ http://jira.codehaus.org/browse/MJAVADOC-38?page=all ]
Brent Worden updated MJAVADOC-38:
-
Attachment: MJAVADOC-38.diff
> Display "Copyright {year}" when inception year and current year are the same.
> -
>
> Key: MJAVADOC-38
> URL: http://jira.codehaus.org/browse/MJAVADOC-38
> Project: Maven 2.x Javadoc Plugin
> Type: Improvement
> Reporter: Brent Worden
> Assignee: Jason van Zyl
> Priority: Minor
> Attachments: MJAVADOC-38.diff
>
>
> By default, the bottom property contains Copyright {inceptionYear}-{year}.
> If the inception year and current year are the same, something like Copyright
> 2005-2005 would be used. It would be nice to just display the year once, as
> in Copyright 2005.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MJAVADOC-38) Display "Copyright {year}" when inception year and current year are the same.
Display "Copyright {year}" when inception year and current year are the same.
-
Key: MJAVADOC-38
URL: http://jira.codehaus.org/browse/MJAVADOC-38
Project: Maven 2.x Javadoc Plugin
Type: Improvement
Reporter: Brent Worden
Assigned to: Jason van Zyl
Priority: Minor
By default, the bottom property contains Copyright {inceptionYear}-{year}. If
the inception year and current year are the same, something like Copyright
2005-2005 would be used. It would be nice to just display the year once, as in
Copyright 2005.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Thu Dec 22 14:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20051222.14.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20051222.14.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Thu Dec 22 14:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051222.14.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051222.14.txt
[jira] Created: (MANTRUN-34) StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
StringIndexOutOfBoundsException in custom ant task referencing 'basedir'
Key: MANTRUN-34
URL: http://jira.codehaus.org/browse/MANTRUN-34
Project: Maven 2.x Antrun Plugin
Type: Bug
Environment: XP, sun 1.4.2 JDK, maven 2.0.1, maven-antrun-plugin 1.1-SNAPSHOT
(built from svn HEAD)
Reporter: Marcel Schutte
Assigned to: Jason van Zyl
Attachments: CustomAntTask.zip
A custom ant task that in its java implementation references 'basedir' throws a
StringIndexOutOfBoundsException. Executions continues and the result is correct.
The attached zip contains a M2 project that builds the jar with the ant task
and then calls it with the antrun plugin. The result for me is:
C:\Data\WSAD\POC\CustomAntTask>mvn package
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - nl.ohra.test:CustomAntTask:jar:1.0-SNAPSHOT
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 1 source file to C:\Data\WSAD\POC\CustomAntTask\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\Data\WSAD\POC\CustomAntTask\target\CustomAntTask-1.0-SNAPSHOT.jar
[INFO] [antrun:run {execution: testant}]
[INFO] Executing tasks
Trying to override old definition of datatype test
[WARNING] Error evaluating expression 'basedir'
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1444)
at java.lang.String.substring(String.java:1411)
at
org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:51)
at
org.apache.tools.ant.PropertyHelper.getPropertyHook(PropertyHelper.java:184)
at
org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:438)
at org.apache.tools.ant.Project.getProperty(Project.java:474)
at nl.ohra.test.TestTask.execute(TestTask.java:11)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:103)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47
2)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1444)
at java.lang.String.substring(String.java:1411)
at
org.apache.maven.plugin.antrun.AntPropertyHelper.getPropertyHook(AntPropertyHelper.java:51)
at
org.apache.tools.ant.PropertyHelper.getPropertyHook(PropertyHelper.java:184)
at
org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:438)
at org.apache.tools.ant.Project.getProperty(Project.java:474)
at nl.ohra.test.TestTask.execute(TestTask.java:11)
at
How to create maven site of chinese version in maven subversion?
How to create maven site of chinese version in maven subversion? I want to become a chinese maven site translator committer,how to ? what is the main condition to become a committer?
[jira] Updated: (MNG-1783) maven-release-plugin doesn't pass username to maven-scm-provider-cvs
[ http://jira.codehaus.org/browse/MNG-1783?page=all ]
Brett Porter updated MNG-1783:
--
Priority: Critical (was: Major)
Fix Version: 2.0.3
this should be a relatively simply fix in Maven SCM.
> maven-release-plugin doesn't pass username to maven-scm-provider-cvs
>
>
> Key: MNG-1783
> URL: http://jira.codehaus.org/browse/MNG-1783
> Project: Maven 2
> Type: Bug
> Versions: 2.0
> Reporter: Jochen Wiedmann
> Priority: Critical
> Fix For: 2.0.3
>
>
> The class CvsScmProvider refuses a CVS url without username. See, for
> example, line 253ff:
> int index = userhost.indexOf( "@" );
> if ( index == -1 )
> {
> result.messages.add( "The userhost part must be on the
> form: @." );
> return result;
> }
> On the other hand, the maven-release-plugin doesn't pass the full URL to the
> provider. In AbstractReleaseMojo, an instance of ScmHelper is used, see line
> 120:
>repository = getScmManager().makeScmRepository(
> scmHelper.getUrl() );
> But the ScmHelper's URL is a reformatted URL, with user, password, and so on
> removed. The effect is that any attempt to run
> mvn release:prepare
> with an URL like scm:cvs:pserver:[EMAIL PROTECTED]:/cvs:module is refused
> with an error message "The scm url is invalid."
> I can't tell which side is wrong and am thus unable to provide a patch.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1888) (XInclude support)
[ http://jira.codehaus.org/browse/MNG-1888?page=all ] Brett Porter closed MNG-1888: - Assign To: Brett Porter Resolution: Won't Fix this has been brought up in other forms before, reasons for not implementing: - as detailed in MNG-1890, parents can be used to reuse content - pom.xml should *not* contain maven.xml, that should be put into plugins (antrun should be used sparingly) - there is a proposal before the dev list to possibly separate the pom into several sections which would be the preferred solution - there is also proposals up for reusable configurations for plugins - pom needs to be unified for the reasons listed in MNG-1890 as for XInclude - our parser doesn't currently support that so it would be out anyway. > (XInclude support) > -- > > Key: MNG-1888 > URL: http://jira.codehaus.org/browse/MNG-1888 > Project: Maven 2 > Type: Improvement > Reporter: Geoffrey > Assignee: Brett Porter > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1890) Optionally split up/partition pom.xml with XInclude
[ http://jira.codehaus.org/browse/MNG-1890?page=all ] Brett Porter closed MNG-1890: - Assign To: Brett Porter Resolution: Duplicate > Optionally split up/partition pom.xml with XInclude > --- > > Key: MNG-1890 > URL: http://jira.codehaus.org/browse/MNG-1890 > Project: Maven 2 > Type: Improvement > Components: POM > Versions: 2.0.1 > Reporter: Geoffrey > Assignee: Brett Porter > > > A pom.xml can get really big, considering it holds more information then > maven.xml and project.xml together. > In Java is a bad idea to have a class with more then 500 lines. > In Spring they use the But there already is a standard to partition xml files: XInclude. > From a user perspective a partitioned pom.xml would be a lot more maintable > since we could decide to make a > pom-dependencies.xml etc if we we want. > Problems: > - Sending the pom to the repository should merge it. > - Continuum needs a non-partioned pom > - pom processing mevenide's etc. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=all ] Jochen Wiedmann updated MNG-728: Attachment: maven-proxy-3.patch maven-proxy-2.patch maven-proxy-1.patch > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0-alpha-3 > Reporter: Kohsuke Kawaguchi > Priority: Minor > Fix For: 2.1 > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1783) maven-release-plugin doesn't pass username to maven-scm-provider-cvs
[ http://jira.codehaus.org/browse/MNG-1783?page=comments#action_54015 ]
Pascal Grange commented on MNG-1783:
I can't answer but I just want you to know that you are not alone :)
We are considering, in my company, switching to maven 2 but this bug is a
blocker for us !
> maven-release-plugin doesn't pass username to maven-scm-provider-cvs
>
>
> Key: MNG-1783
> URL: http://jira.codehaus.org/browse/MNG-1783
> Project: Maven 2
> Type: Bug
> Versions: 2.0
> Reporter: Jochen Wiedmann
>
>
> The class CvsScmProvider refuses a CVS url without username. See, for
> example, line 253ff:
> int index = userhost.indexOf( "@" );
> if ( index == -1 )
> {
> result.messages.add( "The userhost part must be on the
> form: @." );
> return result;
> }
> On the other hand, the maven-release-plugin doesn't pass the full URL to the
> provider. In AbstractReleaseMojo, an instance of ScmHelper is used, see line
> 120:
>repository = getScmManager().makeScmRepository(
> scmHelper.getUrl() );
> But the ScmHelper's URL is a reformatted URL, with user, password, and so on
> removed. The effect is that any attempt to run
> mvn release:prepare
> with an URL like scm:cvs:pserver:[EMAIL PROTECTED]:/cvs:module is refused
> with an error message "The scm url is invalid."
> I can't tell which side is wrong and am thus unable to provide a patch.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1783) maven-release-plugin doesn't pass username to maven-scm-provider-cvs
[ http://jira.codehaus.org/browse/MNG-1783?page=comments#action_54014 ]
Jochen Wiedmann commented on MNG-1783:
--
Would anyone please be so kind to comment at least, whether my observations are
correct and, if so, which side (maven-release-plugin or CVS provider) has to be
fixed? If so, I could continue and provide a patch.
> maven-release-plugin doesn't pass username to maven-scm-provider-cvs
>
>
> Key: MNG-1783
> URL: http://jira.codehaus.org/browse/MNG-1783
> Project: Maven 2
> Type: Bug
> Versions: 2.0
> Reporter: Jochen Wiedmann
>
>
> The class CvsScmProvider refuses a CVS url without username. See, for
> example, line 253ff:
> int index = userhost.indexOf( "@" );
> if ( index == -1 )
> {
> result.messages.add( "The userhost part must be on the
> form: @." );
> return result;
> }
> On the other hand, the maven-release-plugin doesn't pass the full URL to the
> provider. In AbstractReleaseMojo, an instance of ScmHelper is used, see line
> 120:
>repository = getScmManager().makeScmRepository(
> scmHelper.getUrl() );
> But the ScmHelper's URL is a reformatted URL, with user, password, and so on
> removed. The effect is that any attempt to run
> mvn release:prepare
> with an URL like scm:cvs:pserver:[EMAIL PROTECTED]:/cvs:module is refused
> with an error message "The scm url is invalid."
> I can't tell which side is wrong and am thus unable to provide a patch.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1890) Optionally split up/partition pom.xml with XInclude
[ http://jira.codehaus.org/browse/MNG-1890?page=comments#action_54013 ] Olivier Lamy commented on MNG-1890: --- You can easily do it with a super pom which includes all your commons dependencies. Then use this in your others poms. groupId commons-root-pom version > Optionally split up/partition pom.xml with XInclude > --- > > Key: MNG-1890 > URL: http://jira.codehaus.org/browse/MNG-1890 > Project: Maven 2 > Type: Improvement > Components: POM > Versions: 2.0.1 > Reporter: Geoffrey > > > A pom.xml can get really big, considering it holds more information then > maven.xml and project.xml together. > In Java is a bad idea to have a class with more then 500 lines. > In Spring they use the But there already is a standard to partition xml files: XInclude. > From a user perspective a partitioned pom.xml would be a lot more maintable > since we could decide to make a > pom-dependencies.xml etc if we we want. > Problems: > - Sending the pom to the repository should merge it. > - Continuum needs a non-partioned pom > - pom processing mevenide's etc. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1273) Current installation instructions for Windows do not mention M2_HOME. It is required and cannot have spaces.
[ http://jira.codehaus.org/browse/MNG-1273?page=comments#action_54012 ] Grzegorz Slowikowski commented on MNG-1273: --- I commented this issue here: http://jira.codehaus.org/browse/MNG-1317 but this issue is still open. I personally changed in my m2.bat file from "%~dps0" to "%~dp0" and it works. I found in MNG-1318 (http://jira.codehaus.org/browse/MNG-1318) that "%~dps0" has something to do with Windows NT. I have XP, so I cannot check if "%~dp0" would work on NT or not. But when using "mvn.bat" instead of "m2.bat" there is no issue. > Current installation instructions for Windows do not mention M2_HOME. It is > required and cannot have spaces. > - > > Key: MNG-1273 > URL: http://jira.codehaus.org/browse/MNG-1273 > Project: Maven 2 > Type: Bug > Components: documentation - general > Versions: 2.0 > Environment: Windows > Reporter: Richard Bondi > Priority: Minor > Fix For: 2.0.3 > > > Two issues: > 1. The installation instructions for Windows make no mention of the need to > set M2_HOME. But if you try to run "mvn --version" after following the > instructions, you are prompted to set this environment variable. > 2. At least on Windows 2K, M2_HOME will not work if it contains spaces. One > workaround is to use the "short" 8.3 version of all directory names. (To see > the short version of directory names, do "dir /A:D /X" in a DOS window.) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1890) Optionally split up/partition pom.xml with XInclude
Optionally split up/partition pom.xml with XInclude --- Key: MNG-1890 URL: http://jira.codehaus.org/browse/MNG-1890 Project: Maven 2 Type: Improvement Components: POM Versions: 2.0.1 Reporter: Geoffrey A pom.xml can get really big, considering it holds more information then maven.xml and project.xml together. In Java is a bad idea to have a class with more then 500 lines. In Spring they use the From a user perspective a partitioned pom.xml would be a lot more maintable >since we could decide to make a pom-dependencies.xml etc if we we want. Problems: - Sending the pom to the repository should merge it. - Continuum needs a non-partioned pom - pom processing mevenide's etc. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1889) Plugins without descriptors
Plugins without descriptors --- Key: MNG-1889 URL: http://jira.codehaus.org/browse/MNG-1889 Project: Maven 2 Type: Bug Components: Plugin Creation Tools Versions: 2.0.1 Reporter: Jochen Wiedmann Priority: Minor Attachments: numMojoDescriptors.patch The attached patch throws an exception, if no Mojos are found in a plugin. Background: If such a plugin is installed, then an NPE is caused in the DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo descriptors. Obviously, the actual error is in the plugin itself, where it should be exposed. It took me some hours to find this actual reason. (I still do not know, why the Mojos aren't found in my plugin, but that's another story.) The patch should be able to save the same number of hours for other plugin developers. Note: The InvalidPluginDescriptorException, which is triggered by the patch, is possibly not proper. I choosed it, because it allowed to leave the method signature unchanged and keep the patch simple. It is up to the reviewer to choose another exception. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=comments#action_54010 ] Joerg Schaible commented on MNG-1683: - Hi Oliver, seems to be a usefiul addition. We have some webapps, where we use the same javascript framework. Currently it is stored multiple times ... once for each webapp :-/ This addition would eliminate that need. > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 > Type: Improvement > Environment: not significant > Reporter: Olivier Lamy > Attachments: MNG-1683.tar.gz, maven-war-plugin.tar.gz, > maven-zip-plugin.tar.gz > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Thu Dec 22 08:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051222.083000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051222.083000.txt
[jira] Commented: (MNG-1888) (XInclude support)
[ http://jira.codehaus.org/browse/MNG-1888?page=comments#action_54009 ] Brett Porter commented on MNG-1888: --- a few more details would be extremely helpful. > (XInclude support) > -- > > Key: MNG-1888 > URL: http://jira.codehaus.org/browse/MNG-1888 > Project: Maven 2 > Type: Improvement > Reporter: Geoffrey > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1888) (XInclude support)
(XInclude support) -- Key: MNG-1888 URL: http://jira.codehaus.org/browse/MNG-1888 Project: Maven 2 Type: Improvement Reporter: Geoffrey -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1887) Guide to transforming a maven.xml goal into a plugin
Guide to transforming a maven.xml goal into a plugin Key: MNG-1887 URL: http://jira.codehaus.org/browse/MNG-1887 Project: Maven 2 Type: New Feature Components: documentation - guides Versions: 2.0.1 Reporter: Geoffrey Many users coming from maven 1 have large maven.xml files and don't really know how to start migrating those. Usually these maven.xml do simple things like copy some files or run an ant task. 3 use cases should be shown: 1) old custom assembly script can now be done by the assembly plugin 2) some ant task can be done with the antrun plugin 3) some custom script can be turned into a plugin You probably don't like solution 2) and it's indeed not the best solution, like use maven.xml in maven 1 was also not the best solution, despite that people are doing it to do things quick & dirty or as proofs of concepts, so they should be guided (and also be told that 3) is better) This could become a part of "Guide to Moving from Maven 1.x to Maven 2.x": http://maven.apache.org/guides/mini/guide-m1-m2.html But seeing the length of that one, some sort of index would be usefull (like in FAQ's). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1366) Guide to multi project setup
[ http://jira.codehaus.org/browse/MNG-1366?page=comments#action_54008 ] Geoffrey commented on MNG-1366: --- Multi project questions are very regular on the mailing list. > Guide to multi project setup > > > Key: MNG-1366 > URL: http://jira.codehaus.org/browse/MNG-1366 > Project: Maven 2 > Type: Task > Components: documentation - guides > Reporter: Jason van Zyl > > > Need to capture the best practices for setting up a multi-project build and > make a guide. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1540) ability to categorise guides in the maven site
[ http://jira.codehaus.org/browse/MNG-1540?page=comments#action_54007 ] Geoffrey commented on MNG-1540: --- Subsections in http://maven.apache.org/guides/index.html would be really usefull. for example: core (...), site (apt + site + modello + ...), dependencies (sun + dependencies), ... Human minds can't read a list longer then 7 or 9 elements. > ability to categorise guides in the maven site > -- > > Key: MNG-1540 > URL: http://jira.codehaus.org/browse/MNG-1540 > Project: Maven 2 > Type: Improvement > Components: documentation - guides > Reporter: Brett Porter > > -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
