wagon testing
(as sent to users@) In the lead up to the 2.0.2 release, I'd like anyone experiencing: [WAGONSSH-28] session is down [WAGONSSH-30] hangs during deployment to test the following wagon snapshots: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/wagon/wagon-ssh/1.0-alpha-6-SNAPSHOT/wagon-ssh-1.0-alpha-6-20060105.062346-2.jar by including it in your $M2_HOME/lib directory. Please also include: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6-SNAPSHOT/wagon-provider-api-1.0-alpha-6-20060105.062346-7.jar and http://www.ibiblio.org/maven2/com/jcraft/jsch/0.1.24/jsch-0.1.24.jar Replace any existing wagon/jsch libraries. Another way to test is to pick up the following integration build instead: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060105.071501.tar.gz With this build, you can also test scpexe and sftp if you were having any problems with them. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Thu Jan 5 07:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060105.071501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060105.071501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r366101 - in /maven/components/branches/maven-2.0.x: maven-core/pom.xml pom.xml
thanks! Fixed. - Brett Lukas Theussl wrote: > You have the wrong JIRA issue in the log, it should be MNG-1907. > > -Lukas > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r366101 - in /maven/components/branches/maven-2.0.x: maven-core/pom.xml pom.xml
You have the wrong JIRA issue in the log, it should be MNG-1907. -Lukas [EMAIL PROTECTED] wrote: Author: brett Date: Wed Jan 4 23:02:46 2006 New Revision: 366101 URL: http://svn.apache.org/viewcvs?rev=366101&view=rev Log: [MAVEN-1907] Include scpexe wagon by default, and upgrade to alpha-6 SNAPSHOT Modified: maven/components/branches/maven-2.0.x/maven-core/pom.xml maven/components/branches/maven-2.0.x/pom.xml Modified: maven/components/branches/maven-2.0.x/maven-core/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/branches/maven-2.0.x/maven-core/pom.xml?rev=366101&r1=366100&r2=366101&view=diff == --- maven/components/branches/maven-2.0.x/maven-core/pom.xml (original) +++ maven/components/branches/maven-2.0.x/maven-core/pom.xml Wed Jan 4 23:02:46 2006 @@ -143,16 +143,11 @@ org.apache.maven.wagon wagon-ssh runtime - - - plexus-utils - plexus - - - plexus-container-default - org.codehaus.plexus - - + + + org.apache.maven.wagon + wagon-ssh-external + runtime org.codehaus.plexus @@ -165,4 +160,4 @@ scp://minotaur.apache.org//www/maven.apache.org/m2 - \ No newline at end of file + Modified: maven/components/branches/maven-2.0.x/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/branches/maven-2.0.x/pom.xml?rev=366101&r1=366100&r2=366101&view=diff == --- maven/components/branches/maven-2.0.x/pom.xml (original) +++ maven/components/branches/maven-2.0.x/pom.xml Wed Jan 4 23:02:46 2006 @@ -154,13 +154,6 @@ http://www.apache.org/ - - -org.apache.maven.wagon -wagon-ssh-external -1.0-alpha-5 - - @@ -304,22 +297,27 @@ org.apache.maven.wagon wagon-provider-api -1.0-alpha-5 +1.0-alpha-6-SNAPSHOT org.apache.maven.wagon wagon-ssh -1.0-alpha-5 +1.0-alpha-6-SNAPSHOT + + +org.apache.maven.wagon +wagon-ssh-external +1.0-alpha-6-SNAPSHOT org.apache.maven.wagon wagon-file -1.0-alpha-5 +1.0-alpha-6-SNAPSHOT org.apache.maven.wagon wagon-http-lightweight -1.0-alpha-5 +1.0-alpha-6-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1907) Bundle wagon-ssh-external with maven dist
[ http://jira.codehaus.org/browse/MNG-1907?page=all ] Brett Porter closed MNG-1907: - Resolution: Fixed > Bundle wagon-ssh-external with maven dist > - > > Key: MNG-1907 > URL: http://jira.codehaus.org/browse/MNG-1907 > Project: Maven 2 > Type: Improvement > Versions: 2.0.1, 2.0.2 > Environment: All > Reporter: Arik Kfir > Assignee: Brett Porter > Priority: Minor > Fix For: 2.0.2 > > > Bootstraping maven fails if 'settings.xml' has a repository with 'scpexe' url > - the IT tests fail with exceptions stating that "Unsupported Protocol: > 'scpexe': Cannot find wagon which supports the requested protocol: scpexe" > While this can easily be worked around by temporarily disabling the repo in > settings.xml - I think a much better solution would be to bundle > 'wagon-ssh-external' with Maven, since it is very common and in wise use > (well, until the jscp issues are solved ;-) > Shouldn't affect the dist size since its only a few KB in size and the > benefit is cool... > To reproduce, make sure the scpexe-repo is in an active profile and try to > bootstrap. -- 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-1419) resolve outstanding wagon issues
[ http://jira.codehaus.org/browse/MNG-1419?page=all ] Brett Porter updated MNG-1419: -- Assign To: Brett Porter Fix Version: (was: 2.0.3) 2.0.2 > resolve outstanding wagon issues > > > Key: MNG-1419 > URL: http://jira.codehaus.org/browse/MNG-1419 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0.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: (MASSEMBLY-51) assembly:attached fails
[ http://jira.codehaus.org/browse/MASSEMBLY-51?page=all ] Dan Tran updated MASSEMBLY-51: -- Attachment: pom.xml > assembly:attached fails > --- > > Key: MASSEMBLY-51 > URL: http://jira.codehaus.org/browse/MASSEMBLY-51 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.1 > Environment: xp, jdk 1.5, maven-2.0|2.0.1|2.0.2-SNAPHOT > Reporter: Dan Tran > Priority: Blocker > Fix For: 2.1 > Attachments: pom.xml > > > I bind assembly:attached to package phase. mvn install return this > [INFO] Scanning for projects... > [INFO] > - > --- > [INFO] Building Optimizeit Assembly > [INFO]task-segment: [install] > [INFO] > - > --- > [INFO] > - > --- > [ERROR] BUILD ERROR > [INFO] > - > --- > [INFO] One or more required plugin parameters are invalid/missing for > 'assembly: > attached' > [0] on the command line, specify: '-DexecutedProject=VALUE' > run mvn assembly:attached shows the same thing. This is from latest assembly > plugin source -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-44) search by group, artifact and version
[ http://jira.codehaus.org/browse/MRM-44?page=all ] Maria Odea Ching updated MRM-44: Attachment: MRM-44-maven-repository-indexer.patch > search by group, artifact and version > - > > Key: MRM-44 > URL: http://jira.codehaus.org/browse/MRM-44 > Project: Maven Repository Manager > Type: Sub-task > Components: indexing > Reporter: Brett Porter > Assignee: Maria Odea Ching > Fix For: 1.0-alpha-1 > Attachments: MRM-44-maven-repository-indexer.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] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (8 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-664jlmenu 1.0 http://jira.codehaus.org/browse/MAVENUPLOAD-664 MAVENUPLOAD-663please upload jtds (bundle provided) http://jira.codehaus.org/browse/MAVENUPLOAD-663 MAVENUPLOAD-644Maven Jini Plug-in version 2.0 http://jira.codehaus.org/browse/MAVENUPLOAD-644 MAVENUPLOAD-662Some Findbugs jars are corrupt http://jira.codehaus.org/browse/MAVENUPLOAD-662 MAVENUPLOAD-661add sources to commons-net http://jira.codehaus.org/browse/MAVENUPLOAD-661 MAVENUPLOAD-659Upload AjaxTags library http://jira.codehaus.org/browse/MAVENUPLOAD-659 MAVENUPLOAD-660ProGuard http://jira.codehaus.org/browse/MAVENUPLOAD-660 MAVENUPLOAD-654please upload retrotranslator jars for 0.9.5 http://jira.codehaus.org/browse/MAVENUPLOAD-654 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (14 issues) Subscriber: mavendevlist Key Summary MEV-278 Invalid POM for jcoverage 1.0.5 at iBiblio http://jira.codehaus.org/browse/MEV-278 MEV-277 More Spring Dependencies Should be Optional http://jira.codehaus.org/browse/MEV-277 MEV-255 Problem with junit-addons 1.4 http://jira.codehaus.org/browse/MEV-255 MEV-126 poms for som emissing sun xml API + javamail 1.3.3 http://jira.codehaus.org/browse/MEV-126 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-96 Some jars in ibiblio repository are broken http://jira.codehaus.org/browse/MEV-96 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-38 POM for commons-jelly-tags-ant has incorrect artifact & references bogus dependency http://jira.codehaus.org/browse/MEV-38 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Thu Jan 5 01:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060105.011501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060105.011501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commit logs (svn commit: r365696)
Brett Porter wrote: Jason van Zyl wrote: That's not a problem, and we can try to get everything useful in a single line for things like Mylar. I didn't know it needed a single line? That might make it harder to read, but we can look into it. It will take more, it's just the one line summary view makes it easier to see things. I got a short demo from Eugene and have only played with it for a few minutes myself. If you actually look at the way Mylar works it pulls everything in from JIRA using URLs. It's a shame they don't recognise numbers/ids and link them up through some configuration. It might be able to, but while I was watching Eugene a browser was coming up inside a view, that's how Mylar integrated with JIRA and Bugzilla. I'm sure it wouldn't take much to give it the base url. I'm not sure I see that as important provided you have navigation back to the issue. Whether that be typing in the key or using the URL. If we're going to populate contributors elements it would probably make more sense to take them from the source in JIRA and not from second hand information. You probably want the users full information for a contributor element and JIRA has more information. I don't consider JIRA the authoratative source here. You often don't use a patch, or use one and not the other, or something altogether different. Ok, I figured a contributor was someone who contributed a patch. But whatever they contributed should be in the issue tracking system, stored in a way we can link back to it. JIRA doesn't really work very well for this but a custom field in conjunction with the patch submission plugin could probably get the correct information. It's captured upfront in JIRA and we should put the information there to use in something like the scm message as opposed to multiple places. Sure, we might use JIRA to get more details (which is really only the email address), but I think we need to be recording the authors in SVN. Sure, the author being the contributor of the patch. That should be captured in JIRA to be resused elsewhere. Most of the time it is the reporter but a custom field(s) would be better where you could definitively get the author of the patch. MNG-2010 implemented the maven mind reader to pre-write all user documentation requests The url can be optional. I use it all the time and I know it would be useful in Mylar. This is fine with me (I wouldn't necessarily use the JIRA summary which is often crap, but would want to type my own comment). Fair enough. It should be good enough but often times is not. I still think the submitter of patches is important and could be a second line. I might ping legal-discuss to check if we actually have a requirement to capture this in SVN. I think it needs to be captured, but I think the issue management system is the place for it. Whether you pull it automatically or cut and paste it into the message. Thanks :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - checkout] Thu Jan 5 00:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060105.003000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MASSEMBLY-51) assembly:attached fails
assembly:attached fails --- Key: MASSEMBLY-51 URL: http://jira.codehaus.org/browse/MASSEMBLY-51 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Environment: xp, jdk 1.5, maven-2.0|2.0.1|2.0.2-SNAPHOT Reporter: Dan Tran Priority: Blocker Fix For: 2.1 I bind assembly:attached to package phase. mvn install return this [INFO] Scanning for projects... [INFO] - --- [INFO] Building Optimizeit Assembly [INFO]task-segment: [install] [INFO] - --- [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] One or more required plugin parameters are invalid/missing for 'assembly: attached' [0] on the command line, specify: '-DexecutedProject=VALUE' run mvn assembly:attached shows the same thing. This is from latest assembly plugin source -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSITE-6) site:site goal is completely broken
[ http://jira.codehaus.org/browse/MSITE-6?page=comments#action_54958 ] Valerio Schiavoni commented on MSITE-6: --- marked as fixed, but still faced here. the stacktrace is the following: [DEBUG] Found 0 components to load on start [DEBUG] Building Maven user-level plugin registry from: '/home/schiavoni/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level settings from: '/home/schiavoni/workspace/jeffrey/conf/settings.xml' [DEBUG] Building Maven user-level settings from: '/home/schiavoni/.m2/settings.xml' [DEBUG] it.chitechnologies.jeffrey:jeffrey:pom:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1 (selected for test) [INFO] [INFO] Building Jeffrey Project [INFO]task-segment: [site:site] [INFO] [INFO] Searching repository for plugin with prefix: 'site'. [DEBUG] maven-site-plugin: resolved to version 2.0-beta-4 from repository central [DEBUG] Found 0 components to load on start [DEBUG] changelog-maven-plugin: resolved to version 2.0-beta-1 from repository central [DEBUG] Found 0 components to load on start [DEBUG] org.codehaus.mojo:changelog-maven-plugin:maven-plugin:2.0-beta-1 (selected for runtime) [DEBUG] netbeans:cvslib:jar:3.6 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (removed - nearer found: 2.0.7) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] ant:ant:jar:1.6.5 (selected for runtime) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (selected for runtime) [DEBUG] org.apache.maven.reporting:maven-reporting-impl:jar:2.0-beta-1 (selected for runtime) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (removed - nearer found: 1.1.4) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (removed - nearer found: 2.0.7) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (removed - nearer found: 1.0-alpha-4) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (selected for runtime) [DEBUG] regexp:regexp:jar:1.3 (selected for runtime) [DEBUG] taglist-maven-plugin: resolved to version 2.0-beta-1 from repository central [DEBUG] Found 0 components to load on start [DEBUG] org.codehaus.mojo:taglist-maven-plugin:maven-plugin:2.0-beta-1 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (removed - nearer found: 2.0.7) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (selected for runtime) [DEBUG] org.apache.maven.reporting:maven-reporting-impl:jar:2.0-beta-1 (selected for runtime) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (removed - nearer found: 1.1.4) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (selected for runtime) [DEBUG] oro:oro:jar:2.0.7 (removed - nearer found: 2.0.7) [DEBUG] oro:oro:jar:2.0.7 (selected for runtime) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (removed - nearer found: 1.0-alpha-4) [DEBUG] doxia:doxia-core:jar:1.0-alpha-4 (selected for runtime) [DEBUG] maven-project-info-reports-plugin: resolved to version 2.0-beta-3 from repository central [DEBUG] Found 0 components to load on start [DEBUG] org.apache.maven.plugins:maven-project-info-reports-plugin:maven-plugin:2.0-beta-3 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-provider-perforce:jar:1.0-alpha-2 (selected for runtime) [DEBUG] regexp:regexp:jar:1.3 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (selected for runtime) [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-provider-starteam:jar:1.0-alpha-2 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (removed - nearer found: 1.0-alpha-2) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (selected for runtime) [DEBUG] commons-validator:commons-validator:jar:1.1.4 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-provider-clearcase:jar:1.0-alpha-2 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (removed - nearer found: 1.0-alpha-2) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (removed - nearer found: 1.0-alpha-2) [DEBUG] org.apache.maven.scm:maven-scm-api:jar:1.0-alpha-2 (selected for runtime) [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) [DEBUG] org.apache.maven.scm:maven-scm-manager-plexus:jar:1.0-alpha-2 (selected for runtime) [DEBUG]
Re: [vote] Create a maven-sources-plugin for m1
+1 Vincent 2006/1/2, Arnaud HERITIER <[EMAIL PROTECTED]>: > Hi all, > > It seems useful for some users to have a maven-sources-plugin for m1. > http://jira.codehaus.org/browse/MAVEN-1736 > Are you agree if we add it in the m1 plugins ? > > [ ] +1 - It seems to be a good idea. > [ ] +0 - Don't know > [ ] -1 - No, I prefer . > > Arnaud > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-install-plugin 2.1
+1 Vincent 2006/1/4, Brett Porter <[EMAIL PROTECTED]>: > All issues in JIRA have been completed. Please test the published snapshot. > > [ ] +1 > [ ] +0 > [ ] -1 > > Release will proceed in 72 hours if vote carries. > > - 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 trunk - SUCCESS - checkout] Thu Jan 5 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060105.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060105.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m2 logging
Thoughts on logging:- I would like to see logging messages use relevant and meaningful identifiers that are correlatable to provide users with a means of knowing what is going on and what sequence of events has brought about the output. Currently huge amounts of work goes on 'behind the scenes' that results in lots of messages being produced long before there's any mention of what phase or plugin goal has caused the messages or where the user is in the flow of things. One of the biggest draw backs with using maven 2, beyond the lack of tutorials and indepth technical documentation, is its difficulty in problem identifcation and resolution - even to the hex headed, when something breaks/doesnt work (as expected) the only option is to spend a week (or 2) hacking away at the mighty collection of projects, code, apis and utils (i.e. custom everything) trying to get to grips with whats going on uner the scenes. In my humble opinion, a build system, with its critical posiitoning within the engineering process, has gotta be simple (or at least appear to be without obscuring pertinent details), accessible and above all easy to fix and administer and currently the lack of consistent, user oriented logging and tracing gets in the way of this. Regarding m2s adoption in large scale enterprise dev env projects: yes I need a build fwk that supports/promotes depedency mgmt, standardisation, reporting, network delivery, deployment control, agile SDM techniques and architeral governance but more importantly, i need one that is easy to support, train, administer, adapt, extend and fix. Better messages and message tracing and some proper technical docs will help this i think. Observations:- - Too much noise that is only really meaningful to experts - Unable to distinguish what action has caused a message, part of a wider issue with not being able to associate what is being said, by who, and why (users pov) - No ability to extend message generation/delivery with adapters etc. John Allen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-deploy-plugin 2.1
+1 Vincent 2006/1/4, Brett Porter <[EMAIL PROTECTED]>: > All scheduled issues in JIRA have been completed. Please test the > published snapshot. > > [ ] +1 > [ ] +0 > [ ] -1 > > Release will proceed in 72 hours if vote carries. > > NB: The only change is the inclusion of the deploy:deploy-file mojo. > Most of the issues filed actually must be addressed in wagon, which this > release is independent of. > > - 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] more m1 plugin releases
Lukas Theussl wrote: Hi all, The following m1 plugins all have zero issues open: [] faq [] multichanges [] clean [] genapp +1 and I would like to release them for inclusion in m1.1-beta-3. The future documentation is here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/faq/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/multichanges/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/clean/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/genapp/ The genapp plugin is the only one with major changes since the last release, I'd appreciate if someone could have a closer look at it. Here's my +1 and 72h to go. Thanks, Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org you are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] more m1 plugin releases
+1 Lukas Theussl wrote: > > Hi all, > > The following m1 plugins all have zero issues open: > > [] faq > [] multichanges > [] clean > [] genapp > > and I would like to release them for inclusion in m1.1-beta-3. The > future documentation is here: > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/faq/ > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/multichanges/ > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/clean/ > > http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/genapp/ > > > The genapp plugin is the only one with major changes since the last > release, I'd appreciate if someone could have a closer look at it. > > > Here's my +1 and 72h to go. > > Thanks, > Lukas > > - > 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] more m1 plugin releases
Hi all, The following m1 plugins all have zero issues open: [] faq [] multichanges [] clean [] genapp and I would like to release them for inclusion in m1.1-beta-3. The future documentation is here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/faq/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/multichanges/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/clean/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/genapp/ The genapp plugin is the only one with major changes since the last release, I'd appreciate if someone could have a closer look at it. Here's my +1 and 72h to go. Thanks, Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commit logs (svn commit: r365696)
Jason van Zyl wrote: > That's not a problem, and we can try to get everything useful in a > single line for things like Mylar. I didn't know it needed a single line? That might make it harder to read, but we can look into it. > If you actually look at the way Mylar works it pulls everything in from > JIRA using URLs. It's a shame they don't recognise numbers/ids and link them up through some configuration. > I'm not sure I see that as important provided you have navigation back > to the issue. Whether that be typing in the key or using the URL. If > we're going to populate contributors elements it would probably make > more sense to take them from the source in JIRA and not from second hand > information. You probably want the users full information for a > contributor element and JIRA has more information. I don't consider JIRA the authoratative source here. You often don't use a patch, or use one and not the other, or something altogether different. Sure, we might use JIRA to get more details (which is really only the email address), but I think we need to be recording the authors in SVN. > MNG-2010 implemented the maven mind reader to pre-write all user > documentation requests > > The url can be optional. I use it all the time and I know it would be > useful in Mylar. This is fine with me (I wouldn't necessarily use the JIRA summary which is often crap, but would want to type my own comment). I still think the submitter of patches is important and could be a second line. I might ping legal-discuss to check if we actually have a requirement to capture this in SVN. Thanks :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1867) deprecate system scope, analyse other use cases
[ http://jira.codehaus.org/browse/MNG-1867?page=comments#action_54953 ] Brett Porter commented on MNG-1867: --- Mike - we are currently resorting to custom resolvers for such cases. You basically use the repository, or you don't - it can't be mixed and matched. Is this acceptable if it is documented? > deprecate system scope, analyse other use cases > --- > > Key: MNG-1867 > URL: http://jira.codehaus.org/browse/MNG-1867 > Project: Maven 2 > Type: Task > Components: design, Artifacts and Repositories > Reporter: Brett Porter > Fix For: 2.1 > > > possibly can avoid all use cases for system scope through proper use of > alternate resolvers. Gather use cases (see MNG-1471) to ensure. -- 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]
Repository Manager Proxy features
I'm using Maven Proxy to cache not only ibiblio, but some of our internal repos as well (remote offices, etc). The problem is that MP will look at all sites for snapshots before returning the result. This means that queries for internal snapshots hit ibiblio. This is at best a slowdown, at worst causes the build to fail. I had to create 2 instances of MP to deal with this. One only looking at ibiblio, 1 looking internally. What would be nice is if you could define some list of groups and say "don't look here" Or better, define a repo to be internal and say these groups are internal. Will this even be a problem with the RM? Is the RM in some state that is alpha testable?
[jira] Closed: (MPGENAPP-21) generated structure does not conform to maven standards
[ http://jira.codehaus.org/browse/MPGENAPP-21?page=all ] Lukas Theussl closed MPGENAPP-21: - Resolution: Fixed > generated structure does not conform to maven standards > --- > > Key: MPGENAPP-21 > URL: http://jira.codehaus.org/browse/MPGENAPP-21 > Project: maven-genapp-plugin > Type: Bug > Versions: 2.2 > Environment: maven-1.0.2 > Reporter: Chris Wood > Fix For: 2.3 > > > The generated structure does not conform to maven standards as described on > the maven site at > http://maven.apache.org/reference/conventions.html#Directory_Structure -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=comments#action_54948 ] Brett Porter commented on MNG-1323: --- workaround is to include the dependency in the first antrun plugin instance encountered. one way to guarantee would be to include this in the root project. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0 > Reporter: Kenney Westerhof > Fix For: 2.0.3 > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- 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: (MPIR-17) Create XML documents containing report data.
Create XML documents containing report data. Key: MPIR-17 URL: http://jira.codehaus.org/browse/MPIR-17 Project: Maven 2.x Project Info Reports Plugin Type: Improvement Versions: 2.0-beta-3 Reporter: Chris Hagmann It would be a huge improvement if each report was written as as XML document before optionally rendering it. If you did that, then other plugins could use those XML reports, apply XSLT or whatever to generate their own version of a report. It would make the whole reporting thing much more flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1921) test scope in dependencyManagement does not appear to be transitive to dependent subProjects
[ http://jira.codehaus.org/browse/MNG-1921?page=comments#action_54946 ] Brett Porter commented on MNG-1921: --- I don't think this is a bug. Let me understand: child inherits parent, but peer does not? dependency management is not transitive, however the easymock in the child should already be transitive to the peer. But tests scope jars are not. There are other problems here: eg, no group ID. > test scope in dependencyManagement does not appear to be transitive to > dependent subProjects > > > Key: MNG-1921 > URL: http://jira.codehaus.org/browse/MNG-1921 > Project: Maven 2 > Type: Bug > Versions: 2.0.1 > Environment: jdk1.5.0_04, mvn 2.0.1 > Reporter: Brian Bonner > > > If we have a root pom.xml that includes dependencyManagement and specifies > the scope on a dependent component to be test, it's picked up in a > subproject, but it's does not appear to be transitive. > e.g. parent pom > > > easymock > ... > test > > > child pom > > easymock > > peer pom > > child > > > easymock > > The peer pom gets compilation exceptions indicating that it can't find the > package specified by the dependent jar easymock. The easymock jar is nowhere > in the classpath. > Judging by this: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > the test scope should be transitive. > Brian -- 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-1908) M1 snapshots on legacy repos can not be used with m2
[ http://jira.codehaus.org/browse/MNG-1908?page=comments#action_54945 ] Brett Porter commented on MNG-1908: --- look into the unique version = false problem which is probably the same too > M1 snapshots on legacy repos can not be used with m2 > > > Key: MNG-1908 > URL: http://jira.codehaus.org/browse/MNG-1908 > Project: Maven 2 > Type: Bug > Versions: 2.0.1 > Reporter: Guillaume Nodet > Priority: Critical > Fix For: 2.0.3 > > > It seems from the log info that m2 is trying to locate the artifact metadata > on the repository. > SInce this artifact has been generated from m1, there is no metadata. > So whatever repository settings are configured, m2 will never update snapsots. -- 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: [Testing] Listing issues relating to testing and best practices
I really like project/ |_ src |_ main |_ test |_ unit |_ java |_ resources |_ integration |_ java |_ resources |_ functional |_ java |_ resources perhaps we could make it backwards compatible and support the old way of doing it and this approach as the new recommended layoutmaybe at 2.1release the other questions on there largely seem to rest on whether or not the directory layout changes jesse On 1/4/06, Vincent Massol <[EMAIL PROTECTED]> wrote: > > Hi, > > I've started a document at > http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies > where I've listed the known issues/questions I had in mind WRT Maven 2 and > testing. > > If you're interested in testing could you please have a look and > add/comment > if you have other questions/thoughts. > > If you have any question/remark on what's there could you please bring it > on > the list so that we can discuss it. Once we come to a conclusion on the > list, we'll edit the page to reflect the outcome. > > Thanks > -Vincent > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Commented: (MNG-1915) Top level project have to have a packaging of "pom". What about plug-ins wanting to make a different top level packaging?
[ http://jira.codehaus.org/browse/MNG-1915?page=comments#action_54944 ]
Brett Porter commented on MNG-1915:
---
so, this is an aggregating artifact?
> Top level project have to have a packaging of "pom". What about plug-ins
> wanting to make a different top level packaging?
> -
>
> Key: MNG-1915
> URL: http://jira.codehaus.org/browse/MNG-1915
> Project: Maven 2
> Type: Bug
> Components: Reactor and workspace
> Versions: 2.0.1
> Reporter: Nils Fredrik Gjerull
>
>
> The issue number MNG-764 included a patch that made maven check if the pom
> containing {{}} elements had a packaging of pom. What if a plug-in
> want to create a different top level packaging?
--
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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_54943 ] Brett Porter commented on MSUREFIRE-23: --- You can use profiles to have the selected version based on the executing JDK, but that may not be what you desire. The selection mechanism sounds better (just have them pick JDK 1.4 or 1.5, defaulting to one or the other, you can still list the dependencies normally). > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: mike perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-664) jlmenu 1.0
jlmenu 1.0 -- Key: MAVENUPLOAD-664 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-664 Project: maven-upload-requests Type: Task Reporter: Ofir Reichenberg Attachments: jlmenu-1.0-bundle.jar http://jlmenu.sourceforge.net/jlmenu-1.0-bundle.jar JavaLayersMenu - tag library for web menus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Wed Jan 4 21:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20060104.210001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060104.210001.txt
[jira] Commented: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=comments#action_54941 ] ruel loehr commented on MNG-1323: - Are there any suggested work arounds for this issue?Hence, if I wish to use a custom ant task in a child module (which would require a dependency upon the antrun plugin), how would I accomplish it, or is it impossible at this time? > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0 > Reporter: Kenney Westerhof > Fix For: 2.0.3 > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- 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: commit logs (svn commit: r365696)
Brett Porter wrote: I still have a problem with this template. Sorry to keep bringing this up, but I'd really like consistency in this area. Eugene made a good point about why the summary should go first, and why we should be consistent: http://www.jroller.com/page/eu?entry=cvs_comment_templates_please_don That's not a problem, and we can try to get everything useful in a single line for things like Mylar. Personally, I find the URL useless, but I have no problem with it being an optional addition for those that are tooled up. If you actually look at the way Mylar works it pulls everything in from JIRA using URLs. Mylar can actually use the URL to pull up the issue in a view. I actually think it's pretty important for other tools especially for navigation to the source i.e. JIRA. Mylar doesn't know how to look at a POM to construct the URL with just the issue key. But both the Eclipse and IDEA plugins use the web interface to retrieve information so if you whipped up a change log a view could immediately be made for the issue. Mylar actually brings up a browser so you can make changes right there. I don't think we should include the reporter in here. They are not always the most relevant person to the issue (often, someone else did most of the analysis or work/patch). I think its essential we capture the person that submitted a patch fix fore record keeping. And I'd like to keep using Submitted by: for that so that one day we can pull those from the logs and update . I'm not sure I see that as important provided you have navigation back to the issue. Whether that be typing in the key or using the URL. If we're going to populate contributors elements it would probably make more sense to take them from the source in JIRA and not from second hand information. You probably want the users full information for a contributor element and JIRA has more information. If we want something easy to type how about the key and summary. Then we can navigate back to JIRA to harvest anything we want and it's a single line. Maybe something we can use with future tooling in mind: MNG-2010 implemented the maven mind reader to pre-write all user documentation requests The url can be optional. I use it all the time and I know it would be useful in Mylar. - Brett [EMAIL PROTECTED] wrote: PR: SUREFIRE-26 URL: http://jira.codehaus.org/browse/SUREFIRE-26 Summary: Child delegation flag not being honoured in forked tests Reporter: Hiram Chirino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: separate JIRA project for dev process and design
Jason van Zyl wrote: >> For design, I believe it should go with the project itself, targetted at >> the same release as it is aimed for. > > Not sure if all of them would align with a release, but more importantly > it's not easy to see the priorities in design vs scheduled work given > the way JIRA is. If you can get the popular issues in combination with a > filter, say for a design component, then that's cool otherwise it's not > easy to see what's up for debate. Sorry, I'm unsure of what the difference is. Can you provide an example of a design issue that is not also a feature? Or two things that should be separately prioritised? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: separate JIRA project for dev process and design
Brett Porter wrote: Initial thoughts are -1. To me, the Maven dev process is a function of the whole project and can easily be dealt with in MPA. The dev process will be applied to all the projects in the Maven TLP yes, but I'm specifically talking about a JIRA project for scheduled work like MNG and then another JIRA project for design, say MNGD. I don't think there'll be a lot of "issues" to raise there, especially nothing requiring scheduling. The issues in something like MNG would be used to schedule work for releases in m2. The issues in MNGD would be where we keep track of design for m2. For design, I believe it should go with the project itself, targetted at the same release as it is aimed for. Not sure if all of them would align with a release, but more importantly it's not easy to see the priorities in design vs scheduled work given the way JIRA is. If you can get the popular issues in combination with a filter, say for a design component, then that's cool otherwise it's not easy to see what's up for debate. - Brett Jason van Zyl wrote: Hi, I was just looking over our discussion and without a separate project for the dev process and design JIRA doesn't make it very easy to look at the popular issues. So it would definitely be easier for reporting to have a separate project but it might also be good to separate design/process todos vs scheduled work todos. Any thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-18) Problem with SCP deploy
[ http://jira.codehaus.org/browse/MDEPLOY-18?page=comments#action_54940 ] Brett Porter commented on MDEPLOY-18: - I've never seen anything like that. Do you have a second distributionManagement section by accident? Is it possible to attach your full POM? > Problem with SCP deploy > --- > > Key: MDEPLOY-18 > URL: http://jira.codehaus.org/browse/MDEPLOY-18 > Project: Maven 2.x Deploy Plugin > Type: Bug > Reporter: Morten Kristiansen > Assignee: Brett Porter > > > I'm currently using scp to deploy a artifact to a remote repository: > [EMAIL PROTECTED]:~/workspace/HEAD/tt-main$ mvn deploy > [INFO] Scanning for projects... > [INFO] > > [INFO] Building tt-main > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [install:install] > [INFO] Installing /home/morten/workspace/HEAD/tt-main/pom.xml to > /home/morten/.m2/repository/tracetracker/tt-main/1.0.0/tt-main-1.0.0.pom > [INFO] [deploy:deploy] > Uploading: > scp://marple.pd.tracetracker.com/tracetracker/tt-main/1.0.0/tt-main-1.0.0.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error performing commands for file transfer > mkdir: cannot create directory `/tracetracker': Permission denied > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Tue Jan 03 19:56:27 CET 2006 > [INFO] Final Memory: 2M/5M > [INFO] > > [EMAIL PROTECTED]:~/workspace/HEAD/tt-main$ > I have no problems executing a scp from a shell. No problems creating folders > on the server. -- 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]
[Testing] Listing issues relating to testing and best practices
Hi, I've started a document at http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies where I've listed the known issues/questions I had in mind WRT Maven 2 and testing. If you're interested in testing could you please have a look and add/comment if you have other questions/thoughts. If you have any question/remark on what's there could you please bring it on the list so that we can discuss it. Once we come to a conclusion on the list, we'll edit the page to reflect the outcome. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Wed Jan 4 20:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20060104.203000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060104.203000.txt
Re: Created: (MNG-1921) test scope in dependencyManagement does not appear to be transitive to dependent subProjects
reminder to moderators not to moderate through anything from this address. I tried emailing it, but didn't get a response. Who knows what they've done. - Brett [EMAIL PROTECTED] wrote: > test scope in dependencyManagement does not appear to be transitive to > dependent subProjects > > > Key: MNG-1921 > URL: http://jira.codehaus.org/browse/MNG-1921 > Project: Maven 2 > Type: Bug > > Versions: 2.0.1 > Environment: jdk1.5.0_04, mvn 2.0.1 > Reporter: Brian Bonner > > > If we have a root pom.xml that includes dependencyManagement and specifies > the scope on a dependent component to be test, it\'s picked up in a > subproject, but it\'s does not appear to be transitive. > > > e.g. parent pom > > > > easymock > ... > test > > > > > child pom > > > easymock > > > > peer pom > > > child > > > easymock > > > The peer pom gets compilation exceptions indicating that it can\'t find the > package specified by the dependent jar easymock. The easymock jar is nowhere > in the classpath. > > Judging by this: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > the test scope should be transitive. > > Brian > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1922) Rename maven-it-plugin plugin as its name implies it is for performing integration tests in general
[ http://jira.codehaus.org/browse/MNG-1922?page=all ] Vincent Massol updated MNG-1922: Summary: Rename maven-it-plugin plugin as its name implies it is for performing integration tests in general (was: Renamed maven-it-plugin plugin as its name implies it is for performing integration tests in general) > Rename maven-it-plugin plugin as its name implies it is for performing > integration tests in general > --- > > Key: MNG-1922 > URL: http://jira.codehaus.org/browse/MNG-1922 > Project: Maven 2 > Type: Task > Components: integration tests > Versions: 2.0.1 > Reporter: Vincent Massol > > > The it plugin is really meant to perform functional tests of plugins and as > such should be renamed. > Ideas: > * maven-plugin-it-plugin > * maven-test-plugin-plugin > *Another idea is to include its feature in the plugin plugin under a > plugin:test mojo.* -- 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-1922) Renamed maven-it-plugin plugin as its name implies it is for performing integration tests in general
Renamed maven-it-plugin plugin as its name implies it is for performing integration tests in general Key: MNG-1922 URL: http://jira.codehaus.org/browse/MNG-1922 Project: Maven 2 Type: Task Components: integration tests Versions: 2.0.1 Reporter: Vincent Massol The it plugin is really meant to perform functional tests of plugins and as such should be renamed. Ideas: * maven-plugin-it-plugin * maven-test-plugin-plugin *Another idea is to include its feature in the plugin plugin under a plugin:test mojo.* -- 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: Created: (MNG-1921) test scope in dependencyManagement does not appear to be transitive to dependent subProjects
test scope in dependencyManagement does not appear to be transitive to dependent subProjects Key: MNG-1921 URL: http://jira.codehaus.org/browse/MNG-1921 Project: Maven 2 Type: Bug Versions: 2.0.1 Environment: jdk1.5.0_04, mvn 2.0.1 Reporter: Brian Bonner If we have a root pom.xml that includes dependencyManagement and specifies the scope on a dependent component to be test, it\'s picked up in a subproject, but it\'s does not appear to be transitive. e.g. parent pom easymock ... test child pom easymock peer pom child easymock The peer pom gets compilation exceptions indicating that it can\'t find the package specified by the dependent jar easymock. The easymock jar is nowhere in the classpath. Judging by this: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html the test scope should be transitive. Brian -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code style: Variable names
Check the project lead: http://jira.codehaus.org/browse/MASSEMBLY It should be you, Brett, right? :) Cheers, Stéphane On 1/4/06, Brett Porter <[EMAIL PROTECTED]> wrote: > There isn't anything documented on the naming of variables, but would > suggest following the surrounding code. I was referring to things like > "pAssembly", where we usually stick to just "assembly". > > Thanks, > Brett > > Jochen Wiedmann wrote: > > > > Brett, > > > > I was aware of a certain code style, when it comes to indentation, and > > the like. I did my best to follow that code style. However, I am > > completely lost, when it comes to a code style in terms of variable > > names. Any additional hints on that? > > > > Regards, > > > > Jochen > > > > > > > > > > Subject: > > [jira] Commented: (MASSEMBLY-25) Support for multiple assembly descriptors > > From: > > "Brett Porter (JIRA)" <[EMAIL PROTECTED]> > > Date: > > Tue, 3 Jan 2006 18:21:13 -0600 (CST) > > To: > > [EMAIL PROTECTED] > > > > To: > > [EMAIL PROTECTED] > > > > > > [ > > http://jira.codehaus.org/browse/MASSEMBLY-25?page=comments#action_54825 ] > > > > Brett Porter commented on MASSEMBLY-25: > > --- > > > > comment on the patch: please follow existing code style. I have to > > reformat, which is easy, but renaming all the variables is a bit tedious. > > > >> Support for multiple assembly descriptors > >> - > >> > >> Key: MASSEMBLY-25 > >> URL: http://jira.codehaus.org/browse/MASSEMBLY-25 > >> Project: Maven 2.x Assembly Plugin > >> Type: Bug > > > >> Reporter: Jochen Wiedmann > >> Assignee: Brett Porter > >> Fix For: 2.1 > >> Attachments: assembly.patch, assembly2.patch > >> > >> > >> The attached patch adds two new features: > >> - It allows to specify the "includeSiteDirectory" property in the assembly > >> descriptor. > >> IMO, this is the place, where it should be, because this typically > >> depends on the > >> descriptor. For example, you would want the site in a "bin" > >> distribution, but not in > >> the "src" distribution. > >> - It allows to specify multiple descriptors via the properties "dir", > >> "includes", and > >> "excludes". Typically, one would use dir=src/main/assembly, and > >> includes=*.xml. > >> I'd personally prefer to support even multiple "dir/includes/excludes" > >> triplets, but I > >> do not know, how this is done in a Mojo. > > > > > > > > > > - > > 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] > > -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: separate JIRA project for dev process and design
Initial thoughts are -1. To me, the Maven dev process is a function of the whole project and can easily be dealt with in MPA. I don't think there'll be a lot of "issues" to raise there, especially nothing requiring scheduling. For design, I believe it should go with the project itself, targetted at the same release as it is aimed for. - Brett Jason van Zyl wrote: > Hi, > > I was just looking over our discussion and without a separate project > for the dev process and design JIRA doesn't make it very easy to look at > the popular issues. So it would definitely be easier for reporting to > have a separate project but it might also be good to separate > design/process todos vs scheduled work todos. > > Any thoughts? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code style: Variable names
There isn't anything documented on the naming of variables, but would suggest following the surrounding code. I was referring to things like "pAssembly", where we usually stick to just "assembly". Thanks, Brett Jochen Wiedmann wrote: > > Brett, > > I was aware of a certain code style, when it comes to indentation, and > the like. I did my best to follow that code style. However, I am > completely lost, when it comes to a code style in terms of variable > names. Any additional hints on that? > > Regards, > > Jochen > > > > > Subject: > [jira] Commented: (MASSEMBLY-25) Support for multiple assembly descriptors > From: > "Brett Porter (JIRA)" <[EMAIL PROTECTED]> > Date: > Tue, 3 Jan 2006 18:21:13 -0600 (CST) > To: > [EMAIL PROTECTED] > > To: > [EMAIL PROTECTED] > > > [ http://jira.codehaus.org/browse/MASSEMBLY-25?page=comments#action_54825 > ] > > Brett Porter commented on MASSEMBLY-25: > --- > > comment on the patch: please follow existing code style. I have to reformat, > which is easy, but renaming all the variables is a bit tedious. > >> Support for multiple assembly descriptors >> - >> >> Key: MASSEMBLY-25 >> URL: http://jira.codehaus.org/browse/MASSEMBLY-25 >> Project: Maven 2.x Assembly Plugin >> Type: Bug > >> Reporter: Jochen Wiedmann >> Assignee: Brett Porter >> Fix For: 2.1 >> Attachments: assembly.patch, assembly2.patch >> >> >> The attached patch adds two new features: >> - It allows to specify the "includeSiteDirectory" property in the assembly >> descriptor. >> IMO, this is the place, where it should be, because this typically depends >> on the >> descriptor. For example, you would want the site in a "bin" distribution, >> but not in >> the "src" distribution. >> - It allows to specify multiple descriptors via the properties "dir", >> "includes", and >> "excludes". Typically, one would use dir=src/main/assembly, and >> includes=*.xml. >> I'd personally prefer to support even multiple "dir/includes/excludes" >> triplets, but I >> do not know, how this is done in a Mojo. > > > > > - > 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: Questions on MASSEMBLY-25
Thanks! I was planning to do it as part of another issue, but appreciate the help. I believe that -DdescriptorRefs=... should work, but will check it out. - Brett Jochen Wiedmann wrote: > > Hi, > > I am quite glad about the changes in MASSEMBLY-25. However, the docs > haven't been updated. Consequently, the docs are now reflecting > deprecated features. > > I am ready to submit a patch for the docs. However, before I work these > out, I have a couple of questions: > > - What is the policy for adding such patches: Reopen MASSEMBLY-25 > or create a new bug? > - The old docs have typically been made for the command line. > Example: > > m2 assembly:assembly -DdescriptorId=bin > > The example writes a value into the goals property > > protected String descriptorId; > > My personal impression is, that > > m2 assembly:assembly -DdescriptorRefs=bin > > wouldn't do, because > > private String[] descriptorRefs; > > cannot be written to so easily. Is it still possible to > achieve the task from above on the command line without > using a deprecated field? > > Regards, > > Jochen > > > > - > 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-1867) deprecate system scope, analyse other use cases
[ http://jira.codehaus.org/browse/MNG-1867?page=comments#action_54937 ]
Mike Whittemore commented on MNG-1867:
--
I would like to be able to specify a system path for any dependency regardless
of the scope. For example, I would like to mark junit-3.8.1 as being in the
"test" scope, yet point at a jar that is not in the repository. Something like
this:
junit
junit
3.8.1
test
${cots.top}/junit/junit.jar
I don't want to mark it as "system" scope, simply to say it is not in the
repository because that would lose the fact that it is really something scoped
for the unit test phase.
I understand the preferred way to use maven is to install 3rd-party artifacts
in the repository (and the public ibiblio repository if possible), but the
security culture in my company will not allow it (there is a rigid procedure
for how 3rd-party jars and tools get downloaded, installed, and used - not
uncommon in our particular industry). Without this feature I will be forced to
mark all 3rd-party jars as "system" scoped, which I want to avoid. Regardless
of my special circumstances, this feature would add a little more flexibility
to maven for handling special cases.
So to summarize, I would like to be able to tag certain dependencies with a
system path, but still tag them with an appropriate build scope such
as"runtime", "test" or "provided". If tagged with a path, the dependency would
not go to the repository to resolve the jar, but instead would follow the
system path. Additionally, the path should be allowed to contain variables so I
can make the build portable across operating systems (for example, by using a
varaible to indicate the root directory of COTS software installations).
I would be happy to help out with the implementation, though I would need a few
pointers of where to focus my attention.
> deprecate system scope, analyse other use cases
> ---
>
> Key: MNG-1867
> URL: http://jira.codehaus.org/browse/MNG-1867
> Project: Maven 2
> Type: Task
> Components: design, Artifacts and Repositories
> Reporter: Brett Porter
> Fix For: 2.1
>
>
> possibly can avoid all use cases for system scope through proper use of
> alternate resolvers. Gather use cases (see MNG-1471) to ensure.
--
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-1921) test scope in dependencyManagement does not appear to be transitive to dependent subProjects
[ http://jira.codehaus.org/browse/MNG-1921?page=comments#action_54936 ] Brian Bonner commented on MNG-1921: --- I made an error. The peer pom only looks like this: child and has no reference to easymock, however it should pick it up transitively, or so I believe. > test scope in dependencyManagement does not appear to be transitive to > dependent subProjects > > > Key: MNG-1921 > URL: http://jira.codehaus.org/browse/MNG-1921 > Project: Maven 2 > Type: Bug > Versions: 2.0.1 > Environment: jdk1.5.0_04, mvn 2.0.1 > Reporter: Brian Bonner > > > If we have a root pom.xml that includes dependencyManagement and specifies > the scope on a dependent component to be test, it's picked up in a > subproject, but it's does not appear to be transitive. > e.g. parent pom > > > easymock > ... > test > > > child pom > > easymock > > peer pom > > child > > > easymock > > The peer pom gets compilation exceptions indicating that it can't find the > package specified by the dependent jar easymock. The easymock jar is nowhere > in the classpath. > Judging by this: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > the test scope should be transitive. > Brian -- 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]
separate JIRA project for dev process and design
Hi, I was just looking over our discussion and without a separate project for the dev process and design JIRA doesn't make it very easy to look at the popular issues. So it would definitely be easier for reporting to have a separate project but it might also be good to separate design/process todos vs scheduled work todos. Any thoughts? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1921) test scope in dependencyManagement does not appear to be transitive to dependent subProjects
test scope in dependencyManagement does not appear to be transitive to dependent subProjects Key: MNG-1921 URL: http://jira.codehaus.org/browse/MNG-1921 Project: Maven 2 Type: Bug Versions: 2.0.1 Environment: jdk1.5.0_04, mvn 2.0.1 Reporter: Brian Bonner If we have a root pom.xml that includes dependencyManagement and specifies the scope on a dependent component to be test, it's picked up in a subproject, but it's does not appear to be transitive. e.g. parent pom easymock ... test child pom easymock peer pom child easymock The peer pom gets compilation exceptions indicating that it can't find the package specified by the dependent jar easymock. The easymock jar is nowhere in the classpath. Judging by this: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html the test scope should be transitive. Brian -- 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: (MCHECKSTYLE-29) Checkstyle violations should link to Xref if available
[ http://jira.codehaus.org/browse/MCHECKSTYLE-29?page=comments#action_54935 ] darren hartford commented on MCHECKSTYLE-29: +1 > Checkstyle violations should link to Xref if available > -- > > Key: MCHECKSTYLE-29 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-29 > Project: Maven 2.x Checkstyle Plugin > Type: New Feature > Reporter: Nick Giles > Priority: Minor > Attachments: MCHECKSTYLE-29.patch > > > The Checkstyle report should link to the location of the violation in the > Source Cross Reference if it is available. Attached is a patch that will > generate a link based on an additional parameter 'xrefLocation'. If this is > not present, or is null, no link will be created. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMD-9) Link violations to Xref
[ http://jira.codehaus.org/browse/MPMD-9?page=comments#action_54934 ] darren hartford commented on MPMD-9: +1 > Link violations to Xref > --- > > Key: MPMD-9 > URL: http://jira.codehaus.org/browse/MPMD-9 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Reporter: Nick Giles > Priority: Minor > Attachments: MPPMD-22.patch > > > The violations should link to their location in the source xref, as happened > in Maven 1. I'll attach a patch for this that does a simple but hopefully > sufficient job. It's based on the latest SCM code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MCHECKSTYLE-24) Jdk14logger exception
[ http://jira.codehaus.org/browse/MCHECKSTYLE-24?page=comments#action_54933 ] darren hartford commented on MCHECKSTYLE-24: Confirmed my problem went away with the 2.0-beta-2-20051230.164525-2 version of maven-checkstyle-plugin (tested exact same maven project that has not changed). I think the SNAPSHOT was still pointing to 200511** earlier and I didn't catch that until later so sorry for the delay. Thanks, I can run my checkstyle reports with M2, yay -D > Jdk14logger exception > - > > Key: MCHECKSTYLE-24 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-24 > Project: Maven 2.x Checkstyle Plugin > Type: Bug > Environment: Maven 2.0.1, checkstyle plugin 2.0-beta-1, JDK5, Win2000 > Reporter: darren hartford > Assignee: fabrizio giustina > Priority: Blocker > Fix For: 2.0-beta-2 > Attachments: checkstyletrace.txt > > > Problem with checkstyle plugin when used with 'site' - see attached trace. > 'mvn checkstyle:checkstyle' works fine. > Also reference http://jira.codehaus.org/browse/MCHECKSTYLE-10 as may be > similar issue/fix. -- 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: dev process doco
I added mine as a warning in the appropriate section...remove if you aren't concerned about it :) jesse On 1/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Hi, > > I see one comment in the dev process doco and I'm about to incorporate > yesterday's discussion so if you want to add any notes or comments into > the doco feel free. Also, it might be good to put your name with your > comments so I can track you down if I have any questions. > > -- > > jvz. > > Jason van Zyl > jason at maven.org > http://maven.apache.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > >-- Jacques Ellul, The Technological Society > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
dev process doco
Hi, I see one comment in the dev process doco and I'm about to incorporate yesterday's discussion so if you want to add any notes or comments into the doco feel free. Also, it might be good to put your name with your comments so I can track you down if I have any questions. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MSUREFIRE-37) Remove or fix strange "battery = null" messages displayed on the console
Do you do IBM WCS ?? Best Regards Global Identity A/S, Jens Fournais CEO Bygstubben 3 | DK-2950 Vedbaek | Denmark Phone: +45 45 99 31 00 | E-mail: [EMAIL PROTECTED] Please visit our website at: http://www.elibitum.com
[jira] Commented: (ARCHETYPE-21) Unecessary java directory creation
[ http://jira.codehaus.org/browse/ARCHETYPE-21?page=comments#action_54925 ] Eric Redmond commented on ARCHETYPE-21: --- It's possible I am using old code. Let me check. I'll cancel this issue if that is the case. > Unecessary java directory creation > -- > > Key: ARCHETYPE-21 > URL: http://jira.codehaus.org/browse/ARCHETYPE-21 > Project: Maven Archetype > Type: Improvement > Components: maven-archetype-plugin > Reporter: Eric Redmond > Assignee: Jason van Zyl > Priority: Trivial > > > Whether specified in the archetype.xml or not, the plugin will generate the > path /src/main/java if tags are used. It would be nice if it only > honored the specified source dirs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (ARCHETYPE-22) Always generates groupId directories
[ http://jira.codehaus.org/browse/ARCHETYPE-22?page=comments#action_54924 ]
Eric Redmond commented on ARCHETYPE-22:
---
Whichever. What I was getting at is that a groupId directory structure is
inserted by default. have ${package} would make more sense within the
archetype.xml file, but it would also make someone type:
mvn archetype:create -DartifactId=aid -DgroupId=group.i.d -Dpackage=group/i/d
Since it effectively uses groupId to create a default package path anyway, I
just figure groupId would be fine.
> Always generates groupId directories
>
>
> Key: ARCHETYPE-22
> URL: http://jira.codehaus.org/browse/ARCHETYPE-22
> Project: Maven Archetype
> Type: Wish
> Reporter: Eric Redmond
> Assignee: Jason van Zyl
>
>
> I'd like to see the source directories explicity define groupId based
> directory structure. For example:
> /src/main/java/App.java
> would generate /src/main/java/App.java,
> But something similar to /src/main/java/${groupId}/App.java
> would generate the directory structure as it is generated today.
--
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: (MNGECLIPSE-23) Console for running processes in the background
[ http://jira.codehaus.org/browse/MNGECLIPSE-23?page=comments#action_54923 ] Eugene Kuleshov commented on MNGECLIPSE-23: --- Console should show the output of the maven-embedder used to fetch pom dependencies as well as any other internal tasks, not including maven launchers that will have their own consoles. > Console for running processes in the background > --- > > Key: MNGECLIPSE-23 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-23 > Project: Maven 2.x Plug-in for Eclipse > Type: New Feature > Reporter: Dmitri Maximovich > Assignee: Dmitri Maximovich > > > Add support for standard Eclipse console feature (IConsole) to output debug > info from m2 -- 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]
planetmirror broken, m2 not picking it up
With planetmirror set up as the repository, and using the 2.0.0 version of the m2 ant tasks, trying to get back the 2.6.0 file http://public.planetmirror.com/pub/maven/xerces/xercesImpl/2.6.0/xercesImpl-2.6.0.pom This is not valid, because it should be pub/maven2. I think things have been changing there. But here is the problem: planetmirror doesnt return 404, it returns http success (seemingly), and an HTTP search page. So m2 saves the pom, complains about the lack of a checksum and from then on complains about the POM being invalid until I go in and delete it by hand. 1. invalid pom files ought to trigger a fallback to the next site. 2. files that look like html pages (or anything other than a well-intentioned) attempt at a pom ought to be rejected and not saved to the local repository. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MECLIPSE-51) Issue Tracking on website points to generic MNG instead of MECLIPSE
[ http://jira.codehaus.org/browse/MECLIPSE-51?page=all ] David Rice updated MECLIPSE-51: --- Attachment: MECLIPSE-51-maven-eclipse-plugin.patch > Issue Tracking on website points to generic MNG instead of MECLIPSE > --- > > Key: MECLIPSE-51 > URL: http://jira.codehaus.org/browse/MECLIPSE-51 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0 > Reporter: David Rice > Attachments: MECLIPSE-51-maven-eclipse-plugin.patch > > > The page > http://maven.apache.org/plugins/maven-eclipse-plugin/issue-tracking.html > points to the generic Maven 2 jira issues at > http://jira.codehaus.org/browse/MNG. This should point to > http://jira.codehaus.org/browse/MECLIPSE instead. > The attached patch adds a specific section to the > maven-eclipse-plugin pom. -- 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: (MECLIPSE-51) Issue Tracking on website points to generic MNG instead of MECLIPSE
Issue Tracking on website points to generic MNG instead of MECLIPSE --- Key: MECLIPSE-51 URL: http://jira.codehaus.org/browse/MECLIPSE-51 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: David Rice The page http://maven.apache.org/plugins/maven-eclipse-plugin/issue-tracking.html points to the generic Maven 2 jira issues at http://jira.codehaus.org/browse/MNG. This should point to http://jira.codehaus.org/browse/MECLIPSE instead. The attached patch adds a specific section to the maven-eclipse-plugin pom. -- 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: (MCOMPILER-24) SimpleSourceIncludeScanner is created with incorrect include set.
SimpleSourceIncludeScanner is created with incorrect include set. - Key: MCOMPILER-24 URL: http://jira.codehaus.org/browse/MCOMPILER-24 Project: Maven 2.x Compiler Plugin Type: Bug Reporter: Brent Worden Attachments: compiler-mojo.diff In CompilerMojo, the getSourceInclusionScanner(String) method creates a SimpleSourceIncludeScanner using the excludes set for both the include and exclude parameters; ignoring the includes set altogether. Attached is a patch that corrects the parameters. -- 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 Jan 4 16:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060104.163000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060104.163000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 4 16:15:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060104.161501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060104.161501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1920) Allow custom project name for eclipse projects
[ http://jira.codehaus.org/browse/MNG-1920?page=all ]
David Rice updated MNG-1920:
Attachment: MNG-1920-maven-eclipse-plugin.patch
> Allow custom project name for eclipse projects
> --
>
> Key: MNG-1920
> URL: http://jira.codehaus.org/browse/MNG-1920
> Project: Maven 2
> Type: New Feature
> Versions: 2.0.1
> Reporter: David Rice
> Attachments: MNG-1920-maven-eclipse-plugin.patch
>
>
> If you download 2 versions of the same artifact, or 2 artifacts with the same
> artifactId then when you create eclipse the projects you have to load them
> into different workspaces because the eclipse project name is the same (ie.
> based on artifactId). I added a parameter eclipse.projectName to allow you
> to specify an alternate name to artifactId to get around this problem.
> Example uses:
> -Declipse.projectName='${project.artifactId}:${project.version}'
> -Declipse.projectName='${project.groupId}:${project.artifactId}:${project.version}'
> -Declipse.projectName=my-different-project-name
--
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-1920) Allow custom project name for eclipse projects
Allow custom project name for eclipse projects
--
Key: MNG-1920
URL: http://jira.codehaus.org/browse/MNG-1920
Project: Maven 2
Type: New Feature
Versions: 2.0.1
Reporter: David Rice
If you download 2 versions of the same artifact, or 2 artifacts with the same
artifactId then when you create eclipse the projects you have to load them into
different workspaces because the eclipse project name is the same (ie. based on
artifactId). I added a parameter eclipse.projectName to allow you to specify
an alternate name to artifactId to get around this problem.
Example uses:
-Declipse.projectName='${project.artifactId}:${project.version}'
-Declipse.projectName='${project.groupId}:${project.artifactId}:${project.version}'
-Declipse.projectName=my-different-project-name
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Wed Jan 4 16:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20060104.160001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060104.160001.txt
[jira] Created: (MNG-1919) If deploy with uniqueVersion=false (only generate file ended SNAPSHOT), this is not downloaded
If deploy with uniqueVersion=false (only generate file ended SNAPSHOT), this is not downloaded -- Key: MNG-1919 URL: http://jira.codehaus.org/browse/MNG-1919 Project: Maven 2 Type: Bug Versions: 2.0.1 Environment: all Reporter: Olivier Lamy If I specify false in the pom. The generated file is only one ended with -SNAPSHOT (no problem is cool). But it's not downloaded by a client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_54913 ] Jesse Kuhnert commented on MSUREFIRE-23: Yay! This is turning out to be a lot easier than I thought. Question: Does anything in the maven dependency runtime have the ability for me to optionally include one or another artifact depending on the jvm version running? I've basically got an issue where I have to either include the jdk14 or jdk15 version of testng depending on the runtime. One solution that I came up with is bundling the core set of classes/interfaces for testng into a sort of testng-core artifact, and then force the user to specify which testng implementation they want to use. The surefire runtime would also report errors if more than one testng artifact impl was specified. I'm going to pass this along to cedric as well. > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: mike perham > > > Add support for running unit tests with TestNG. > http://www.testng.org -- 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]
[m2] surefire and commons-logging problem
Hello, I have a problem with running surefire tests when I have commons-logging in my classpath. I get java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory. I am subscriber of this list and I think I saw a solution here (adding something to the commons-logging...???) but I can't find it now. Could you, please, refresh my memory what it is? Best regards, Piotrek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-663) please upload jtds (bundle provided)
please upload jtds (bundle provided) Key: MAVENUPLOAD-663 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-663 Project: maven-upload-requests Type: Task Reporter: Miguel Griffa Attachments: jtds-1.2-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-install-plugin 2.1
Brett Porter wrote: All issues in JIRA have been completed. Please test the published snapshot. [ ] +1 [ ] +0 [ ] -1 +1 Release will proceed in 72 hours if vote carries. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-deploy-plugin 2.1
Brett Porter wrote: All scheduled issues in JIRA have been completed. Please test the published snapshot. [ ] +1 [ ] +0 [ ] -1 +1 Release will proceed in 72 hours if vote carries. NB: The only change is the inclusion of the deploy:deploy-file mojo. Most of the issues filed actually must be addressed in wagon, which this release is independent of. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-116) scm:update doesn't iterate through multi-projects
[ http://jira.codehaus.org/browse/SCM-116?page=comments#action_54899 ] David Boden commented on SCM-116: - >I think it is assumed that when you update the root of a multi-project, the >SCM updates everything underneath that directory, including all subprojects. What if you have 100 modules in your CVS but your tag only specifies 2 of them. Is it really a good idea to allow source control to update all 100 modules? No, the plugin should iterate intelligently through the 2 specified modules. > scm:update doesn't iterate through multi-projects > - > > Key: SCM-116 > URL: http://jira.codehaus.org/browse/SCM-116 > Project: Maven SCM > Type: Bug > Versions: 1.0-beta-2 > Reporter: David Boden > > > scm:update doesn't iterate through projects > > C:\dev\CDSSS>mvn scm:update > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] SalesStation ss_base_shared > [INFO] SalesStation cds_ss_shared > [INFO] SalesStation ss_offering_shared > [INFO] SalesStation ss_base_applet > [INFO] SalesStation sales_station_lib > [INFO] SalesStation ss_offering_lib > [INFO] SalesStation sales_station_applet > [INFO] SalesStation cds_ss_applet > [INFO] SalesStation cds_ss_lib > [INFO] SalesStation SS webapp > [INFO] SalesStation FET_S webapp (contains images) > [INFO] SalesStation CDSSS webapp > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building SalesStation CDSSS webapp > [INFO]task-segment: [scm:update] (aggregator-style) > [INFO] > > [INFO] [scm:update] > [INFO] Executing: cvs -f -q update -d > [INFO] Working directory: C:\dev\CDSSS > [WARNING] Unknown status: '? '. > [WARNING] Unknown status: 'M '. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 5 seconds > [INFO] Finished at: Thu Dec 15 10:38:24 GMT 2005 > [INFO] Final Memory: 3M/7M > [INFO] > > C:\dev\CDSSS> > > Any reason why it doesn't iterate? I'm using Maven 2.0.1 and SCM version > 1.0-beta-2. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHECKSTYLE-29) Checkstyle violations should link to Xref if available
[ http://jira.codehaus.org/browse/MCHECKSTYLE-29?page=all ] Nick Giles updated MCHECKSTYLE-29: -- Attachment: MCHECKSTYLE-29.patch > Checkstyle violations should link to Xref if available > -- > > Key: MCHECKSTYLE-29 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-29 > Project: Maven 2.x Checkstyle Plugin > Type: New Feature > Reporter: Nick Giles > Priority: Minor > Attachments: MCHECKSTYLE-29.patch > > > The Checkstyle report should link to the location of the violation in the > Source Cross Reference if it is available. Attached is a patch that will > generate a link based on an additional parameter 'xrefLocation'. If this is > not present, or is null, no link will be created. -- 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: (MCHECKSTYLE-29) Checkstyle violations should link to Xref if available
Checkstyle violations should link to Xref if available -- Key: MCHECKSTYLE-29 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-29 Project: Maven 2.x Checkstyle Plugin Type: New Feature Reporter: Nick Giles Priority: Minor The Checkstyle report should link to the location of the violation in the Source Cross Reference if it is available. Attached is a patch that will generate a link based on an additional parameter 'xrefLocation'. If this is not present, or is null, no link will be created. -- 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-1784) mvn install - multiple modules using subproject as launch point - pom.xml gets renamed installed in local repository as a .war file
[ http://jira.codehaus.org/browse/MNG-1784?page=all ] David Boden closed MNG-1784: Resolution: Fixed Fix Version: 2.0.1 Aggregator poms must now be of type pom. You get an error message if this is not the case. > mvn install - multiple modules using subproject as launch point - pom.xml > gets renamed installed in local repository as a .war file > --- > > Key: MNG-1784 > URL: http://jira.codehaus.org/browse/MNG-1784 > Project: Maven 2 > Type: Bug > Components: Reactor and workspace > Versions: 2.0 > Reporter: David Boden > Fix For: 2.0.1 > Attachments: demo.zip > > > Please unzip the attached demo.zip and navigate to the BigWAR directory. From > here, type: > mvn install > You'll get this logged: > [INFO] Installing C:\dev\demo\BigWAR\pom.xml to C:\Documents and > Settings\dboden\.m2\repository\com\demo\demo\BigWAR\SNAPSHOT\BigWAR-SNAPSHOT.war > The pom.xml gets renamed to a .war file and installed in the repository! > I admit that I've not quite used the pom.xml sub modules features as > intended. However, it would be better if we could use them in this way! Any > pom.xml should be able to specify that sub modules should be built > beforehand. Why should we have to use the parent as the starting point for a > sub modules build? > In any case, I'm sure you'll agree that installing a .xml file as a .war is > incorrect behaviour, in any case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Wed Jan 4 13:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20060104.133000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060104.133000.txt
Re: [discussion] Integration testing location
Vincent Massol wrote: -Original Message- From: Jesse McConnell [mailto:[EMAIL PROTECTED] Sent: mercredi 28 décembre 2005 20:44 To: Maven Developers List Subject: Re: [discussion] Integration testing location I worry a bit about mixing unit and integration tests generally... maybe we have the recommended case for them go into src/integration-test/java or something along those lines... logically the structure src/test/java and src/test/it doesn't do it for me since it tests are probably written in java anyway, so that kinda breaks the spirit of 'src'/'type'/'language' convention we kind of have going.. Right. I hadn't seen it this way (I thought src/test was for all tests and that src/main was for all runtime sources) but I think you're right. I'm fine with src/it/java. as for the rest of it, I like adding the phases... Sure but there's a very common use case for integration testing: the need to have environment setup before the test and to clean it after the tests. Of course you could write all sort of plugin to that the plugin support doing this itself but then you're no longer flexible and you're not providing a solution to lots of other use cases. For example cargo could define a cargo:test goal which would start the container, run the tests and stop the containers. But this doesn't lead to all variations like: - the user simply wants to redeploy the new artifacts in the container but not start the container again - the user want to have his/her tests written using tetstng and not junit (or any other test framework) Sounds more like functional testing to me...anything that needs a deployed system is a v. more complex situation. I am working with a PhD student at CERN on distributed testing, and there is a project gridunit that does some good stuff already, running junit tests across a farm of nodes, collecting and presenting the results. Clearly presenting the results gets more complex once you have tested on 20 boxes; you want to know what failed everywhere, what failed somewhere, and if there is any commonality for the partial failures. The perspective we are taking is that a test run is just another thing to deploy; you have a test listener to collect results and logs from across the machines, then test runners on different machines running different tests. The listener collects the results, post-processes them and then you can act on the outcome (report failures, host the reports, etc). In this view, functional testing of a deployment is just another deployment. Its different from a production deployment, but not very; just a different deployment descriptor to process. -Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] how do I submit a plugin to codehaus?
you can make an issue for each plugin you want to contribute here: http://jira.codehaus.org/browse/MOJO for plugin discussion the [EMAIL PROTECTED] is probably the more appropriate address cheers! jesse On 1/4/06, Jurgen De Landsheer <[EMAIL PROTECTED]> wrote: > > hello, > > I've developed some plugins (lint4j, linguine maps, spring beandocs) > that I want > to submit to the sandbox on codehaus. I've seen that I need to create an > issue, > but in wich project - "Maven 2" or some other - and issue type "new > feature" > or "improvement". And then what? Can I submit improvements, bugfixes > right away and can people that are interested do that too or can they only > download the code. > > PS I've searched for any lint4j plugin for Maven 2 but could only find > one for > Maven 1 without source code so I've made a simple one that more or less > does > the same as the one for Maven 1. > > this email was also send to the developers list of codehaus but I don't > know if that > one is read by a lot of people, if someone could tell me whats the > diffirence between > dev@maven.apache.org and dev@mojo.codehaus.org and wich one is the best > one > to pick... > > greetings > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[continuum build - FAILED - update] Wed Jan 4 13:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060104.13.txt
[jira] Closed: (MEV-275) Castor dependencies
[ http://jira.codehaus.org/browse/MEV-275?page=all ] Carlos Sanchez closed MEV-275: -- Resolution: Fixed AFAIK there's nothing to do with the jar artifact > Castor dependencies > --- > > Key: MEV-275 > URL: http://jira.codehaus.org/browse/MEV-275 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: David Blevins > Assignee: Carlos Sanchez > Attachments: castor-1.0M1.patch > > > Added some of the missing deps for castor to run -- 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]
[m2] how do I submit a plugin to codehaus?
hello, I've developed some plugins (lint4j, linguine maps, spring beandocs) that I want to submit to the sandbox on codehaus. I've seen that I need to create an issue, but in wich project - "Maven 2" or some other - and issue type "new feature" or "improvement". And then what? Can I submit improvements, bugfixes right away and can people that are interested do that too or can they only download the code. PS I've searched for any lint4j plugin for Maven 2 but could only find one for Maven 1 without source code so I've made a simple one that more or less does the same as the one for Maven 1. this email was also send to the developers list of codehaus but I don't know if that one is read by a lot of people, if someone could tell me whats the diffirence between dev@maven.apache.org and dev@mojo.codehaus.org and wich one is the best one to pick... greetings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-278) Invalid POM for jcoverage 1.0.5 at iBiblio
[ http://jira.codehaus.org/browse/MEV-278?page=comments#action_54890 ] Carlos Sanchez commented on MEV-278: attached pom is missing log4j and includes itself > Invalid POM for jcoverage 1.0.5 at iBiblio > -- > > Key: MEV-278 > URL: http://jira.codehaus.org/browse/MEV-278 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Chris Hagmann > Attachments: README, jcoverage-1.0.5.pom > > > Jcoverage has a set of dependencies (as taken from its README taken from > http://www.jcoverage.org/download/jcoverage-1.0.5-bin.zip): > THIRD PARTY DEPENDENCIES > jcoverage is dependant on the following third party libraries, which > are included in the jcoverage binary distribution. > bcel5.1 http://jakarta.apache.org/bcel/ > log4j 1.2.8 http://jakarta.apache.org/log4j/ > getopt 1.0.9 http://gnu.org/ > oro 2.0.7 http://jakarta.apache.org/oro/ > But the POM doesn't state any dependencies, so the transitive dependency > resolution mechanism doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-deploy-plugin 2.1
+1 On 1/4/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > +1 > > Arnaud > > > On 1/4/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > > > +1 > > > > Emmanuel > > > > Brett Porter a écrit : > > > All scheduled issues in JIRA have been completed. Please test the > > > published snapshot. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > Release will proceed in 72 hours if vote carries. > > > > > > NB: The only change is the inclusion of the deploy:deploy-file mojo. > > > Most of the issues filed actually must be addressed in wagon, which this > > > release is independent of. > > > > > > - 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] > > > > > > -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MDEPLOY-18) Problem with SCP deploy
[ http://jira.codehaus.org/browse/MDEPLOY-18?page=all ] Morten Kristiansen reopened MDEPLOY-18: --- But why is it trying to create tracetracker at /? And it's not using morten as user, but maven: >From pom.xml: marplerepo scp://marple.pd.tracetracker.com/repository/maven2 >From ~/.m2/settings.xml marplerepo maven /home/morten/.ssh/id_rsa I have also tried setting: 664 777 but that doesn't work etiher. > Problem with SCP deploy > --- > > Key: MDEPLOY-18 > URL: http://jira.codehaus.org/browse/MDEPLOY-18 > Project: Maven 2.x Deploy Plugin > Type: Bug > Reporter: Morten Kristiansen > Assignee: Brett Porter > > > I'm currently using scp to deploy a artifact to a remote repository: > [EMAIL PROTECTED]:~/workspace/HEAD/tt-main$ mvn deploy > [INFO] Scanning for projects... > [INFO] > > [INFO] Building tt-main > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [install:install] > [INFO] Installing /home/morten/workspace/HEAD/tt-main/pom.xml to > /home/morten/.m2/repository/tracetracker/tt-main/1.0.0/tt-main-1.0.0.pom > [INFO] [deploy:deploy] > Uploading: > scp://marple.pd.tracetracker.com/tracetracker/tt-main/1.0.0/tt-main-1.0.0.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error performing commands for file transfer > mkdir: cannot create directory `/tracetracker': Permission denied > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Tue Jan 03 19:56:27 CET 2006 > [INFO] Final Memory: 2M/5M > [INFO] > > [EMAIL PROTECTED]:~/workspace/HEAD/tt-main$ > I have no problems executing a scp from a shell. No problems creating folders > on the server. -- 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-1916) Making it possible for plug-in to add modules to the reactor programatically
[ http://jira.codehaus.org/browse/MNG-1916?page=comments#action_54888 ]
Nils Fredrik Gjerull commented on MNG-1916:
---
Wildcarded {{}} would certainly help. As commented in issue MNG-1915 I
am working on making a maven2 plug-in for JPF. This is the reason I would like
to specify a number of directories and have all subdirectories containing jpf
plug-ins included in the reactor.
I would like to have more fine grained control of which of this subdirectories
should be included. One example would be to only include directories containing
pom.xml, plugin.xml and plugin-fragment.xml files. This is however not
essential, so wildcarded {{}} would probably do the trick.
> Making it possible for plug-in to add modules to the reactor programatically
>
>
> Key: MNG-1916
> URL: http://jira.codehaus.org/browse/MNG-1916
> Project: Maven 2
> Type: Improvement
> Reporter: Nils Fredrik Gjerull
>
>
> I would like to be able to specify a number of directories as plug-in
> directories, automatically discover every plug-in in those directories and
> include them in the reactor. As I understands it the reactor with it's
> modules ({{org.apache.maven.execution.ReactorManager}}) is created in
> {{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
> plug-ins can't add projects to the reactor programatically.
> My proposition to solve this is to add a phase which will be executed after
> the pom.xml is parsed, but before the information stored in
> Model/MavenProject is used, and most importantly before the {{ReactorManager
> is created}}. Then you can add information to the MavenProject
> programatically, increasing the flexibility for plug-ins.
> I am not fluent in the maven2 code base, but it seems to me that this require
> quite a lot of changes to the code. As I understands it the life cycle starts
> after the {{ReactorManager}} is made, and therefore after the information in
> Model have started to be used.
--
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]
Questions on MASSEMBLY-25
Hi, I am quite glad about the changes in MASSEMBLY-25. However, the docs haven't been updated. Consequently, the docs are now reflecting deprecated features. I am ready to submit a patch for the docs. However, before I work these out, I have a couple of questions: - What is the policy for adding such patches: Reopen MASSEMBLY-25 or create a new bug? - The old docs have typically been made for the command line. Example: m2 assembly:assembly -DdescriptorId=bin The example writes a value into the goals property protected String descriptorId; My personal impression is, that m2 assembly:assembly -DdescriptorRefs=bin wouldn't do, because private String[] descriptorRefs; cannot be written to so easily. Is it still possible to achieve the task from above on the command line without using a deprecated field? Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code style: Variable names
Brett, I was aware of a certain code style, when it comes to indentation, and the like. I did my best to follow that code style. However, I am completely lost, when it comes to a code style in terms of variable names. Any additional hints on that? Regards, Jochen --- Begin Message --- [ http://jira.codehaus.org/browse/MASSEMBLY-25?page=comments#action_54825 ] Brett Porter commented on MASSEMBLY-25: --- comment on the patch: please follow existing code style. I have to reformat, which is easy, but renaming all the variables is a bit tedious. > Support for multiple assembly descriptors > - > > Key: MASSEMBLY-25 > URL: http://jira.codehaus.org/browse/MASSEMBLY-25 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Jochen Wiedmann > Assignee: Brett Porter > Fix For: 2.1 > Attachments: assembly.patch, assembly2.patch > > > The attached patch adds two new features: > - It allows to specify the "includeSiteDirectory" property in the assembly > descriptor. > IMO, this is the place, where it should be, because this typically depends > on the > descriptor. For example, you would want the site in a "bin" distribution, > but not in > the "src" distribution. > - It allows to specify multiple descriptors via the properties "dir", > "includes", and > "excludes". Typically, one would use dir=src/main/assembly, and > includes=*.xml. > I'd personally prefer to support even multiple "dir/includes/excludes" > triplets, but I > do not know, how this is done in a Mojo. -- 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 --- End Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1915) Top level project have to have a packaging of "pom". What about plug-ins wanting to make a different top level packaging?
[ http://jira.codehaus.org/browse/MNG-1915?page=comments#action_54880 ]
Nils Fredrik Gjerull commented on MNG-1915:
---
I am working on creating a maven2 plug-in for Java Plug-in Framework
([http://jpf.sourceforge.net/]). This framework is inspired by Eclipse. I would
like to be able to use maven2 to build applications using this framework. To do
this I would like to have a master project (quite like the "pom" packaging, but
with different implementations of the validate, install and deploy phases). The
modules in the master project would bee the boot module and all the plug-ins
needed for a functioning system.
> Top level project have to have a packaging of "pom". What about plug-ins
> wanting to make a different top level packaging?
> -
>
> Key: MNG-1915
> URL: http://jira.codehaus.org/browse/MNG-1915
> Project: Maven 2
> Type: Bug
> Components: Reactor and workspace
> Versions: 2.0.1
> Reporter: Nils Fredrik Gjerull
>
>
> The issue number MNG-764 included a patch that made maven check if the pom
> containing {{}} elements had a packaging of pom. What if a plug-in
> want to create a different top level packaging?
--
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: (CONTINUUM-532) Add ability to move from a particular build to the build list for a project.
[ http://jira.codehaus.org/browse/CONTINUUM-532?page=all ] Emmanuel Venisse closed CONTINUUM-532: -- Assign To: Emmanuel Venisse Resolution: Fixed Fixed. > Add ability to move from a particular build to the build list for a project. > > > Key: CONTINUUM-532 > URL: http://jira.codehaus.org/browse/CONTINUUM-532 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0.2 > Reporter: Trygve Laugstol > Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-531) Add back the "build now" button on the "view project" page.
[ http://jira.codehaus.org/browse/CONTINUUM-531?page=comments#action_54861 ] Emmanuel Venisse commented on CONTINUUM-531: It isn't in template page (http://people.apache.org/~brett/white-site/viewProject.html). Where do you want it? > Add back the "build now" button on the "view project" page. > --- > > Key: CONTINUUM-531 > URL: http://jira.codehaus.org/browse/CONTINUUM-531 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0.2 > Reporter: Trygve Laugstol > Fix For: 1.1-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] release maven-deploy-plugin 2.1
+1 Arnaud On 1/4/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > +1 > > Emmanuel > > Brett Porter a écrit : > > All scheduled issues in JIRA have been completed. Please test the > > published snapshot. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Release will proceed in 72 hours if vote carries. > > > > NB: The only change is the inclusion of the deploy:deploy-file mojo. > > Most of the issues filed actually must be addressed in wagon, which this > > release is independent of. > > > > - 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-install-plugin 2.1
+1 Arnaud On 1/4/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > +1 > > Emmanuel > > Brett Porter a écrit : > > All issues in JIRA have been completed. Please test the published > snapshot. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Release will proceed in 72 hours if vote carries. > > > > - 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] > >
