Re: sending JIRA mail to commits@maven.apache.org
+1 (if I am allowed to vote :) To avoid having a full inbox, I use gmane.org: It turns mailing lists into newsgroups. So actually with this email, I am using the newsgroup gmane.comp.jakarta.turbine.maven.devel . I can't filter that, so it's very hard to follow the conversations. Having a different mailing list (and gmane newsgroup) would fix it. With kind regards, Geoffrey De Smet Emmanuel Venisse wrote: -0 for the same reason. Emmanuel John Casey a écrit : -0 I filter it all into a separate folder anyway, so I don't notice. I would tend to think that jira issues are much closer to the types of discussions which are meant to take place here...commits are more of the ground-level implementation details. I get it all anyway, so if you all have a strong consensus one way or the other, I'll go along. -john Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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: sending JIRA mail to commits@maven.apache.org
-0 for the same reason. Emmanuel John Casey a écrit : -0 I filter it all into a separate folder anyway, so I don't notice. I would tend to think that jira issues are much closer to the types of discussions which are meant to take place here...commits are more of the ground-level implementation details. I get it all anyway, so if you all have a strong consensus one way or the other, I'll go along. -john Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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: [vote] [m1] plugin releases
beta3 won't exist, it will be 1.0 final next week Emmanuel Arnaud HERITIER a écrit : +3 But we'll make a new scm release before the beta3 Arnaud On 2/21/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: Hi, Please vote on the release of the following m1 plugins: [] maven-artifact-plugin-1.8 [] maven-jxr-plugin-1.5 [] maven-scm-plugin-1.6 The artifact and scm releases are necessary now that the repository and release plugins are demoted, the jxr plugin was just waiting for the first JXR release, which is now available. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ Vote closes in 72h. +1 Thanks, -Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.8-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT - 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: (MNG-1181) MavenEmbedder.execute() doesn't run reactor modules
[ http://jira.codehaus.org/browse/MNG-1181?page=comments#action_59191 ] Jochen Wiedmann commented on MNG-1181: -- Jason, I can follow your points, including the "formatted differently". This one wasn't intended, btw, I went as far as creating a special Maven formatter in my Eclipse. However, please understand the following points: - I am not proposing a patch. I am posting a "proof of concept". I am mainly asking for guidance. - Without help, I am most possibly unable to fix the current MavenEmbedder, because it is too complex for me. You're the Maven expert, I am the novice. At least, I won't be able to fix it with a small patch. - I do not even understand the intended lifecycle of the MavenEmbedder, the DefaultMaven, and the objects they are using. - I am happy, if you decide to fix the MavenEmbedder without following my extended proposals. In that case I'll step aside and terminate my work on this request. If you want me to carry on, here's my plan. Understand, that I make the steps as small as possible: - I propose an object (MavenRequestConfiguration?), that may serve as a replacement of the CLI within DefaultMaven. The object will receive additional properties, as required by the MavenEmbedder. This first step doesn't include other changes than proposing this object. - You split the objects properties into two categories: Those, which should be per MavenEmbedder instance and those, which are per request. Additionally, you should provide notes on using these properties, if they have lifcycle considerations, or something similar. - The former properties are removed from the object. - I propose a patch for DefaultMaven, the Maven interface, and the MavenCli, which makes the DefaultMaven use the above object (get/setMavenRequestConfiguration(), and getters/ setters for the per embedder properties). - You accept the patch. - I propose a patch for the MavenEmbedder, which makes it use the DefaultMaven internally. - You accept the patch. - I propose a patch for the MavenCli, which makes it use the MavenEmbedder. Changes to the above proposal are fine for me. My intention is to get this thing going. (Remember, this is a five months old blocker!) > MavenEmbedder.execute() doesn't run reactor modules > --- > > Key: MNG-1181 > URL: http://jira.codehaus.org/browse/MNG-1181 > Project: Maven 2 > Type: Bug > Components: Embedding > Reporter: Eugene Kuleshov > Priority: Blocker > Fix For: 2.0.4 > Attachments: MNG-1181.tar.gz, MavenEmbedder2.java, MavenEmbedder2.java > > > MavenEmbedder.execute() doesn't run reactor modules. > I've been trying to run it with "generate-sources" goal, but it only build > the root 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]
[jira] Updated: (MRM-74) Browse web user interface
[ http://jira.codehaus.org/browse/MRM-74?page=all ] Brett Porter updated MRM-74: Fix Version: 1.0-alpha-1 > Browse web user interface > - > > Key: MRM-74 > URL: http://jira.codehaus.org/browse/MRM-74 > Project: Maven Repository Manager > Type: Task > Components: web application > Versions: 1.0-alpha-1 > Reporter: John Tolentino > Assignee: nick gonzalez > Fix For: 1.0-alpha-1 > Attachments: maven-repository-webapp-MRM-74.diff > > Original Estimate: 1 day, 16 hours > Remaining: 1 day, 16 hours > -- 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: (MRM-70) Browse by Group/Artifact/Version
[ http://jira.codehaus.org/browse/MRM-70?page=all ] Brett Porter updated MRM-70: Fix Version: 1.0-alpha-1 > Browse by Group/Artifact/Version > > > Key: MRM-70 > URL: http://jira.codehaus.org/browse/MRM-70 > Project: Maven Repository Manager > Type: Task > Components: browser > Versions: 1.0-alpha-1 > Reporter: John Tolentino > Assignee: John Tolentino > Fix For: 1.0-alpha-1 > > Original Estimate: 8 hours > Remaining: 8 hours > -- 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: (MRM-81) Search web user interface
[ http://jira.codehaus.org/browse/MRM-81?page=all ] Brett Porter updated MRM-81: Fix Version: 1.0-alpha-1 > Search web user interface > - > > Key: MRM-81 > URL: http://jira.codehaus.org/browse/MRM-81 > Project: Maven Repository Manager > Type: Task > Components: web application > Versions: 1.0-alpha-1 > Reporter: John Tolentino > Fix For: 1.0-alpha-1 > > Original Estimate: 16 hours > Remaining: 16 hours > > General search page and search result page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MRM-79) Repository Interface web user interface
[ http://jira.codehaus.org/browse/MRM-79?page=comments#action_59190 ] Brett Porter commented on MRM-79: - ping > Repository Interface web user interface > --- > > Key: MRM-79 > URL: http://jira.codehaus.org/browse/MRM-79 > Project: Maven Repository Manager > Type: Task > Components: web application > Versions: 1.0-alpha-1 > Reporter: John Tolentino > > Original Estimate: 4 hours > Remaining: 4 hours > > Manual removal of lockfile can be done here. -- 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: (MRM-14) utilise repository relocation information to update dependencies
[ http://jira.codehaus.org/browse/MRM-14?page=all ] Brett Porter updated MRM-14: Fix Version: (was: 1.0-alpha-1) > utilise repository relocation information to update dependencies > > > Key: MRM-14 > URL: http://jira.codehaus.org/browse/MRM-14 > Project: Maven Repository Manager > Type: New Feature > Components: repository-converter > Reporter: Brett Porter > > > since repoclean loads up all the poms it can know which have been relocated > and automatically update the dependency information of some poms as they are > converted. > I think this is appropriate, but maybe the original should be retained? -- 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: (MRM-11) Security policy for uploads must be in place
[ http://jira.codehaus.org/browse/MRM-11?page=all ] Brett Porter updated MRM-11: Fix Version: (was: 1.0-alpha-1) > Security policy for uploads must be in place > > > Key: MRM-11 > URL: http://jira.codehaus.org/browse/MRM-11 > Project: Maven Repository Manager > Type: Task > Components: design > Reporter: 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] Updated: (MRM-28) sync shouldn't use file sizes as basis - updated checksums are not resynced
[ http://jira.codehaus.org/browse/MRM-28?page=all ] Brett Porter updated MRM-28: Fix Version: (was: 1.0-alpha-1) > sync shouldn't use file sizes as basis - updated checksums are not resynced > --- > > Key: MRM-28 > URL: http://jira.codehaus.org/browse/MRM-28 > Project: Maven Repository Manager > Type: Bug > Components: partner sync > Reporter: Brett Porter > > > currently the sync from a partner repo does not reget checksums that have > changed, so if they are created mistakenly they are not updated. > That said, we should be warned of an occurrence where such a file changes. -- 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: (MRM-12) POI directory structure incorrectly converted from m1 repo
[ http://jira.codehaus.org/browse/MRM-12?page=all ] Brett Porter updated MRM-12: Fix Version: (was: 1.0-alpha-1) > POI directory structure incorrectly converted from m1 repo > -- > > Key: MRM-12 > URL: http://jira.codehaus.org/browse/MRM-12 > Project: Maven Repository Manager > Type: Bug > Components: repository-converter > Reporter: Carlos Sanchez > > > The POI files are in directories like > http://www.ibiblio.org/maven2/poi/poi-2.5.1-final/20040804/ > although the pom in m1 repo and the one in the m2 have a correct version tag > "2.5.1-final-20040804" -- 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: (MRM-10) syncopate needs to validate the incoming directory layout
[ http://jira.codehaus.org/browse/MRM-10?page=all ] Brett Porter updated MRM-10: Fix Version: (was: 1.0-alpha-1) > syncopate needs to validate the incoming directory layout > - > > Key: MRM-10 > URL: http://jira.codehaus.org/browse/MRM-10 > Project: Maven Repository Manager > Type: Improvement > Components: partner sync > Reporter: Brett Porter > > > we need to validate a couple of things: > 1) that the incoming content from sources is in the correct layout, and error > on stuff that isn't. dist.codehaus.org are often offenders here (eg > http://www.ibiblio.org/maven/non-codehaus/) > 2) we should probably restrict the group IDs synced, to prevent - for example > - codehaus uploading Apache artifacts over the official ones -- 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: (MRM-90) add advanced search options
[ http://jira.codehaus.org/browse/MRM-90?page=all ] Brett Porter updated MRM-90: Fix Version: (was: 1.0-alpha-1) > add advanced search options > --- > > Key: MRM-90 > URL: http://jira.codehaus.org/browse/MRM-90 > Project: Maven Repository Manager > Type: New Feature > Components: web application > Reporter: Brett Porter > > > we need to add the ability to query on particular fields and across some > ranges. -- 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: (MPCRUISECONTROL-34) FileNotFoundException with EmailPublisher
[ http://jira.codehaus.org/browse/MPCRUISECONTROL-34?page=all ] Lukas Theussl closed MPCRUISECONTROL-34: Resolution: Won't Fix Bug in CC that was fixed in version 2.3, see link above. > FileNotFoundException with EmailPublisher > - > > Key: MPCRUISECONTROL-34 > URL: http://jira.codehaus.org/browse/MPCRUISECONTROL-34 > Project: maven-cruisecontrol-plugin > Type: Bug > Versions: 1.7 > Environment: CC 2.2.1 maven 1.0.2 plugin 1.7 linux > Reporter: Michael Mattox > Attachments: config.xml, cruisecontrol.log > > > When I use the config.xml generated by the plugin I get the attached > config.xml & the output contains FileNotFoundExceptions. I searched the > mailing list and found one other person with these exceptions but no replies. > :( -- 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: [vote] Release Maven 2.0.3
+1 Lukas John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - 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: sending JIRA mail to commits@maven.apache.org
-1 Anyone subscribed to the dev list should be interested in the evolution and development of the project (otherwise he wouldn't be subscribed). JIRA is a big part of that, it really belongs here. -Lukas Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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: [vote] Release Maven 2.0.3
+1, everything seems to be working for me. John Casey wrote: > Hi, > > I think it's time to release Maven 2.0.3. This release will incorporate > 21 resolved JIRA issues, including some critical fixes for Continuum and > users of the embedder. The full listing of fixes can be found here: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=12107 > > > The remaining open issues are reminders for the site publishing process > which should accompany this binary release. > > If you're interested, you can take the current release candidate for a > test drive. The RC tarball is at: > > http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz > > > I'll leave the vote open for the customary 72 hours before summarizing. > Please cast your vote as: > > [ ] +1 Yes, release > [ ] 0 No opinion > [ ] -1 No, don't release > > Here's my +1. > > Cheers, > > John > > - > 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: [vote] Release Maven 2.0.3
+1 -Vincent > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: mercredi 22 février 2006 05:07 > To: Maven Developers List > Subject: [vote] Release Maven 2.0.3 > > Hi, > > I think it's time to release Maven 2.0.3. This release will incorporate > 21 resolved JIRA issues, including some critical fixes for Continuum and > users of the embedder. The full listing of fixes can be found here: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName > =Html&version=12107 > > The remaining open issues are reminders for the site publishing process > which should accompany this binary release. > > If you're interested, you can take the current release candidate for a > test drive. The RC tarball is at: > > http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2- > 20060222.031501.tar.gz > > I'll leave the vote open for the customary 72 hours before summarizing. > Please cast your vote as: > > [ ] +1 Yes, release > [ ] 0 No opinion > [ ] -1 No, don't release > > Here's my +1. > > Cheers, > > John > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MRM-58) create a search result class for returning from search
[ http://jira.codehaus.org/browse/MRM-58?page=all ] Edwin Punzalan closed MRM-58: - Resolution: Fixed Fixed along with MRM-57 > create a search result class for returning from search > -- > > Key: MRM-58 > URL: http://jira.codehaus.org/browse/MRM-58 > Project: Maven Repository Manager > Type: Bug > Components: indexing > Reporter: Brett Porter > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > > Original Estimate: 6 hours >Time Spent: 5 hours > Remaining: 1 hour > > instead of returning artifacts, return a search result class including > artifact, classes, packages and files -- 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: (MRM-57) ability to retrieve matched portion of classes, packages and files fields
[ http://jira.codehaus.org/browse/MRM-57?page=all ] Edwin Punzalan closed MRM-57: - Resolution: Fixed > ability to retrieve matched portion of classes, packages and files fields > - > > Key: MRM-57 > URL: http://jira.codehaus.org/browse/MRM-57 > Project: Maven Repository Manager > Type: Bug > Components: indexing > Reporter: Brett Porter > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > Attachments: MRM-57-maven-repository-indexer.patch, > MRM-57-maven-repository-indexing.patch > > Time Spent: 21 hours >Remaining: 0 minutes > > If searching by "org.apache", it would be good to just obtain the portions of > the field that matched. This might require indexing one record per class. > Need to investigate some more, and determine whether we are using that or can > do something else. -- 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: (MRM-69) Simple "query everything" search
[ http://jira.codehaus.org/browse/MRM-69?page=all ] Brett Porter updated MRM-69: Fix Version: 1.0-alpha-1 > Simple "query everything" search > > > Key: MRM-69 > URL: http://jira.codehaus.org/browse/MRM-69 > Project: Maven Repository Manager > Type: Task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > Attachments: MRM-69-maven-repository-indexer.patch, > MRM-69-maven-repository-indexer.patch, MRM-69-maven-repository-indexer.patch > > Original Estimate: 15 hours >Time Spent: 13 hours > Remaining: 2 hours > > Search keyword/term in any of the fields in the index. -- 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: (MRM-88) search by filename
[ http://jira.codehaus.org/browse/MRM-88?page=all ] Brett Porter updated MRM-88: Fix Version: 1.0-alpha-1 > search by filename > -- > > Key: MRM-88 > URL: http://jira.codehaus.org/browse/MRM-88 > Project: Maven Repository Manager > Type: Sub-task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > > Original Estimate: 2 hours > Remaining: 2 hours > -- 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: (MRM-68) Accomodate "query everything" in the index
[ http://jira.codehaus.org/browse/MRM-68?page=all ] Brett Porter updated MRM-68: Fix Version: 1.0-alpha-1 > Accomodate "query everything" in the index > -- > > Key: MRM-68 > URL: http://jira.codehaus.org/browse/MRM-68 > Project: Maven Repository Manager > Type: Task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > > Original Estimate: 20 hours >Time Spent: 17 hours, 30 minutes > Remaining: 2 hours, 30 minutes > > Index must accomodate google-like search wherein the keyword or term can be > searched on all the fields in the index. -- 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: (MRM-97) Allow hard-fail configuration for a remote repository
[ http://jira.codehaus.org/browse/MRM-97?page=all ] Brett Porter updated MRM-97: Fix Version: 1.0-alpha-1 > Allow hard-fail configuration for a remote repository > - > > Key: MRM-97 > URL: http://jira.codehaus.org/browse/MRM-97 > Project: Maven Repository Manager > Type: Task > Components: remote proxy > Versions: 1.0-alpha-1 > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 1.0-alpha-1 > > Original Estimate: 8 hours >Time Spent: 1 hour > Remaining: 0 minutes > > see maven-proxy configuration > http://cvs.maven-proxy.codehaus.org/maven-proxy/core/src/test/resources/org/apache/maven/proxy/config/PropertyLoaderTest1.properties?rev=1.1&view=markup -- 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: (MRM-54) allow nested search parameters
[ http://jira.codehaus.org/browse/MRM-54?page=all ] Brett Porter updated MRM-54: Fix Version: 1.0-alpha-1 > allow nested search parameters > -- > > Key: MRM-54 > URL: http://jira.codehaus.org/browse/MRM-54 > Project: Maven Repository Manager > Type: Task > Components: indexing > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 1.0-alpha-1 > > Original Estimate: 8 hours >Time Spent: 6 hours > Remaining: 0 minutes > > Search parameters should be nested to allow searches like >( ( groupId=1 AND artifactId=2 ) AND ( version=1 OR version=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]
[jira] Updated: (MRM-96) Enable the use of http proxies when mrm is restricted to browse directly over the net
[ http://jira.codehaus.org/browse/MRM-96?page=all ] Brett Porter updated MRM-96: Fix Version: 1.0-alpha-1 > Enable the use of http proxies when mrm is restricted to browse directly over > the net > - > > Key: MRM-96 > URL: http://jira.codehaus.org/browse/MRM-96 > Project: Maven Repository Manager > Type: Task > Components: remote proxy > Versions: 1.0-alpha-1 > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 1.0-alpha-1 > > Original Estimate: 8 hours >Time Spent: 3 hours > Remaining: 0 minutes > -- 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: (MRM-61) Searcher for metadata index
[ http://jira.codehaus.org/browse/MRM-61?page=all ] Brett Porter updated MRM-61: Fix Version: 1.0-alpha-1 > Searcher for metadata index > --- > > Key: MRM-61 > URL: http://jira.codehaus.org/browse/MRM-61 > Project: Maven Repository Manager > Type: New Feature > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > > Original Estimate: 13 hours >Time Spent: 13 hours > Remaining: 0 minutes > -- 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] Wed Feb 22 04:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060222.040001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060222.040001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3
+1 John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - 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]
[vote] Release Maven 2.0.3
Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Wed Feb 22 03:36:13 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.033613.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.033613.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with the site plugin
Sorry Brett. Will keep that in mind in the future. Issue 2 is not actually a issue. It was a user-error. Vincent, as for the site:stage goal, do you know approx when it may be available in a release ? Cheers Prasad On 2/21/06, Vincent Siveton <[EMAIL PROTECTED]> wrote: > The site:stage goal only exists in the trunk > http://jira.codehaus.org/browse/MSITE-92 > > Cheers > > Vincent > > 2006/2/21, Prasad Kashyap <[EMAIL PROTECTED]>: > > Can someone please let me know if the following issues are as designed > > or bugs that need a JIRA ? > > > > 1. The site:stage goal of the maven-site-plugin has disappeared in the > > 2.0-beta-4 version. > > > > 2. The post-site phase doesn't work. I have a simple antrun that > > echoes a msg.. It executes in the site phase but doesn't in the > > post-site phase. > > http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site > > > > Cheers > > Prasad > > > > - > > 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] Closed: (MSITE-93) post-site phase doesn't seem to work
[ http://jira.codehaus.org/browse/MSITE-93?page=all ] Prasad Kashyap closed MSITE-93: --- Resolution: Fixed user-error ! > post-site phase doesn't seem to work > > > Key: MSITE-93 > URL: http://jira.codehaus.org/browse/MSITE-93 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Prasad Kashyap > > > The post-site phase doesn't work. I have a simple antrun that echoes a msg.. > It executes in the site phase but doesn't do anything in the post-site phase. > http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site -- 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-1181) MavenEmbedder.execute() doesn't run reactor modules
[ http://jira.codehaus.org/browse/MNG-1181?page=comments#action_59183 ] Jason van Zyl commented on MNG-1181: I apologize for not looking at these issues sooner and I do appreciate the effort and I would like to integrate some of your work but the embedder is not simply a repackaging of DefaultMaven. The intention is to also provide access/manipulation of models, artifacts and repositories. I'm not intentionally trying to duplicate the code, I was attemping to entirely decouple the embedder from the CLI notions. Eventually the embedder will be used in the MavenCli, the plugin integration testing code and the Ant tasks. I'm not trying to dupe things here intentionally. I will start looking at integrating bits and pieces of your code, but patches and some discussion will get you further then just rewriting the embedder. It's not likely I'm going to replace it with something I'm unfamiliar with, formatted differently and working differently then I intended. I'm not trying to discourage you and gladly welcome the help but some smaller patches and dialog will get you much further. > MavenEmbedder.execute() doesn't run reactor modules > --- > > Key: MNG-1181 > URL: http://jira.codehaus.org/browse/MNG-1181 > Project: Maven 2 > Type: Bug > Components: Embedding > Reporter: Eugene Kuleshov > Priority: Blocker > Fix For: 2.0.4 > Attachments: MNG-1181.tar.gz, MavenEmbedder2.java, MavenEmbedder2.java > > > MavenEmbedder.execute() doesn't run reactor modules. > I've been trying to run it with "generate-sources" goal, but it only build > the root 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]
[jira] Created: (MSITE-93) post-site phase doesn't seem to work
post-site phase doesn't seem to work Key: MSITE-93 URL: http://jira.codehaus.org/browse/MSITE-93 Project: Maven 2.x Site Plugin Type: Bug Reporter: Prasad Kashyap The post-site phase doesn't work. I have a simple antrun that echoes a msg.. It executes in the site phase but doesn't do anything in the post-site phase. http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site -- 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: (MRM-88) search by filename
[ http://jira.codehaus.org/browse/MRM-88?page=all ] Maria Odea Ching closed MRM-88: --- Resolution: Fixed The searcher is already capable of this. > search by filename > -- > > Key: MRM-88 > URL: http://jira.codehaus.org/browse/MRM-88 > Project: Maven Repository Manager > Type: Sub-task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > > Original Estimate: 2 hours > Remaining: 2 hours > -- 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] Wed Feb 22 03:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.031501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sending JIRA mail to commits@maven.apache.org
That's been my main hesitation to this point, so its good to get this feedback. What do you think of other solutions: - subscribe to commits@ and filter out the actual commits - subscribe to filters from JIRA (so you get a daily mail of all the open or new issues in a particular project) - use RSS from JIRA filters - set up a group in JIRA that get sent all the same mails that [EMAIL PROTECTED] does and can be added there on request. Or should we have a jira specific list? - Brett Yann Le Du wrote: >> What do folks think of doing this to make the dev traffic a bit >> friendlier to the people just reading the messages? >> >> - Brett > > > -0 as a non-developer, for the same reasons as Mike. > As an external user who wants to keep informed of evolutions, JIRA is as > important to me as dev discussions. But SVN commits are way less important. > > - Yann > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sending JIRA mail to commits@maven.apache.org
-0 I filter it all into a separate folder anyway, so I don't notice. I would tend to think that jira issues are much closer to the types of discussions which are meant to take place here...commits are more of the ground-level implementation details. I get it all anyway, so if you all have a strong consensus one way or the other, I'll go along. -john Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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: (MNG-2095) Add "plugin-metadata-1.0.0.xsd" to http://maven.apache.org/xsd
[ http://jira.codehaus.org/browse/MNG-2095?page=comments#action_59181 ]
John Casey commented on MNG-2095:
-
I've added the following to the modello POMs:
{noformat}
site-xsd
site
xsd
{noformat}
If this is incorrect, I'll need some more instruction on how this should be
done, as I'm not too familiar with the site-generation side of Maven.
> Add "plugin-metadata-1.0.0.xsd" to http://maven.apache.org/xsd
> --
>
> Key: MNG-2095
> URL: http://jira.codehaus.org/browse/MNG-2095
> Project: Maven 2
> Type: Task
> Components: Plugin Creation Tools
> Reporter: Michael Böckling
> Assignee: John Casey
> Fix For: 2.0.3
>
>
> Please upload plugin-metadata-1.0.0.xsd to http://maven.apache.org/xsd.
> This would allow to have syntax support (proposals) in the xml-editor which
> would greatly help in writing Ant mojos.
--
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: sending JIRA mail to commits@maven.apache.org
> What do folks think of doing this to make the dev traffic a bit > friendlier to the people just reading the messages? > > - Brett -0 as a non-developer, for the same reasons as Mike. As an external user who wants to keep informed of evolutions, JIRA is as important to me as dev discussions. But SVN commits are way less important. - Yann
[jira] Updated: (MNG-2100) v3 pom properties is already supported in v4 poms and should be converted accordingly
[ http://jira.codehaus.org/browse/MNG-2100?page=all ] Edwin Punzalan updated MNG-2100: Attachment: MNG-2100-maven-model-converter.patch > v3 pom properties is already supported in v4 poms and should be converted > accordingly > - > > Key: MNG-2100 > URL: http://jira.codehaus.org/browse/MNG-2100 > Project: Maven 2 > Type: Bug > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Attachments: MNG-2100-maven-model-converter.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: (MASSEMBLY-69) "dependencies" configuration element in assembly:unpack plugin read-only
[ http://jira.codehaus.org/browse/MASSEMBLY-69?page=comments#action_59177 ] Prasad Kashyap commented on MASSEMBLY-69: - Have attached a patch. Please review and apply. > "dependencies" configuration element in assembly:unpack plugin read-only > - > > Key: MASSEMBLY-69 > URL: http://jira.codehaus.org/browse/MASSEMBLY-69 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Prasad Kashyap > Attachments: MASSEMBLY-69.patch > > > The "dependencies" configuration element in the maven-assembly-plugin is set > to read-only but the documentation on it say it's optional. > The assembly:unpack goal currently unpacks all dependencies specified in the > project. If this optional element was not read-only, it would be useful to > specify just those dependencies that needed to be unpacked. > http://maven.apache.org/plugins/maven-assembly-plugin/unpack-mojo.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2032) Bug in dependency exclusions processing (ArtifactFilter's)
[ http://jira.codehaus.org/browse/MNG-2032?page=all ] Brett Porter closed MNG-2032: - Assign To: Brett Porter Resolution: Duplicate > Bug in dependency exclusions processing (ArtifactFilter's) > -- > > Key: MNG-2032 > URL: http://jira.codehaus.org/browse/MNG-2032 > Project: Maven 2 > Type: Bug > Components: Dependencies > Versions: 2.0.2 > Reporter: Grzegorz Slowikowski > Assignee: Brett Porter > > > I thing, I found an error in dependency exclusions calculations. > For pom dependencies: > > > struts > struts > 1.2.8 > > > javax.servlet > servlet-api > > > > > jfree > jfreechart > 1.0.0 > > > gnujaxp > gnujaxp > > > > > in method MavenMetadataSource.createArtifacts the two above dependencies are > processed and ArtifactFilters are applied. The first dependency (struts) gets > ExcludesArtifactFilter( "javax.servlet:servlet-api" ) - this is OK, but > the second dependency (jfreechart) gets wrong filter - AndArtifactFilter > which concatenates ExcludesArtifactFilter( "gnujaxp:gnujaxp" ) with > ExcludesArtifactFilter( "javax.servlet:servlet-api" ). This second > ExcludesArtifactFilter comes from the first dependency (struts). Method > parameter "dependencyFilter" is overridden when processing the first > dependency and read when processing the second one. The fix should be simple. -- 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: (MASSEMBLY-69) "dependencies" configuration element in assembly:unpack plugin read-only
[ http://jira.codehaus.org/browse/MASSEMBLY-69?page=all ] Prasad Kashyap updated MASSEMBLY-69: Attachment: MASSEMBLY-69.patch > "dependencies" configuration element in assembly:unpack plugin read-only > - > > Key: MASSEMBLY-69 > URL: http://jira.codehaus.org/browse/MASSEMBLY-69 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Prasad Kashyap > Attachments: MASSEMBLY-69.patch > > > The "dependencies" configuration element in the maven-assembly-plugin is set > to read-only but the documentation on it say it's optional. > The assembly:unpack goal currently unpacks all dependencies specified in the > project. If this optional element was not read-only, it would be useful to > specify just those dependencies that needed to be unpacked. > http://maven.apache.org/plugins/maven-assembly-plugin/unpack-mojo.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2100) v3 pom properties is already supported in v4 poms and should be converted accordingly
v3 pom properties is already supported in v4 poms and should be converted accordingly - Key: MNG-2100 URL: http://jira.codehaus.org/browse/MNG-2100 Project: Maven 2 Type: Bug Reporter: Edwin Punzalan -- 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: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=all ] Allan Ramirez closed MDEPLOY-25: Resolution: Fixed -added the document in the maven-site "guide-deploying-3rd-party-jars.apt" -mentioned that the artifact would be installed both on local and remote repository > deploy:deploy-file installs the file in the local repository too (but it > should not do that) > > > Key: MDEPLOY-25 > URL: http://jira.codehaus.org/browse/MDEPLOY-25 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.1 > Reporter: Geoffrey De Smet > Assignee: Allan Ramirez > Priority: Minor > > > deploy:deploy-file installs a jar in a remote repository, but currently also > installs it in the local repository. > I believe this is a bug, because it makes you wrongly believe that the remote > repository is ok when you run local tests afterwards. > If this is the desired behaviour, please notify it on the command line and > the documentation of deploy:deploy-file > When I installed a simple hello.jar in my remote repository, I also found it > in my local repository (in my user dir) after this command: > $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello > -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi > toryId=springRichclientRepository > -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor > y > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. > 7.jar > 6b uploaded > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading repository metadata for: 'artifact org.hello:hello' > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading project information for hello 0.7 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 > [INFO] Final Memory: 2M/4M > [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] Commented: (MNG-1123) publish m2 component javadoc and reports
[ http://jira.codehaus.org/browse/MNG-1123?page=comments#action_59174 ] John Casey commented on MNG-1123: - is this for the site publishing, or attached artifacts? > publish m2 component javadoc and reports > > > Key: MNG-1123 > URL: http://jira.codehaus.org/browse/MNG-1123 > Project: Maven 2 > Type: Task > Reporter: Brett Porter > Priority: Minor > Fix For: 2.0.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]
[maven2 build trunk - SUCCESS - update] Wed Feb 22 02:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060222.023000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060222.023000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sending JIRA mail to commits@maven.apache.org
Jolly good idea. -Jan Brett Porter <[EMAIL PROTECTED]> 02/21/2006 07:11 PM Please respond to "Maven Developers List" To Maven Developers List cc Subject sending JIRA mail to commits@maven.apache.org What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Feb 22 02:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.021501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.021501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2099) Anchors in http://maven.apache.org/maven-model/maven.html are broken
Anchors in http://maven.apache.org/maven-model/maven.html are broken Key: MNG-2099 URL: http://jira.codehaus.org/browse/MNG-2099 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.2 Reporter: Yann Le Du Priority: Minor Anchors in http://maven.apache.org/maven-model/maven.html should be (e.g.) : instead of -- 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: (MRM-57) ability to retrieve matched portion of classes, packages and files fields
[ http://jira.codehaus.org/browse/MRM-57?page=all ] Maria Odea Ching updated MRM-57: Attachment: MRM-57-maven-repository-indexer.patch > ability to retrieve matched portion of classes, packages and files fields > - > > Key: MRM-57 > URL: http://jira.codehaus.org/browse/MRM-57 > Project: Maven Repository Manager > Type: Bug > Components: indexing > Reporter: Brett Porter > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > Attachments: MRM-57-maven-repository-indexer.patch, > MRM-57-maven-repository-indexing.patch > > Time Spent: 21 hours >Remaining: 0 minutes > > If searching by "org.apache", it would be good to just obtain the portions of > the field that matched. This might require indexing one record per class. > Need to investigate some more, and determine whether we are using that or can > do something else. -- 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: (MINSTALL-14) Unable to invoke install-file goal from inside a pom
Unable to invoke install-file goal from inside a pom Key: MINSTALL-14 URL: http://jira.codehaus.org/browse/MINSTALL-14 Project: Maven 2.x Install Plugin Type: Bug Reporter: Prasad Kashyap prasad hi brett.. why is that I can't use the install:install-file from inside a pom but I can use it from command line ? prasad from inside the pom i get an error that artifactid is read-only brett prasad: I think that's a bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sending JIRA mail to commits@maven.apache.org
-1 JIRA is rather important for me to see and I would assume that would be true of anyone on the dev list. I'm less concerned with individual commits. I would personally prefer it the way it is today. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 8:11 PM To: Maven Developers List Subject: sending JIRA mail to commits@maven.apache.org What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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]
[continuum build branches/continuum-1.0.x - FAILED - checkout] Wed Feb 22 02:00:01 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060222.020001.txt
RE: sending JIRA mail to commits@maven.apache.org
I vote a big +1 Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 7:11 PM To: Maven Developers List Subject: sending JIRA mail to commits@maven.apache.org What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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]
sending JIRA mail to commits@maven.apache.org
What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Wed Feb 22 01:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.014501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Wed Feb 22 01:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.011501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Wed Feb 22 00:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.003002.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060222.003002.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Wed Feb 22 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060222.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060222.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_59171 ] Allan Ramirez commented on MDEPLOY-25: -- Ok.. I 'll document it. > deploy:deploy-file installs the file in the local repository too (but it > should not do that) > > > Key: MDEPLOY-25 > URL: http://jira.codehaus.org/browse/MDEPLOY-25 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.1 > Reporter: Geoffrey De Smet > Priority: Minor > > > deploy:deploy-file installs a jar in a remote repository, but currently also > installs it in the local repository. > I believe this is a bug, because it makes you wrongly believe that the remote > repository is ok when you run local tests afterwards. > If this is the desired behaviour, please notify it on the command line and > the documentation of deploy:deploy-file > When I installed a simple hello.jar in my remote repository, I also found it > in my local repository (in my user dir) after this command: > $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello > -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi > toryId=springRichclientRepository > -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor > y > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. > 7.jar > 6b uploaded > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading repository metadata for: 'artifact org.hello:hello' > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading project information for hello 0.7 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 > [INFO] Final Memory: 2M/4M > [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]
Re: Problems with the site plugin
The site:stage goal only exists in the trunk http://jira.codehaus.org/browse/MSITE-92 Cheers Vincent 2006/2/21, Prasad Kashyap <[EMAIL PROTECTED]>: > Can someone please let me know if the following issues are as designed > or bugs that need a JIRA ? > > 1. The site:stage goal of the maven-site-plugin has disappeared in the > 2.0-beta-4 version. > > 2. The post-site phase doesn't work. I have a simple antrun that > echoes a msg.. It executes in the site phase but doesn't in the > post-site phase. > http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site > > Cheers > Prasad > > - > 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: Problems with the site plugin
Prasad Kashyap wrote: > Can someone please let me know if the following issues are as designed > or bugs that need a JIRA ? > > 1. The site:stage goal of the maven-site-plugin has disappeared in the > 2.0-beta-4 version. it never existed in beta-4 (it's new) > > 2. The post-site phase doesn't work. I have a simple antrun that > echoes a msg.. It executes in the site phase but doesn't in the > post-site phase. > http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site It should work. Please don't cross post to users and developers lists. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=comments#action_59164 ] John Didion commented on CONTINUUM-418: --- I've begun work on implementing this for our company. I will post a patch when finished. I'm having a bit of trouble figuring out the plexus site building stuff, so if someone knowledgable could get in touch with me, I'd appreciate it. > RSS feed for build status > - > > Key: CONTINUUM-418 > URL: http://jira.codehaus.org/browse/CONTINUUM-418 > Project: Continuum > Type: Wish > Versions: 1.0 > Reporter: David Blevins > Priority: Minor > > > Lyndon Samson suggested on the Geronimo dev list that an rss feed for > reporting build status would be a really great way to report build status. > A neat application of that feature would be the ability to include continuum > data on a confluence page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-366) add support for rss feed generation
[ http://jira.codehaus.org/browse/CONTINUUM-366?page=comments#action_59163 ] John Didion commented on CONTINUUM-366: --- This bug should be closed. RSS does not fit the notifier pattern as it is pull, not push. CONTINUUM-418 addresses this issue correctly. > add support for rss feed generation > --- > > Key: CONTINUUM-366 > URL: http://jira.codehaus.org/browse/CONTINUUM-366 > Project: Continuum > Type: New Feature > Reporter: yo > Fix For: 1.1 > > > add support for generating rss feeds as notifier -- 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
[maven2 build trunk - SUCCESS - update] Tue Feb 21 22:00:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060221.220001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060221.220001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] plugin releases
+3 But we'll make a new scm release before the beta3 Arnaud On 2/21/06, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > Hi, > > Please vote on the release of the following m1 plugins: > > [] maven-artifact-plugin-1.8 > [] maven-jxr-plugin-1.5 > [] maven-scm-plugin-1.6 > > The artifact and scm releases are necessary now that the repository and > release plugins are demoted, the jxr plugin was just waiting for the > first JXR release, which is now available. > > Please check the changes and jira reports on the preliminary project > pages: > > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ > > > Vote closes in 72h. > > +1 > > Thanks, > -Lukas > > > maven plugin:download > -Dmaven.repo.remote=http://www.ibiblio.org/maven, > http://cvs.apache.org/repository/ > -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.8-SNAPSHOT > > maven plugin:download > -Dmaven.repo.remote=http://www.ibiblio.org/maven, > http://cvs.apache.org/repository/ > -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT > > maven plugin:download > -Dmaven.repo.remote=http://www.ibiblio.org/maven, > http://cvs.apache.org/repository/ > -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[jira] Closed: (MPJAVA-21) Unable to add something to java:compile classpath
[ http://jira.codehaus.org/browse/MPJAVA-21?page=all ] Lukas Theussl closed MPJAVA-21: --- Assign To: (was: Jason van Zyl) Resolution: Won't Fix Fix Version: (was: 1.6) I don't think it is a good idea to do that. Only things that are declared as dependencies should be added to the classpath, is there a reason for not adding those libs as dependencies? As a workaround, you may use the maven:addPath tag in a pregoal to java:compile. > Unable to add something to java:compile classpath > - > > Key: MPJAVA-21 > URL: http://jira.codehaus.org/browse/MPJAVA-21 > Project: maven-java-plugin > Type: Wish > Reporter: Stepan Koltsov > Priority: Minor > > > It is not possible to add anything to classpath used in java:compile in javac > task. Its could be generated libraries (using XMLBeans for example) or other > libraries stored somewhere in "lib/" (we store some libraries in CVS, they > are placed there). > As workaround it's possible to edit maven.dependency.path, but that is dirty. > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
jason and I had a nice chat about this on #plexus today when I asked a question about getting the right logger instance inside of an object built out by lookup(ROLE).. Here is the framework that we worked out...there are two lvls to it but in a nutshell it is a nice approach I think, very much along the lines of what brett was talking about. First off we build out a AbstractMojoTestCase that is a child of PlexusTestCase and in this we add a method that can be used like this: MyMojo mojo = (MyMojo) lookup ( Mojo.ROLE, path_to_pom ); now, the way this works is that in the src/test/resources (or whatever) directory we start building out a number of directories for different test cases and in those directories we put pom.xml files that contain the plugin declaration and the configuration parameters... these poms can be used in one of two different ways: 1) they can be used to instantiate the mojo through the above lookup method inside of java unit tests, giving you the fully instantiated mojo that you can execute all of the unit tests you like 2) they can be iterated over in a testing battery where we can do verification on the output of the plugin, a la the integration tests the lookup() method above can use the default plugin manager for a lot of the work I guess. Some of this gets into murky territory for me since I haven't dug into that area of maven, but it all seems like it ought to work pretty smooth. We would probably want to split out the directory structure for the 1) and 2) points above so we can distingish between them in the test running harness but...or perhaps even just use the embedder/integration plugin for much/all of the second one, depends on what kind of verification system we want to use. But the interesting part would be the ability to use the mojo lookup much like bret was mentioning above. so if people are comfortable with this approach I'll work on hammering out a moderately working implementation so we can make sure the api is clean and what we are looking for. jason was very keen on the something along the lines of lookup(mojo, configuration) but we started getting bogged down in details on what that object would look like since it would need to seed the mojo for an arbitrary number and type of private variables... the nice part of using a pom is that we get a pretty good build out of the whole deal, dependencies and all if need be...and it is a _very_ natural extension for maven and mojo users. We can provide a few examples of building out the test cases and it should flow very naturally...and what I like, expose people to a bit more to the way plexus is used to build objects in maven... hm...and the same deal might work if you were wanting to put a inner class extending abstract mojo test case on the mojo for testing private methods...kinda interesting anyway thoughts? jesse On 2/21/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Thanks for this! > > Jesse McConnell wrote: > > 1) so I did it once with just a normal junit test class and put the > setters > > on the mojo. Very little new code had to be added to get it working and > it > > was trivial to take that plugin up to about 85% coverage...the remainder > > being some workaround for a windows jdk shortcoming. > > I almost get 100% on Windows :) > > Just needs a test that if you try and delete something that's not > allowed to be, it throws an exception. And test John's changes that came > after this :) > > > 2) then I redid it using the approach that Trygvis was doing in his > > deb-maven-plugin where you make the mojo a basic adapter to the > > implementation which is put together in a standard plexus layoutthis > > forced the generation of a fair bit more code and a couple of additional > > classes, but it certainly felt more true to the nature of what a mojo > > is...at least my perception of what a mojo is :) > > http://cvs.codehaus.org/changelog/mojo?cs=1478&@csTruncateDiffs=false# > > I recently did the separated content and found it extremely tedious to > implement, so I moved back to not doing that - but it depends on the > situation as we generally do what you are suggesitng anyway. > > The original idea was for a mojo was that it could be reused anywhere > (automatically generating an ant task wrapper, for example). I think > we've steered away from that practically though idealogically would > still like them to be the reusable components. We steered away mostly > because: > 1) the plugin api dependency and extending AbstractMojo > 2) the amount of extra work it is to populate the mojo variables, > especially when it comes to wiring up the plexus components which is so > wasy as is. > > I think its good to abstract things out like you've done to a degree, > but I think the right level for clean is pretty much where it is: > deleteDirectory. Some of this needs to move to plexus utils, and the > clean plugin should really be delete target, delete output, delete test > output. WDYT? > > So far
RE: plugin testing
> -Original Message- > From: Jesse McConnell [mailto:[EMAIL PROTECTED] > Sent: mardi 21 février 2006 00:45 > To: Maven Developers List > Subject: Re: plugin testing > > ok, I fiddled around a bit today with the clean plugin as a basic test > case... > > I really don't like the idea of putting setters on the mojo...not sure > why, > but it bugs me, probably because it is really only putting them there for > testing purposes which is generally a no-no. Funnily it's quite the opposite for me. When a unit test wants something that is not in the main source files, I consider this as a code smell. It usually means my code is not flexible enough or has a design issue and needs refactoring. In addition, I personally believe private field injection is a bit too "magical" to my taste. We had discussed allowing setters in the past. I guess you're not yet part of the unit testing addicts who consider that unit testing is a design activity and that tests are a side-effect of this... ;-) [...] > So I am curious as to what people think about that idea of having the > mojo's > setup in that way? It seems a bit heavywieght for the clean plugin but > how > important is it to not put those setters on the mojo? I have always been > a > bit of a fan for the correct conceptual way as opposed to the cheap and > easy...though the cheap and easy can be faster :) For me the conceptually correct one is almost always the mock solution because it forces you to refactor to offer a flexible and open architecture. However sometime you don't have the time for this and you go for stubs. But then you risk adding to your technical debt (http://www.martinfowler.com/bliki/TechnicalDebt.html). Now I agree it's not always that black and white... BTW, I'm playing the devil's advocate here so take my words with a grain of salt. I'm just answering to fuel the conversation! :-) [...] > so I am not really proposing anything with this followup mail...I'll > generate a patch with my first test case setup for the clean plugin and > put > that in jira... I am however wondering if people generally like the > plexified approach for the plugin implementation? I wouldn't be adverse > to > converting a couple more over to see how they lookand it does make > them > feel a bit more modular and useful outside of maven for a toolset like > axistools, sablecc, or javacc since normal people don't have a facility > for > injecting those params.. I think you're right and the next step is probably to see some tests in action. BTW it could be interesting to see tests for the same plugin coded with both approaches (after refactoring to suit the mock approach, if need be ;-)). -Vincent > On 2/19/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > > > after reading up on mocks from the links that vincent posted, I am going > > to take a stab at putting together a minor set of these to work with for > a > > couple of the plugins...just to see how it would work out. Hopefully I > can > > get with vincent a bit tomorrow to make sure I get it close to right the > > first time > > > > jesse > > > > On 2/18/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > Vincent Massol wrote: > > > > I think what you're describing is a stub but not a mock. The > advantage > > > of a > > > > dynamic mock is that you don't need to code any method. It's the > user > > > of the > > > > mock which says what behavior it should have for the methods it > calls > > > on the > > > > mock. > > > > > > You're right, I've always referred to stubs incorrectly as mocks. I > > > meant a stub. I think it's in our interest to produce these to make > > > testing easier and more consistent for everyone. > > > > > > I'm interested to see your thoughts on the mocks eventually though - > > > I've never really done anything with them since I was reading JiA > (which > > > I don't have any more :( > > > > > > - Brett > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > jesse mcconnell > > jesseDOTmcconnellATgmailDOTcom > > > > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJAVA-42) Generate files are not compiled if not generated files are not present
[ http://jira.codehaus.org/browse/MPJAVA-42?page=all ] Lukas Theussl closed MPJAVA-42: --- Resolution: Fixed Fix Version: 1.6 > Generate files are not compiled if not generated files are not present > -- > > Key: MPJAVA-42 > URL: http://jira.codehaus.org/browse/MPJAVA-42 > Project: maven-java-plugin > Type: Bug > Environment: Running maven rc4 with maven-javacc-plugin-1.1 and > maven-javacc-plugin-1.4 > Reporter: Kenneth Leider > Priority: Minor > Fix For: 1.6 > > > Generated sources are placed in the target/generated-src/java/main directory, > and this directory is added to maven.compile.src.set. > However when the maven-java-plugin runs the compile goal, it skips > compilation completely because the "sourcesPresent" variable is not "true". > I can only assume this variable is set if the sources listed in the pom > resolve to files. -- 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] Tue Feb 21 21:15:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060221.211503.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.211503.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with the site plugin
Can someone please let me know if the following issues are as designed or bugs that need a JIRA ? 1. The site:stage goal of the maven-site-plugin has disappeared in the 2.0-beta-4 version. 2. The post-site phase doesn't work. I have a simple antrun that echoes a msg.. It executes in the site phase but doesn't in the post-site phase. http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site Cheers Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Tue Feb 21 21:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060221.210001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060221.210001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCM-139) Create a utility class for scm url checking/parsing
[ http://jira.codehaus.org/browse/SCM-139?page=all ] Dennis Lundberg updated SCM-139: Attachment: SCM-139-2.zip > Create a utility class for scm url checking/parsing > --- > > Key: SCM-139 > URL: http://jira.codehaus.org/browse/SCM-139 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Reporter: Dennis Lundberg > Attachments: SCM-139-2.zip, SCM-139.zip, ScmUrlUtils.java > > > There is a lot of code in different places, both in maven-scm and elsewhere, > that checks and parses scm url:s. I propose that a utility class ScmUrlUtils > be crated in maven-scm-api where such code (static methods) can be placed. > The code there should not be scm provider specific. This should be > accompanied by a test suite. > This concept might also be applied to individual scm providers, e.g. there > could be a CvsScmUrlUtils in maven-scm-provider-cvs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2003) release and update to wagon-file 1.0-alpha-7
[ http://jira.codehaus.org/browse/MNG-2003?page=all ] John Casey closed MNG-2003: --- Resolution: Fixed released and updated in maven/pom.xml > release and update to wagon-file 1.0-alpha-7 > > > Key: MNG-2003 > URL: http://jira.codehaus.org/browse/MNG-2003 > Project: Maven 2 > Type: Task > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Brett Porter > Assignee: John Casey > Priority: Blocker > Fix For: 2.0.3 > > > to fix regression WAGON-30 -- 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: (SCM-139) Create a utility class for scm url checking/parsing
[ http://jira.codehaus.org/browse/SCM-139?page=all ] Dennis Lundberg updated SCM-139: Attachment: SCM-139.zip > Create a utility class for scm url checking/parsing > --- > > Key: SCM-139 > URL: http://jira.codehaus.org/browse/SCM-139 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Reporter: Dennis Lundberg > Attachments: SCM-139.zip, ScmUrlUtils.java > > > There is a lot of code in different places, both in maven-scm and elsewhere, > that checks and parses scm url:s. I propose that a utility class ScmUrlUtils > be crated in maven-scm-api where such code (static methods) can be placed. > The code there should not be scm provider specific. This should be > accompanied by a test suite. > This concept might also be applied to individual scm providers, e.g. there > could be a CvsScmUrlUtils in maven-scm-provider-cvs. -- 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
[maven2 build branches/maven-2.0.x - SUCCESS - update] Tue Feb 21 20:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060221.204501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.204501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-598) Ability to specify which scm connection should be used to build the project (connection or developerConnection)
Ability to specify which scm connection should be used to build the project (connection or developerConnection) --- Key: CONTINUUM-598 URL: http://jira.codehaus.org/browse/CONTINUUM-598 Project: Continuum Type: New Feature Components: Web interface, Core system Versions: 1.0, 1.0.1, 1.0.2 Reporter: Igor Vaynberg i am a committer on a sf.net project. the anonymous cvs access is extremely unstable, but the developer access is rock solid. since i am a developer and i run a continuum server i am in a position to leverage the developer scm connection. it would be great if i can just tell continuum to use the developerConnection scm url rather then the regular connection scm url. i tried chaning the url in the project info manually, but after the project is built once the url reverts back to the one in the pom ( as it should i would imagine ) i think a simple drop down in project info with connection/developerConnection choice would be great -- 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
[maven2 build trunk - SUCCESS - update] Tue Feb 21 20:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060221.203000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060221.203000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repo selection [Was: JIRA MNG-2098]
Thought it was appropriate to bring my comments out of the jira issue for discussion on the list. Basically, I want to work on a more elegant fix for this issue but am requesting some community guidance. Specifically for the issue: 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment. but the more pressing issue is 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata. Thanks, Garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2006) Module SCM URL is resolved as [...]/parent/module regardless of relativePath
[ http://jira.codehaus.org/browse/MNG-2006?page=all ] John Casey closed MNG-2006: --- Resolution: Fixed Implemented the following strategy for determining module path adjustments for URLs: 1. look for module-project file, and parent-project file, and compute directory shift from parent-project section based on that. 2. look for module-project artifactId, and parent-project section, and match where the artifactid is the last path part for a given module in the parent. Using is difficult, since the pom files are not always going to be populated for this method, particularly when computing model inheritance. This should work in most normal cases. Where it doesn't, it's still possible to override the value in the child pom. > Module SCM URL is resolved as [...]/parent/module regardless of relativePath > > > Key: MNG-2006 > URL: http://jira.codehaus.org/browse/MNG-2006 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Versions: 2.0.2 > Environment: Maven 2.0.2 > Continuum 1.0.2 with maven-scm-*-1.0-beta-3-20060115.041342-*.jar > Reporter: Yann Le Du > Assignee: John Casey > Priority: Blocker > Fix For: 2.0.3 > > > Quoting Emmanuel Venisse from user list : > Ok, it's a bug in > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=306518&view=markup > in assembleScmInheritance method. > This method append parent scm connection url and artifactId without look at > relativePath. > For detailed description see > http://www.nabble.com/-m2-Multiprojects-and-inherited-SCM-URLs-t951105.html > Project structure : > PROJECT > PROJECT/parent > PROJECT/parent/pom.xml > PROJECT/module > PROJECT/module/pom.xml > parent/pom.xml : > scm:svn:svn://host/PROJECT/parent/ > ../module > module/pom.xml : > ../parent/pom.xml > When I add module in Continuum, its url is resolved as : > scm:svn:svn://host/PROJECT/parent/module -- 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-2098) Artifact resolver incorrectly selects repository which doesn't contain the selected version
Artifact resolver incorrectly selects repository which doesn't contain the selected version --- Key: MNG-2098 URL: http://jira.codehaus.org/browse/MNG-2098 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Garrett Conaty Attachments: MNG-2098.simplefix.diff, pom.xml The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range. However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact. It currently just sets it to the last repository that had versions to merge. What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions. Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown. So there are a couple of issues here 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment. but the more pressing issue is 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata. The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method. This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match. What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range. -- 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-2098) Artifact resolver incorrectly selects repository which doesn't contain the selected version
[ http://jira.codehaus.org/browse/MNG-2098?page=all ] Garrett Conaty updated MNG-2098: Attachment: MNG-2098.simplefix.diff > Artifact resolver incorrectly selects repository which doesn't contain the > selected version > --- > > Key: MNG-2098 > URL: http://jira.codehaus.org/browse/MNG-2098 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Garrett Conaty > Attachments: MNG-2098.simplefix.diff, pom.xml > > > The current logic for resolution of an artifact which has groupId/artifactId > and then a range is for the DefaultArtifactCollector to call > MavenMetadataSource and retrieve the available versions and then match the > available versions to the range. > However, a side effect exists in that the DefaultRepositoryMetadataManager in > its call to mergeMetadata sets the repository for the artifact. It currently > just sets it to the last repository that had versions to merge. What occurs > here though is that it can be set to a repository that doesn't actually have > the artifact that is selected as part of the match of version range to > available versions. Then when this artifact is passed to the resolver to > download the JAR it references, it of course can't find it and an exception > is thrown. > So there are a couple of issues here > 1) Should the DefaultArtifactResolver really use artifact.getRepository() > exclusively if it's not null? Perhaps the Artifact really ought to contain a > list of repositories that are acceptable (from the transformation phase) from > which to try. This may be a good enhancment. > but the more pressing issue is > 2) Shouldn't the DefaultArtifactCollector actually do the repository > selection, not have it be a side effect of getting the metadata. > The simple patch I've attached solves the problem by just removing the call > to setRepository in the mergeMetadata method. This has the effect that there > will be no repository chosen by the time the DefaultArtifactResolver gets a > hold of the artifact and it will then go through the list of > remoteRepositories until it finds a succesful match. > What I'd like to do though is really modify the DefaultArtifactCollector and > MavenMetadataSource so that the collector can make the decision about what > repository/list of repositories to use, and in the very least choose the > repository that has the version that was matched in the range. -- 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 - FAILED - update] Tue Feb 21 20:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.201500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MANTRUN-44) No way to skip antrun when -Dmaven.test.skip is set
No way to skip antrun when -Dmaven.test.skip is set --- Key: MANTRUN-44 URL: http://jira.codehaus.org/browse/MANTRUN-44 Project: Maven 2.x Antrun Plugin Type: Bug Reporter: Dan Diephouse Fix For: 1.2 I can't figure out a way to not have the ant-run plugin execute when in the generate-test-resources phase and -Dmaven.test.skip is set. I think we need something like: 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 - FAILED - update] Tue Feb 21 19:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.194500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJAVA-41) Allow the generation of the compiler output report although compilation fails
[ http://jira.codehaus.org/browse/MPJAVA-41?page=all ] Lukas Theussl closed MPJAVA-41: --- Resolution: Fixed Introduced a maven.compile.failonerror property. > Allow the generation of the compiler output report although compilation fails > - > > Key: MPJAVA-41 > URL: http://jira.codehaus.org/browse/MPJAVA-41 > Project: maven-java-plugin > Type: Improvement > Versions: 1.6 > Reporter: Carlos Sanchez > Fix For: 1.6 > > -- 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 - FAILED - update] Tue Feb 21 19:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.191501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJAVA-32) Support maven.compile.debuglevel property
[ http://jira.codehaus.org/browse/MPJAVA-32?page=all ] Lukas Theussl closed MPJAVA-32: --- Resolution: Fixed > Support maven.compile.debuglevel property > - > > Key: MPJAVA-32 > URL: http://jira.codehaus.org/browse/MPJAVA-32 > Project: maven-java-plugin > Type: Improvement > Reporter: Andrew Wason > Fix For: 1.6 > > > Support a maven.compile.debuglevel property that corresponds to the Ant javac > task debuglevel (i.e. maps to javac -g:lines,vars,source). I normally build > production code using lines,source and maven.compile.debug only lets me turn > debug full on or full off. -- 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-2097) adding a phase called prepare-package
adding a phase called prepare-package - Key: MNG-2097 URL: http://jira.codehaus.org/browse/MNG-2097 Project: Maven 2 Type: New Feature Components: Plugins and Lifecycle Versions: 2.0.2 Environment: all Reporter: Olivier Lamy Hi, I have an artifact (packaging war). I have some jobs to do (xdoclet-maven-plugin others internal plugin) which are only needed for included materials in the war : - web.xml - automatic generated pages (about page etc..) Actually I attached it tho the phase process-classes or test. But when I just want to try a simple the simple : mvn -Dtest=something clean test. All of my .java are parsed by the plugin and all other jobs made whereas this should be done in a phase just before packaging. I really need a phase just before package to place all this jobs. Probably this can be extends to phase deploy. 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]
[jira] Updated: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=all ] Carlos Sanchez updated MAVENUPLOAD-742: --- Attachment: qalab-patch.diff > Please upload maven-qalab-plugin > > > Key: MAVENUPLOAD-742 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Attachments: maven-qalab-plugin-2.0-bundle.jar, qalab-patch.diff > > > this plugin provides the basic merge and movers mojos and main and movers > reports taking input from checkstyle, PMD and findbugs and reporting > statistical quality data over the life of the project. > it's a reworking of the maven 1 plugin for maven 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]
[jira] Closed: (MAVENUPLOAD-750) JiBX upload bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-750?page=all ] Carlos Sanchez closed MAVENUPLOAD-750: -- Assign To: Carlos Sanchez Resolution: Fixed > JiBX upload bundles > --- > > Key: MAVENUPLOAD-750 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-750 > Project: maven-upload-requests > Type: Task > Reporter: Michael Böckling > Assignee: Carlos Sanchez > Attachments: jibx-bind-1.0.1-bundle.jar, jibx-bind-1.0.1-bundle.jar, > jibx-extras-1.0.1-bundle.jar, jibx-extras-1.0.1-bundle.jar, > jibx-run-1.0.1-bundle.jar, jibx-run-1.0.1-bundle.jar > > > JiBX is a framework for binding XML data to Java objects. > Downloaded from: http://sourceforge.net/project/showfiles.php?group_id=69358 > Now you know why I needed xpp3 uploaded. :-) > I wonder if this time I got it right in the first try... -- 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: repository manager overview
Looks like a promising tool. I tried IndexSearcherCli, but found out it needs to make an index first and there isn't one available for ibiblio yet. Will the indexes be available on a public server (through a xfire/hessian/httpinvoker webservice) or will everyone need to make it's own index to be able to use the command line tool (or a Swing GUI)? Or will it only be available through google-like website? PS: Anyone else experiencing this problem? I checked out the source, but regularly got: ... Amaven-repository-discovery/src/main svn: Can't move 'maven-repository-discovery/src/main/.svn/tmp/entries' to 'maven-repository-discovery/src/main/.svn/entries': Permission denied It must be something with my local cygwin svn 1.2.3 client, because after a couple times svn update worked. Just wanted to note it, in case anyone else seeing this. jerome lacoste wrote: On 2/8/06, Brett Porter <[EMAIL PROTECTED]> wrote: Some folks seem interested, so I wanted to give a quick overview of the repository manager. It is an application that runs either standalone or as a webapp with the following functionality: - repository search - repository/artifact browsing and display of artifacts and their relationships - repository health reports (missing transitive dependencies, incorrect/missing checksums, incorrect/missing digital signatures, out of place artifacts, missing poms, etc) - maven-proxy like support - repository conversion It has the following modules: - discovery: walks a repository and finds all the artifacts in it so you can perform a certain action on each, or just the ones that are new/deleted since last walked. - indexer: used to add artifacts and metadata to the lucene index. Includes elements of the POM and checksums - converter: copy artifacts from one repository to the other, changing layout, converting metadata if required. - artifact-applet: applet to allow you to checksum a large artifact on your local machine and upload the checksum to the server to search - reports-standard: a bunch of reports on the status of an artifact in the repository - proxy: maven-proxy like functionality - utils: checksum, pathing, etc - webapp: webwork 2 and plexus based webapp for running it all Any questions? Just what I was looking for. Thanks for pointing it out on the user list. I guess this is the URL, right? http://svn.apache.org/viewcvs.cgi/maven/repository-manager/trunk/ J -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=comments#action_59142 ] Carlos Sanchez commented on MAVENUPLOAD-742: I have tried the plugin from http://cvs.sourceforge.net/viewcvs.py/qalab/maven2-qalab-plugin/ and doesn't even build, non exisitng versions, depends on itself,... please check attached patch to see the improvements I needed to make it build As it depends in the findbugs plugin that wasn't yet released, I can't upload it to ibiblio (you can't make a release depending on a snapshot as it changes). > Please upload maven-qalab-plugin > > > Key: MAVENUPLOAD-742 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Attachments: maven-qalab-plugin-2.0-bundle.jar > > > this plugin provides the basic merge and movers mojos and main and movers > reports taking input from checkstyle, PMD and findbugs and reporting > statistical quality data over the life of the project. > it's a reworking of the maven 1 plugin for maven 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]
[maven2 build branches/maven-2.0.x - FAILED - update] Tue Feb 21 18:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060221.184501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MCOMPILER-28) goal compile throws exception when src/main/java doesn't exist
[ http://jira.codehaus.org/browse/MCOMPILER-28?page=all ] Lukas Theussl moved MPASPECTJ-25 to MCOMPILER-28: - Workflow: Maven (was: jira) Key: MCOMPILER-28 (was: MPASPECTJ-25) Project: Maven 2.x Compiler Plugin (was: maven-aspectj-plugin) > goal compile throws exception when src/main/java doesn't exist > -- > > Key: MCOMPILER-28 > URL: http://jira.codehaus.org/browse/MCOMPILER-28 > Project: Maven 2.x Compiler Plugin > Type: Bug > Environment: linux > Reporter: M. van der Plas > > > I've create a profile in our companies generic root pom to use aspectj. > In the configuration of the aspectj plugin I've added the goals compile and > test-compile. > Sometimes a project only consists of test classes, with the src/main/java > directory non-existent. > When the profile for these projects is activated, I get the exception listed > below. > Is it possible to ignore this exception ? > ERROR] FATAL ERROR > [INFO] > > [INFO] basedir D:\workspace\tracetest\src\main\java does not exist > [INFO] > > [INFO] Trace > java.lang.IllegalStateException: basedir D:\workspace\tracetest\src\main\java > does not exist >at > org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542) >at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1402) >at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1368) >at > org.codehaus.mojo.aspectj.AjcHelper.getBuildFilesForSourceDirs(AjcHelper.java:137) >at > org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:272) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java: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:85) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) >at java.lang.reflect.Method.invoke(Method.java:391) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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]
