Re: [PLEASE TEST] Maven 2.2.0-RC1
Hi John, no regressions found with Mac OSX 1.5.0_16. Cheers John Casey wrote: Hi everyone, It's that time again. For the 2.2.0 release of Maven, we're trying to keep the number of issues fairly limited to regressions, issues with quite a few votes that are low-hanging fruit, and some sort of strategic issues. We're moving Maven to JDK 1.5 with this release, though the entire API has not yet been generified. We've resolved 15 issues (one is still open, waiting for me to finalize the associated site docs). The full listing is at the bottom of this message, and the link to the release notes is: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=15103 You can find the RC1 staging artifacts here: https://repository.apache.org/content/repositories/maven-staging-008/ ...and the binary/source distribution archives here: https://repository.apache.org/content/repositories/maven-staging-008/org/apache/maven/apache-maven/2.2.0-RC1/ Please note that Maven 2.2.0 will require JDK 1.5 to run, so take this into consideration when testing. If you come across any problems, please file an issue in: http://jira.codehaus.org/browse/MNG and set Affects-Version == 2.2.0. Thanks! -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp What we have to learn to do, we learn by doing. -Aristotle Release Notes: --- Release Notes - Maven 2 - Version 2.2.0 ** Sub-task * [MNG-4144] - document escape character for curly braces in clear-text passwords for settings.xml password security * [MNG-4145] - switch to released versions of plexus-sec-dispatcher (and by ext. plexus-cipher) once they're available ** Bug * [MNG-3553] - cannot resolve dependency with scope import * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4082] - Encryption is triggered if passwords merely contain curly braces * [MNG-4126] - [regression] Properties defined in profiles.xml of parent are not inherited during multimodule build * [MNG-4137] - NPE in DefaultLIfecycleExecutor when run from within Hudson builds * [MNG-4140] - Properties incorrectly replaced in pom * [MNG-4146] - password security doesn't work with custom password providers * [MNG-4147] - very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header ** Improvement * [MNG-2979] - Cross module dependencies for multi-module site * [MNG-3834] - Improve error message when dependency with classifier is missing version ** Task * [MNG-4143] - Update Java requirement to 1.5 ** Wish * [MNG-4139] - avoid the schema location in generated maven-metadata*.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release maven-dependency-plugin 2.1 and dependency-analyzer 1.1
+1 Brian E. Fox wrote: Another smallish release that's been waiting a while. I'm going to work with Oleg next week to have the dependency plugin use mercury so I'd like to get the current fixes out in a stable form first. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14007styleName =HtmlprojectId=11214Create=Create Staging Repo: http://people.apache.org/~brianf/staging-repository2/ Site: http://people.apache.org/~brianf/maven-dependency-plugin/ Vote is open for 72hrs +1 -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.0-alpha-1
+1 Jason van Zyl wrote: Hi, This is really to get the ball rolling for Maven 3.x. While I have some gracious guinea pigs who are arduously pummeling this code base I wouldn't recommend anyone use this in production. If you want to try it and give feedback that's great, but we have a lot of work we know ourselves that needs to be done. Not trying to discourage anyone from trying it but I honestly wouldn't expect much for a at least a couple more weeks. Over the next few alphas the work will be dominated by bug fixing, regression fixing, general alignment with Maven 2.x so that all known requirements to run Maven 2.x plugins are satisfied, and refactoring to prepare the codebase for the fun stuff of adding new features. There is still a lot of work todo, but by the end of January I think I'll have a good enough idea to layout some tentative beta dates and for GA. I know this by guestimating based on myself, Shane, and Oleg working on this full-time and Benjamin working part-time. We are trying extremely hard to make everything accessible by producing tons of ITs, a specification for POM construction and builds coming off the grid at a very high frequency. I hope that fairly soon into the alpha cycle we can attract Ralph into the mix and soon after that more developers. My hope is that by the time the betas rolls around we have 4-5 people who know the core as well as Shane and I do now, and 7-8 by the time we hit GA. I think from this point I would like to try and eject and alpha every week or two with builds coming off the grid many times a day. Please don't expect too much from the distribution if you happen to download it as we know there are problems and we haven't started optimizing at all yet. Shane and I had to do a release before we went batty so we needed to get the process going. I don't think we are going to attempt to integrate newer build of Maven 3.x into m2e for a couple more alphas so anyone doing embedding work I can tell you that it's not time to integrate yet. So without fanfare, here are the standard bits you're looking for: Issues resolved: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=13143pid=10500sorter/field=issuekeysorter/order=DESC Staging repo: http://people.apache.org/builds/maven/3.0-alpha-1/ Distributions: http://people.apache.org/builds/maven/3.0-alpha-1/staging-repo/org/apache/maven/maven-distribution/3.0-alpha-1/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-skins parent POM 4
+1 Dennis Lundberg wrote: Hi It time to release our Stylus skin. To start off we need to get a new release of maven-skins parent 4 out, so that we later can release maven-stylus-skin. This is to comply with the new with the new Privacy policy. Diff of the POM since the last release: http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?r1=526743r2=728980diff_format=h Diff of the site.xml since the last release: http://svn.apache.org/viewvc/maven/skins/trunk/src/site/site.xml?r1=639596r2=729763diff_format=h Vote will be open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [2.0.10 RC7] please test
No regressions found. Cheers Brian E. Fox wrote: (once again with the right url) This fixes the NPE reported in the last RC: http://jira.codehaus.org/browse/MNG-3921 (Thanks Benjamin and Henrique) Here's the list of issues fixed in 2.0.10: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName =HtmlprojectId=10500Create=Create And I've staged RC-6 here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.10-RC7/ Please try it out and see if we have any remaining regressions over 2.0.9. Thanks, Brian -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Filtering version 1.0-beta-2
+1 Olivier Lamy wrote: Hi, In preparation of resources plugin, I'd like to release the shared library maven-filtering version 1.0-beta-2. We solved 6 issues : http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14488styleName=HtmlprojectId=11761Create=Create Staging repo: http://people.apache.org/~olamy/staging-repo/ Staging site: http://maven.apache.org/shared/maven-filtering-1.0-beta-2 (wait sync). Vote open for 72 hours. Here my +1 -- Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shortening paths for core ITs
Arnaud HERITIER wrote: +1 Just a remark : sometime you replace integration-tests by its otherwise by it. Perhaps we could unify them . For example you propose to rename core-integration-tests-support to core-it-support and not to core-its-support. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.1.0-M1
+1 John Casey wrote: Hi everyone, After fixing 70 issues and spending about 2 months going through release candidate after release candidate, we finally have a stable codebase! To that end, I'd like to put Maven 2.1.0-M1 up for a vote. The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14503 and the staged binary is here: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1/org/apache/maven/apache-maven/2.1.0-M1 This vote will be open for 72h. Please vote +1/+0/-1. Here's my +1. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.1.0-M1-RC17
John, no problems encountered. Great work! John Casey wrote: Hi, I've fixed MNG-3748, where illegal elements in the settings.xml were not triggering build failure. Anyway, this release candidate includes a fix for that issue: http://people.apache.org/~jdcasey/stage/current-maven-RC/ Enjoy, and let me know if you have problems. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven enforcer plugin 1.0-alpha-4
+1 nicolas de loof wrote: +1 2008/9/9 Arnaud HERITIER [EMAIL PROTECTED] +1 Arnaud On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon [EMAIL PROTECTED] wrote: +1 --jason On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote: Time to release the enforcer with all its new rules. The plugin is staged here: http://people.apache.org/~brianf/stage/ http://people.apache.org/%7Ebrianf/stage/ The site is staged here: http://people.apache.org/~brianf/plugins/maven-enforcer-plugin/ http://people.apache.org/%7Ebrianf/plugins/maven-enforcer-plugin/ http://people.apache.org/~brianf/enforcer/ http://people.apache.org/%7Ebrianf/enforcer/ Release Notes http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14550styleName =HtmlprojectId=11530Create=Create Vote is open for 72hrs. +1 -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding issues with images using dependency and resource plugins?
Benjamin Bentmann wrote: What encoding exactly would you like to set? The encoding of the file contents? This is not necessary. Encoding is only required when one has to convert between bytes and characters but the (un-)archiving of files is merely a byte-to-byte copy, i.e. operates on a lower level and does not involve textual interpretation of the file contents: Characters --filter-- CharactersSemantic Layer ^ | | | decode encode | | | v Bytes ---copy--- Bytes Physical Layer IIRC, the Dependency Plugin doesn't do filtering so should be fine without encoding configuration. Hi Benjamin, yes you're right - my brain was having a tea break :-) so, yep, all works fine if I don't filter binary images. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
Brian E. Fox wrote: Until I see a definitive list of the Milestones for 2.1, I vote for #2. I am mostly afraid of going down the rat hole that was the old 2.1 with forever changing scope. I don't see any problem with calling this 2.1 and putting in the other features into 2.2, what's the problem? My vote is for #2, as IMO the advantages outweigh the disadvantages pointed out by John. As Brett stressed, anything that has new features should warrant a new 2.x release and bugfixes should go in 2.x.y. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Encoding issues with images using dependency and resource plugins?
Hi all, I've hit upon what I think are encoding issues with the dependency and/or resource plugin, and I'd like to sound out what the others' take on it is. So imagine a scenario in which one has a module that encapsulates all web resources (images, css, js, etc ...) which is shared amongst several webapps. These resources can be packaged in a jar and unpacked via the dependency plugin in the webapp modules. The problem that occurs is that building on different platforms (say Mac for dev and Linux for deployment) the image resources get corrupted (and cannot be retrieve via the web browser from the deployed webapp). The reason why I think it's encoding-related is that: 1. Copying the war built on dev machine to server works fine 2. Adopting the workaround of overriding the image resources with the ones copied from filesystem via ant task (ie by-passing both the dependency and resource plugins) also works fine when built on the server. I've tried setting UTF-8 encoding on resources plugin, but that makes the images unreadable on Mac. I note in passing that the dependency plugin uses the Plexus Unarchiver to unpack, but only the ZipUnarchiver allows to set the encoding property. Is there any reason why setEncoding() is not pulled up to Unarchiver interface? Summing up, anybody else experienced similar issues? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding issues with images using dependency and resource plugins?
Benjamin Bentmann wrote: Do you filter the images? AFAIK, the Resources Plugin should not alter a file's contents during copying unless filtering is enabled on the resource set. Yep - that is indeed the case, I do filter and that is most likely the root of the issue. If you filter your web stuff, you will need to exclude the images (and any other files with binary content) from the filtering. I.e. define two mutually exclusive resource sets, one for the text files to be filtered and one for the binary stuff to be just copied over unaltered. Will do. Thanks for the heads up. Ant's copy task also has a warning about filtering binary data [0]. And infact, I was not filtering when I copied with ant because they were just images. ZipUnarchiver.setEncoding() only controls the encoding for file names as given by zip entries [1,2], not the encoding of the compressed file contents [3]. So unless you experience corrupt file names, that shouldn't be the cause of your problem. Ok - understood, but shouldn't the copying done via the unarchiver in the dependency plugin be able to set the encoding like the resource plugin? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
Brian E. Fox wrote: Exactly. I don't think we need to reopen this up to a bunch more changes, we can make more releases later. If I thought we would be opening a can of worms for this originally, I probably wouldn't have been in favor of it. My understanding was that 2.0.10 became 2.1.0 and more changes would follow on 2.x since we moved out 3.0. I agree with Brian. However tempting to have more features creep in because of the new dot release (as opposed to dot dot) it's better to release a stable version (on which there is now a consensus that it has sufficiently evolved from 2.0.x branch) and focus on next release. Release early, release often ... etc :-) Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
Daniel Kulp wrote: RC11 is looking pretty good to me. I've built several things with it, re-setup my eclipse workspaces from fresh checkouts (eclipse:eclipse), etc... Haven't done a deploy yet (that's next), but everything else is looking pretty good to me. I've done both a snapshot deploy and a release with it without problems. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.10-RC9
[EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, John Casey wrote: Hi everyone, I just wanted to point you to the message I sent to users@ telling people they should go try 2.0.10-RC9. This release candidate incorporates the fixes for the final two issues from RC8, and looks like it's our best chance so far for getting the actual release done. Just to let you know: No issues on 9 modules - consisting of a totalt of 35 artifacts here. Likewise - no problems encountered, performance issues aside. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version for 2.1 branch
+1 Arnaud HERITIER wrote: +1 Arnaud On Sun, Aug 17, 2008 at 11:33 PM, Brett Porter [EMAIL PROTECTED] wrote: +1D On 17/08/2008, at 6:27 PM, Ralph Goers wrote: Is there any reason that the 2.1 branch cannot require java 1.5 to compile and execute? Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.10-RC8
Hi John, no problems encountered so far on all projects tested. Thanks for excellent work! Cheers John Casey wrote: Hi, As you've undoubtedly noticed, the RC7 distro didn't last very long before a nasty bug showed up...actually two, but they were related. At any rate, they're fixed, and here is yet another release candidate. You can get RC8 here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC8/org/apache/maven/apache-maven/2.0.10-RC8 Thanks for your patience during this release process. I know it's drawn out and getting a little old, but we're getting there. The bottom line is: we need many, many more integration tests to shorten this process. For now, all we can do is add use cases as we come across them. Good luck, and happy testing! -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC6
Daniel Kulp wrote: John, Performance is a bit better, but in a multi-project reactor build, the source jars are now all wrong. None of the source ends up in the jars. Just the extra things from the remote-resources. Yes - I can confirm that. In fact, another symptom of this is running cobertura. The coverage report is produced, but when clicking on any class it shows an error because it cannot find the java source. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC6
John Casey wrote: Hi Daniel, Mauro, In either of these cases, can anyone give me some specific steps (and the project SVN URL, if possible) to reproduce the problem? I tried running 'mvn clean source:jar' last night on maven-project and maven-model, but apparently that's too simplistic to reproduce the problem...all of the sources were present. I'd like to open another JIRA for this, but I need more to go on before I can come up with a description for the ticket that makes any real sense. A simple project you can use to reproduce is: svn co https://svn.codehaus.org/xsite/trunk xsite cd xsite mvn clean install -Preporting open xsite-core/target/site/cobertura/index.html and click on any class link to view src. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding Pico to the community builds in hudson
Jason van Zyl wrote: Mauro, Can I have your SVN coordinates and the goals you run to test and I will set Pico up in Hudson for us to test. https://svn.codehaus.org/picocontainer/java/2.x/trunk The uber-build is executed by a simple mvn clean install. This uber-build works now with 2.0.10-RCx but has problems with script-jython module with 2.0.9. In this case the build needs to be done (again mvn clean install) for the individual groups (relative to trunk): site-resources logging pico persistence script web Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding Pico to the community builds in hudson
Jason van Zyl wrote: Mauro, Here's the result here: http://ci.sonatype.org/view/Community%20Test%20Projects/job/XSite/3/console That seem fine? That's fine but you need to check the actual content of the cobertura report. eg open xsite-core/target/site/cobertura/index.html and click on the class link to see if it show the source or gives an error. Don't know how one could automate this since the cobertura report does not expose the url of the single classes. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
Brian E. Fox wrote: I have been saying that the trunk is too changed for 2.1 for a while also. I think having it as 3.0 is probably the logical thing to do and then we can really buckle 2.0 down as it should be and start making these bigger destabilizing fixes/small features to a 2.1 branch cut from 2.0.10. Unless 2.0.10 gets worked out real soon, perhaps we even go back to 2.0.9 and branch there (ie 2.0.10 becomes 2.1.0) I agree. Ideally there should be no backward-incompatible or significant changes between 2.0.x and 2.0.y. New features - not necessarily major but would require migration of sorts - should go in 2.z releases and yes 3.0 is probably best for very significant refactors, as is trunk ATM. I think users have a hard time understanding why a build worked in a previous 2.0.x release but not in the latest. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? Also cutting an alpha or beta would enable IDE devs to work to that without having sleepless nights about stabilisation. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC6
No problems encountered. WRT timing/memory, it now actually seems to have improved somewhat. Eg on 50-ish module build: 2.0.9 [INFO] Total time: 7 minutes 24 seconds [INFO] Finished at: Sat Aug 09 10:25:18 BST 2008 [INFO] Final Memory: 76M/154M 2.0.10-RC6 [INFO] Total time: 6 minutes 20 seconds [INFO] Finished at: Sat Aug 09 10:41:52 BST 2008 [INFO] Final Memory: 70M/142M Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.10-RC5
John Casey wrote: I've checked the maven core and plugins builds, and they're both running around 30s longer than with 2.0.9, with slightly less memory consumption. Other builds I've tried are running nearer to +15s over 2.0.9. Here's a benchmark done on a sizeable project: 2.0.9 [INFO] Total time: 3 minutes 26 seconds [INFO] Finished at: Tue Aug 05 09:11:06 BST 2008 [INFO] Final Memory: 62M/134M 2.0.10-RC5 [INFO] Total time: 4 minutes 16 seconds [INFO] Finished at: Tue Aug 05 09:06:49 BST 2008 [INFO] Final Memory: 58M/135M So a 20% increase on the original time - which is acceptable IMO for the sake of reproducibility. Certainly not a 300% increase. Granted, these aren't huge builds, but neither are they the 3X time increase over 2.0.9 that others are reporting. Can we live with this performance issue through 2.0.10, and try to find a better way around for 2.0.11? I would be inclined to say yes - and if someone hit these huge performance problems, could they stay on 2.0.9 until 2.0.11 came out with the fix? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.10-RC5
John, regression has been fixed on Pico build. Cheers John Casey wrote: Hi, Here's your daily dose of Maven 2.0.10! I've fixed the regressions pointed out in RC4, and added integration tests to guard against their reintroduction. The new release candidate can be found here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC5/org/apache/maven/apache-maven/2.0.10-RC5 The release notes (again): http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112 Please try it out and let me know if things go wrong. Thanks, -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.10-RC4
John Casey wrote: Hi, I've got a new release candidate for people to try out: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC4/org/apache/maven/apache-maven/2.0.10-RC4/ Major changes: - Bumped wagon version to 1.0-beta-4 - Improved handling of mirror definitions without an id/ element The only outstanding potential issue has something to do with the MJAVADOC-172 and MJAVADOC-194 integration tests, in the maven-javadoc-plugin. I'm unable to even build this plugin on my localhost due to unit test failures (even using Maven 2.0.9), so unfortunately I can't even attempt to figure out what the specific failure is in these cases. Hopefully, RC4 will make it possible to distill a failing test case I can use to fix the issue in the core (if it's in the core). John, this RC has a major regression wrt 2.0.9 when building Pico: To reproduce: svn co https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico cd pico mvn install You'll see that when it builds the TCK module - whose src is a sub-part of the core test src - it fails to compile because it cannot find as a dependency the core which had been previously built, and declared as a dependency in the parent management section. I'll see if there is an IT for this scenario (and it not I'll add it), but I suspect some of the changes in the dependencies resolution will be at the root. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
Brett Porter wrote: I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. I would even make a 2.1-beta-1. Betas are by definition stable but not final - and should not be treated as RCs. Alphas on the other hand tend to less trusted by users - who are more reluctant to try them out or use them in commercial projects. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with classloader in maven plugin
Try having a look at this example:
https://svn.codehaus.org/mojo/trunk/sandbox/fit-maven-plugin/src/main/java/org/codehaus/mojo/fit/
Cheers
Claudio Ranieri wrote:
Hi
I am trying to create a maven plugin to jboss wsconsume, but I have a problem
with classloader in plugin.
My plugin is based in an ant task (WSConsumeTask).
I am using maven 2.0.8 on Windows machine.
When I created a simple Java project with libraries necessary, my code works.
How shown below:
public static void main(String[] args) {
WSConsumeTask t = new WSConsumeTask();
t.setWsdl(https://xxx/crypto?wsdl;);
t.setVerbose(true);
t.setKeep(true);
t.execute();
}
But when I am using into maven plugin, I got problem with classloader.
I got this exception:
C:\eclipse\workspace\TestePluginMaven\output\com\buscape\bean\CryptoService.java:7:
cannot find symbol
symbol : class Service
location: package javax.xml.ws
import javax.xml.ws.Service;
^
C:\eclipse\workspace\TestePluginMaven\output\com\buscape\bean\CryptoService.java:8:
cannot find symbol
symbol : class WebEndpoint
location: package javax.xml.ws
import javax.xml.ws.WebEndpoint;
^
C:\eclipse\workspace\TestePluginMaven\output\com\buscape\bean\CryptoService.java:9:
cannot find symbol
symbol : class WebServiceClient
location: package javax.xml.ws
import javax.xml.ws.WebServiceClient;
The plugin classloader doesn´t load the jaxws libraries. But this libraries was
added in pom.xml of plugin.
I tried to add dependencies tag in my plugin config, but didn´t works. How
shown below:
plugin
groupIdjboss/groupId
artifactIdmaven-jbossws-plugin/artifactId
version1.0.0/version
configuration
verbosetrue/verbose
keeptrue/keep
wsdlhttps://xxx/crypto?wsdl/wsdl
/configuration
dependencies
dependency
groupIdjboss.jbossws/groupId
artifactIdjaxws-tools/artifactId
version3.0.1-native-2.0.4.GA/version
scopecompile/scope
/dependency
dependency
groupIdjboss.jbossws/groupId
artifactIdjboss-jaxws/artifactId
version3.0.1-native-2.0.4.GA/version
scopecompile/scope
/dependency
/dependencies
/plugin
I tried too to use an initClassLoader based in jaxws-maven-plugin source, how
shown below:
private String initClassLoader(ClassLoader parent) throws
MojoExecutionException {
try {
List classpathFiles =
project.getCompileClasspathElements();
URL[] urls = new URL[classpathFiles.size() + 4];
StringBuffer classPath = new StringBuffer();
for (int i = 0; i classpathFiles.size(); ++i) {
getLog().debug((String)classpathFiles.get(i));
urls[i] = new
File((String)classpathFiles.get(i)).toURL();
classPath.append((String)classpathFiles.get(i));
classPath.append(File.pathSeparatorChar);
}
urls[classpathFiles.size()] = new
File(project.getBuild().getOutputDirectory()).toURL();
urls[classpathFiles.size() + 1] =
getArtifact(jboss.jbossws:jboss-jaxws);
urls[classpathFiles.size() + 2] =
getArtifact(jboss.jbossws:jaxws-tools);
File toolsJar = new
File(System.getProperty(java.home),../lib/tools.jar);
if (!toolsJar.exists()) {
toolsJar = new
File(System.getProperty(java.home),lib/tools.jar);
}
urls[classpathFiles.size() + 3] = toolsJar.toURL();
System.out.println(urls: +Arrays.toString(urls));
URLClassLoader cl = new URLClassLoader(urls,parent);
// Set the new classloader
Thread.currentThread().setContextClassLoader(cl);
System.setProperty(java.class.path,classPath.toString());
String sysCp = System.getProperty(java.class.path);
return sysCp;
}
catch (MalformedURLException e) {
throw new MojoExecutionException(e.getMessage(),e);
}
catch (DependencyResolutionRequiredException e) {
throw new MojoExecutionException(e.getMessage(),e);
}
}
public void execute() throws MojoExecutionException {
// Need to build a URLClassloader since Maven removed it form
the chain
ClassLoader parent = this.getClass().getClassLoader();
String originalSystemClasspath = this.initClassLoader( parent );
try {
// Execute WSConsumeTask
WSConsumeTask t = new WSConsumeTask();
t.setWsdl(wsdl);
Re: [VOTE] Maven 2.0.9
+1
Brian E. Fox wrote:
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
Release is staged at:
http://people.apache.org/~brianf/stage-2.0.9
Binaries are here:
http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/
List of issues fixed:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
* [MNG-3316] - Barfs at attribues named .*encoding
* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
* [MNG-3394] - Plugin versions inherited via pluginManagement
cannot be overriden by build.plugins section of sub modules
* [MNG-3396] - Managed versions dont affect over constrained ranges
* [MNG-3400] - MavenProject is not extensible
* [MNG-3405] - Checking for updates from repository logging should
not display if WagonManager is offline
* [MNG-3410] - Managed versions in plugins are not considered when
using them
* [MNG-3415] - Transfer errors cause junk metadata in the local repo
* [MNG-3426] - regression : dependency in plugin configuration
doesn't override plugin classpath
* [MNG-3430] - Toolchain doesn't match Toolchain extensions
* [MNG-3431] - Pom Extensions not supported for Toolchains
* [MNG-3439] - incorrect child dependency selected when parent is
not selected
* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository
* [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo
* [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly
* [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken
* [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells
* [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions
* [MNG-3494] - local pom dependencies should get injected before
inherited dependencies
* [MNG-3495] - NPE at
org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24
1)
** Improvement
* [MNG-428] - Japanese message resource
* [MNG-2881] - Improve logging when downloading snapshots in offline
mode
* [MNG-3279] - Support Exception Chaining for MojoFailureException
* [MNG-3318] - ActiveProjectArtifact should have appropriate equals
and hashCode methods
* [MNG-3331] - Normalize paths to sub modules
* [MNG-3388] - DefaultPluginManager needs to catch LinkageError
* [MNG-3395] - Default core plugin versions in the superpom.
* [MNG-3442] - Add explicit resource bundle for
Re: [2.0.9 RC5]
Hi Brian, no issued encountered on a selection of builds wrt to 2.0.8. Cheers Brian E. Fox wrote: This RC has the following changes over RC4: *Webdav 1.0-beta-2 instead of beta-1 (This fixes James' issue) *The webdav extension version that is bundled in core can be overridden by an extension element, thus no longer locking in the users. This plays a little with the classloading so we should rerun all previous tests to make sure nothing new is broken. FWIW, I used the latest RC5-Snapshot to build the official RC5 release and had no issues. *MNG-3221 has been rolled back and fixed in a different way that specifically targets just the report plugins in the forked lifecycles. This should correct the issues seen by Nicolas and Sejal Those are all the known issues in RC4. We had some issues in the past with site plugin compat so we should try to get some coverage in that area as well. Binaries are here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC5/ Thank you everyone for the ongoing testing assistance and regression fixing. I am confident that 2.0.9 is going to bring a new level of quality to the project. We'll see if I still feel that way after we let the users whack at it, but it will be worth it in the end. Once we achieve this level it will be easier to maintain it going forward with more frequent releases and closer attention to how we fix issues along with good ITs to avoid regressions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5
+1 Arnaud HERITIER wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release apache-jar-resource-bundle version 1.4
+1 Daniel Kulp wrote: To comply with the latest requirements discussed on legal-discuss, we need a new version of the apache-jar-resource-bundle. The only change is really the result of discussions and testing around: http://jira.codehaus.org/browse/MRRESOURCES-32 Many thanks to David Jencks for leading that up with legal-discuss. Staging area: http://people.apache.org/~dkulp/stage-bundle/ Tag: http://svn.apache.org/repos/asf/maven/resources/tags/apache-jar-resource-bundle-1.4/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shade-plugin 1.0.1
+1 Daniel Kulp wrote: There is a critical bug in 1.0 where the resulting merged NOTICE files may not be correct. This release is JUST to fix that issue (thus the 1.0.1 version and not 1.1): http://jira.codehaus.org/browse/MSHADE-22 Staging area: http://people.apache.org/~dkulp/stage_shade/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shared-components parent 9
+1 Dennis Lundberg wrote: Hi To get the latest version of maven-source-plugin into our toolchain, I'd like to release the shared components parent r635758 as version 9. A site.xml has been added in this release. Source: https://svn.apache.org/viewvc/maven/shared/trunk/pom.xml?r1=587316r2=632477diff_format=h https://svn.apache.org/viewvc/maven/shared/trunk/src/site/site.xml?revision=635758view=markup SNAPSHOT: A SNAPSHOT has been uploaded as maven-shared-components-9-20080310.232816-2. The vote will be open for 72 hours. +1 from me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release maven-javadoc-plugin 2.4
+1
Brian E. Fox wrote:
It's time to release the next Javadoc plugin. Besides the fixes listed
below, the most important change is the reverting of javadoc acting as
an aggregator. This caused most users tons of grief during releases. The
issue for this is MJAVADOC-137 (reverted MJAVADOC-104)
The plugin is staged at:
http://people.apache.org/~brianf/staging-repository
I'm having technical difficulties deploying the site, but it's an issue
on my side and it'll be up asap.
Release Notes - Maven 2.x Javadoc Plugin - Version 2.4
** Bug
* [MJAVADOC-108] - proxy support for plugin not complete enough
* [MJAVADOC-135] - Error parsing javadoc version when used with IBM
jdk 1.4.2
* [MJAVADOC-136] - UmlGraph 4.8 - could not find map file
* [MJAVADOC-137] - javadoc:javadoc always runs as aggregator
* [MJAVADOC-139] - NPE out of AbstractJavadocMojo::getSourcePaths()
on multimodule project using aggregate
* [MJAVADOC-141] - regression: Adding jar execution to the parent
of a multi-module javadoc plugin causes recursive invocations error
* [MJAVADOC-143] - java.util.NoSuchElementException when using maven
2.0.6 and 2.0.7, but works in 2.0.4
* [MJAVADOC-145] - If Javadoc is set to aggregate, the build fails
inside a Maven plugin module
* [MJAVADOC-147] - -quiet argument is a standard doclet in j2sdk
1.4, not a javadoc option
* [MJAVADOC-149] - Newline in ${project.organization.name} makes
javadoc fail
* [MJAVADOC-151] - No support for 'noProxyHosts' specified in
settings.xml
* [MJAVADOC-152] - Javadoc plugin fails when -J-fullversion returns
localized version string
* [MJAVADOC-155] - maxmemory and minmemory support only m unit
* [MJAVADOC-156] - UnsupportedOperationException in multi module
project
* [MJAVADOC-161] - performRelease=true breaks install/deploy with
multimodule projects
* [MJAVADOC-164] - Javadoc 1.4 fails due to missing directory in
linkoffline option
* [MJAVADOC-172] - classpath is wrong using aggregate mode
* [MJAVADOC-173] - JavadocUtil#copyJavadocResources( File
outputDirectory, File javadocDir ) should exclude default pattern
* [MJAVADOC-176] - javadoc uses the undcoumented and platform
unspecific -J-fullversion to determine version instead of the more
standardized -J-version
** Improvement
* [MJAVADOC-153] - Generate the OfflineLink class with Modello
* [MJAVADOC-158] - Command line dump reveals proxy user/password in
case of errors
* [MJAVADOC-159] - nooverview not implemented
* [MJAVADOC-160] - Validate javadoc options and standard doclet
options
* [MJAVADOC-165] - Provide specific default value for encoding
parameter
* [MJAVADOC-169] - Add support for i18n
** New Feature
* [MJAVADOC-148] - Support of -top option in standard doclet JDK 6.0
** Task
* [MJAVADOC-154] - Bump to plexus-utils:1.4.6
* [MJAVADOC-174] - Fix hyperlink to reference doc for mojo parameter
use
72hrs, yada yada
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Benjamin Bentmann as Maven committer
+1 Lukas Theussl wrote: I'd like to propose giving commit access to Benjamin. During the last few months, he has provided patches in so many areas of Maven that I can't list them all here (various plugins, surefire, doxia,...), including documentation and translations, and he has not been afraid to actively discuss things on the dev list. I think he would make a great addition to our team. +1 -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
+1 Raphaël Piéroni wrote: Hi, Here comes the time for calling the first release of the Maven Archetype plugin version 2.0-alpha-1. Staging repo: http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/ Staging site: No staging site now, the new documentation is not yet written. Its is planed for version 2.0-alpha-2. Vote open for 96 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] (take 2) Release Maven Surefire plugin version 2.4.1
+1 Dan Fabulich wrote: Fabrizio found a last-minute bug. I've rolled a new candidate. Let's vote again! [Boy, the temptation to let the rules slide on a change this small is almost irresistable. ;-)] -Dan -- Forwarded message -- Date: Sat, 26 Jan 2008 11:53:28 -0800 (Pacific Standard Time) From: Dan Fabulich [EMAIL PROTECTED] Reply-To: Maven Developers List dev@maven.apache.org To: Maven Developers List dev@maven.apache.org Subject: [VOTE] Release Maven Surefire plugin version 2.4.1 With a change as big as Surefire 2.4, there turned out to be a few bugs still lurking. We solved 7 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=14016 There are still 38 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541status=1 Staging repo: http://people.apache.org/~dfabulich/staging-repo/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 Surefire plugin version 2.4.1
+1 Dan Fabulich wrote: With a change as big as Surefire 2.4, there turned out to be a few bugs still lurking. We solved 7 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=14016 There are still 38 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541status=1 Staging repo: http://people.apache.org/~dfabulich/staging-repo/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-dependency-plugin 2.0
+1 Brian E. Fox wrote: It's been a long time since the last release and we have lots of improvements/fixes: Release Notes - Maven 2.x Dependency Plugin - Version 2.0 ** Bug * [MDEP-59] - dependency:unpack can't extract rar archives * [MDEP-74] - dependencies in test scope are not handled properly by analyze * [MDEP-75] - non-portable classpath separator in build-classpath output * [MDEP-80] - Usage page of the docs use an overWrite property, but none exists in the (auto-generated) goal reference docs * [MDEP-81] - analyzer can't handle non-pom projects that don't produce a /target folder * [MDEP-83] - Typo in How to prepare your dependencies before updating to Maven 2.0.6 * [MDEP-91] - org.codehaus.mojo:dependency-maven-plugin takes precedence over org.apache.maven.plugins:maven-dependency-plugin * [MDEP-93] - Tests can fail with OOME * [MDEP-95] - can't build unit tests with jdk1.4 rev 545703 * [MDEP-97] - dependency:tree not consistent with maven core's dependency tree * [MDEP-113] - Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT * [MDEP-120] - build-classpath is unable to build a classpath with runtime or test dependencies ** Improvement * [MDEP-89] - change separators in build-classpath * [MDEP-96] - Allow includes and excludes to be used simultaneously in the same filter * [MDEP-99] - Unpack SWC files * [MDEP-100] - Merge dependency:tree branch for new features * [MDEP-101] - Add dependency:list alias for dependency:resolve * [MDEP-104] - Add Analyze HTML Report * [MDEP-111] - Provide output on file as in other goals * [MDEP-119] - build-classpath should create destination directory for the classpath file * [MDEP-125] - Build-classpath should store the classpath in a Filter * [MDEP-129] - allow substitution of the absolute local repo path with a property * [MDEP-130] - allow the classpath file to be attached * [MDEP-131] - Complete i18n support for new analyze-report * [MDEP-132] - Add german translation for analyze-report mojo * [MDEP-133] - Add dedicated resource bundle for locale en ** New Feature * [MDEP-47] - Ability to have an includes/excludes feature on the dependency:unpack goal. * [MDEP-70] - add new mojo to perform analysis of dependencies and fail the build if certain conditions aren't met * [MDEP-71] - add report to display contents of dependency-analyzer * [MDEP-94] - Add dependency:tree goal * [MDEP-116] - [dependency :copy-dependencies ] Add parameter to allow extracting POMs Staged at: http://people.apache.org/~brianf/staging-repository Vote is open for 72hrs. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
Brian E. Fox wrote: It's not entirely true that versions don't matter. Alpha or Beta is really a less important distinction and we are generally trying to move away from more alpha/beta releases. I would argue that since Maven requires Shade to release, that the current version should be 1.0 not alpha or beta. Doing a release is much more than slapping a version (tag) on it. It makes the next version usable by other people to do releases because it means we've pushed a non-snapshot to the public. If there are people unaffected by MSHADE-9, then there is still value to those people in having a release now rather than later. I think in general we try to fix too many things at once and end up not getting important fixes out to the people that need them. I'd rather see a release come out with the current fixes and then when MSHADE-9 is fixed, we do another release. At least then some people can use it rather than making everyone wait...and realistically doing the release doesn't preclude someone from fixing the issue in parallel so it shouldn't in theory delay the inevitable release with the MSHADE-9 fix in it. +1 Betas (and alphas) IMO should be milestones towards a final major release 1.x or 2.x. But all too often betas tend to get treated as final releases. No problem in having a release with a known issue (in this case MSHADE-9). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shade improvement: filtering
David Blevins wrote: Mauro, is it possible you can publish a new snapshot or update the perms on the metadata files? Done both. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fix-permissions.sh
Brian E. Fox wrote: Good idea. Is the script still there? I seemed to have a hard time finding it. /www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh I think we should move it one level up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fix-permissions.sh
Mauro Talevi wrote: Brian E. Fox wrote: Good idea. Is the script still there? I seemed to have a hard time finding it. /www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh I think we should move it one level up. And possibly enhance script to take repo name as mandatory param: fix-permissions.sh repo Note that one needs to be in apsite/apcvs groups to do that. I've now run script on m2-ibiblio-rsynch-repository (I probably did not run it when I deployed surefire 2.3.1). Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-dependency-analyzer 1.0
+1 Brian E. Fox wrote: In preparation for releasing the dependency plugin, I'd like to release the maven-dependency-analyzer 1.0. This has a few fixes documented under the latest mdep release. Staged at: http://people.apache.org/~brianf/staging-repository +1 --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Second Try] Release Maven Jar plugin version 2.2
+1 Olivier Lamy wrote: Hi, I'd like to release the Maven Jar Plugin version 2.2. We solved 26 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=12878styleName=HtmlprojectId=11137Create=Create Staging repo : http://people.apache.org/~olamy/staging-repo Staging Site : http://people.apache.org/~olamy/staging-sites/maven-jar-plugin-2.2/ Tag : https://svn.apache.org/repos/asf/maven/plugins/tags/maven-jar-plugin-2.2/ Change since first try : - insure the released pom contains license header - documentation update. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here my +1 (non binding). Thanks, -- Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Jar plugin version 2.2
+1 Olivier Lamy wrote: Hi, I'd like to release the Maven Jar Plugin version 2.2. We solved 26 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=12878styleName=HtmlprojectId=11137Create=Create Staging repo : http://people.apache.org/~olamy/staging-repo Staging Site : http://people.apache.org/~olamy/staging-sites/maven-jar-plugin-2.2/ Tag : https://svn.apache.org/repos/asf/maven/plugins/tags/maven-jar-plugin-2.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here my +1 (non binding). Thanks, -- Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] preparing the release of archetypeng
+1 Raphaël Piéroni wrote: Hello, I would like to prepare the alpha-1 release of the archetypeng stuff. Preparing that release will need to do these things: 1. move the current archetype code (svn.apache.org/repos/asf/maven/archetype/trunk) to a branch (.../branches/archetype-1.0.x) 2. move the current archetypeng (svn.apache.org/repos/asf/maven/sandbox/trunk/archetypeng) to to the old archetype trunk This vote is open for at least 72 hours Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [Take 2] Release Maven Surefire version 2.4
+1 - no problems encountered. Dan Fabulich wrote: Hi, Maven Surefire version 2.4 is back on the runway. A handful of bugs were fixed since the previous take, including SUREFIRE-416 (which blocked the release). Note that I'm still unable to reproduce SUREFIRE-328, which some people claim to have seen in the wild. If you can reproduce it with the staged 2.4 Surefire, please send me a REDUCED Maven project that reproduces the problem [that is, not your entire build, if you can help it ;-)] I also took this opportunity to make a briefer shortcut for skipping test execution without skipping test compile. You should now be able to mvn install -DskipTests to compile your tests without running them. (Note no need for =true.) Hopefully folks have spent some time trying out the SNAPSHOT version or the previous take, because we expect ordinary users to get auto-upgraded to version 2.4 when we decide to release. This version fixes numerous long-outstanding bugs, notably in TestNG support. We solved 72 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=13243 There are still 30 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541status=1 Staging repo: http://people.apache.org/~dfabulich/staging-repo/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 PS Since it's so close to the Gregorian New Year, I'm probably not going to actually deploy the release until Jan 3 at the earliest, even if the vote passes. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Surefire version 2.4
+1 Dan Fabulich wrote: Hi, Maven Surefire version 2.4 is on the runway. Hopefully folks have spent some time trying out the SNAPSHOT version, because we expect ordinary users to get auto-upgraded to version 2.4 when we decide to release. This version fixes numerous long-outstanding bugs, notably in TestNG support. We solved 71 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=13243 There are still 31 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10541status=1 Staging repo: http://people.apache.org/~dfabulich/staging-repo/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 PS This is my first call for a release. Be gentle. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Result] [Vote] [Take 2] Release Maven Surefire 2.3.1
Mauro Talevi wrote: Hi all, all showstoppers have been addressed. Second attempt for Maven Surefire 2.3.1 release. Issues solved: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=13251 Staging repo: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/surefire/tags/surefire-2.3.1/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Cheers This vote passed with the following votes: +1 (binding): Jason van Zyl, Brian E. Fox, John Casey, Brett Porter +1 (non-binding): Oliver Lamy, Nicolas de Loof, Mauro Talevi, Marat Radchenko +0 (non-binding): Jerome Lacoste No other votes. The artifacts have been moved over to the ASF repository. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] [Take 2] Release Maven Surefire 2.3.1
Marat Radchenko wrote: Till now I thought that currently 2.4-SNAPSHOT and 2.3.1 are the same thing. No, they are not - 2.4 will be released shortly and it is a separate dev branch. Please raise issue only if the build works fine with 2.3.1-SNAPSHOT. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] [Take 2] Release Maven Surefire 2.3.1
Hi all, all showstoppers have been addressed. Second attempt for Maven Surefire 2.3.1 release. Issues solved: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=13251 Staging repo: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/surefire/tags/surefire-2.3.1/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox
Vincent Siveton wrote: -1 due to compilation failure with jdk1.4 on tag. http://rafb.net/p/jVfAXG92.html Right - I thought the maven plugins parent POM would have fixed the target/source JDK to 1.4. I'd continue with vote (would avoid issuing another one) and fix JDK compat before releasing. Any objections? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox
Daniel Kulp wrote: Crap. Second time I've done this in the last couple weeks. :-( Why the 1.5 javac doesn't flag these things with source/targe set to 1.4 is beyond me. Eclipse doesn't even flag them when using 1.5 but project is set to 1.4. That said, I just figured out how to get the eclipse project to use a 1.4 JVM for the maven projects I have so hopefully I won't do this again. I've just committed fixes for it. Sorry about that. Thanks for that Dan! I've rebuilt staging artifacts and created tag with latest revision. URLs same as in the original email. I'll wait until tomorrow to copy from staging to release repo. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoker vs. Verifier?
Dan Fabulich wrote: John Casey wrote: What you're seeing as overlap is a mixture of concerns in the invoker plugin. The verifications beanshell really needs to be migrated out to some sort of proper integration-testing plugin (or, even better, a plugin that unites invoker and verifier under a common configuration...then extend the verifier with the invoker's beanshell functionality). Regardless, the invoker plugin can be used for any sort of scenario where you need to fork a new maven process. I've personally used it to proxy secondary builds in some sticky client use cases. You don't have to use the beanshell script to verify the build, it's just an [admittedly confusing] option. As I've remarked before, I find it weird that various Maven developers have gone and written _plugins_ to do Maven integration testing. Integration tests are just tests; we know how to write/run tests using real test frameworks like JUnit and TestNG. Those frameworks are pretty cool; you can do stuff like rerun failures-only, graph results over time, write data-driven tests, etc. You can even use them to write tests in scripting languages like Groovy, BeanShell, etc. All that AND you get excellent IDE integration. More generally, while I certainly see the value of a maven-invoker-plugin, I don't expect that you'd want that to be the normal way people would write Maven integration tests. Right now there are four things: maven-verifier, maven-verifier-plugin (no relation!), maven-invoker, and maven-invoker-plugin. I think I'd like to advocate ripping out the bulk of maven-verifier and make it depend entirely on maven-invoker. Since maven-verifier is so confusingly named, I think I'd want to take the good bits out and put them in maven-integration-test-helper (which is what maven-verifier really is, anyway). More controversially (?) I'd like to deprecate the idea of writing *tests* using the maven-invoker-plugin, instead preferring to write them in Java (or BeanShell, I'm easy!) running them using a real test framework. maven-invoker-plugin should still be used for spawning sub-builds in those delightful cases where that's necessary. Thoughts? Dan, I agree with you - integration tests would benefit from having a more unified approach, just like unit tests are run by surefire. It should support different languages, Java and scripting, and different runners. I would still have a different plugin for ITs than for unit tests, as they typically are run with different usecases, and I fear that surefire would get overloaded. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox
Following fixes, new version 1.0-alpha-15 has been staged for release. Please for vote for its release and to move this version of the sandbox (and start dev of 1.0-beta-1-SNAPSHOT). Staging area: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0-alpha-15/ As it's second take and alpha release - I'd like to keep vote open for 24 hours only. Here is my +1 [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Dan Fabulich wrote: Uh, actually, I need to turn my vote to a -1. :-( I just discovered that I'm being bitten by MSHADE-5 (and MSHADE-6) every time I go to deploy the Surefire 2.4-SNAPSHOT. As a result, I deployed a corrupted SNAPSHOT... yuck! I just fixed MSHADE-6 in the sandbox, which would have at least prevented me from deploying a defective binary. I still don't see a great way to resolve MSHADE-5 except to pursue a strategy like the one described in MSHADE-7 (perhaps, as dkulp suggested, as an option). I'm going to go try to do the deploy directly from people.apache.org now. :-( Dan, I would seem to me MSHADE-5 is connected to Windows' less-than-optimal filesystem management, I've never seen it on Unix. The fact that it occurs only occasionally is a telling sign. I've commented on MSHADE-7 - as far as I can tell, feature is already implemented, via shadedArtifact attachment. Please try out the configuration in: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0-alpha-14/src/test/projects/shaded-attached-project/pom.xml Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Maven Ant Tasks 2.0.8 (take 2)
+1 Hervé BOUTEMY wrote: Hi, Following Maven release, I'd like to release (again) Maven Ant Tasks 2.0.8. Problem with dependencies order has been fixed. We solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533styleName=Htmlversion=13618 The tasks can be downloaded from: http://people.apache.org/~hboutemy/staging-repo/org/apache/maven/maven-ant-tasks/2.0.8/maven-ant-tasks-2.0.8.jar Staging repo: http://people.apache.org/~hboutemy/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/ant-tasks/tags/maven-ant-tasks-2.0.8/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Brian E. Fox wrote: It would be cool if you could try the new candidate on 2.0.x also. I had trouble with it excluding tons of stuff when I did 2.0.8. I can try it later today if you can't. Built a 2.0.9 snapshot and try it out on a sample projects. No problems encountered. So it does look promising. I would stage an alpha-15 release and let people loose on it. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.3.1, 2.4 and Shade
On Sat, 8 Dec 2007 22:09:45 -0800 (Pacific Standard Time), Dan Fabulich [EMAIL PROTECTED] wrote: I think that means that if we release maven-shade-plugin alpha-14, even without fixing MSHADE-9, we can release Surefire 2.4, which would make me very happy. :-) Staged alpha-14 at http://people.apache.org/~mauro/staging-repo When you guys give the thumbs up, I'll copy stage to repo. Cheers
Re: Surefire 2.3.1, 2.4 and Shade
On Mon, 10 Dec 2007 13:47:27 -0500, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 10 December 2007, Mauro Talevi wrote: On Sat, 8 Dec 2007 22:09:45 -0800 (Pacific Standard Time), Dan Fabulich [EMAIL PROTECTED] wrote: I think that means that if we release maven-shade-plugin alpha-14, even without fixing MSHADE-9, we can release Surefire 2.4, which would make me very happy. :-) Staged alpha-14 at http://people.apache.org/~mauro/staging-repo When you guys give the thumbs up, I'll copy stage to repo. Cheers You would need to call a vote on [EMAIL PROTECTED] and have the vote pass. Well - it was recently agreed that no vote was required for alphas. That said, it looks good to me. Cool!
Re: Surefire 2.3.1, 2.4 and Shade
Dan Fabulich wrote: I just posted a long e-mail to surefire-dev about my findings re: Surefire 2.3.1, 2.4 and Shade. I won't repost it here, but here's the summary: Summary: I think we're ready to release 2.3.1, because I can't reproduce regression SUREFIRE-347, the only bug targeted for 2.3.1. I was able to reproduce a related bug SUREFIRE-334, and was able to fix it using maven-shade-plugin alpha-14-SNAPSHOT (even though MSHADE-9 isn't fixed yet). If we go ahead and release maven-shade-plugin alpha-14-SNAPSHOT, we can release Surefire 2.4 as well (or instead). Hi Dan, I'll release alpha-14 later today, unless somebody has any objections. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release process
olivier lamy wrote: Hi, I'd like to work on release for maven-invoker-plugin (and maven-invoker). For this there are two things to release maven-invoker and maven-invoker-plugin. Does this needs two separate votes ? I would say that one is enough if staged at the same time. But first, is the documentation here [1] up to date ? http://maven.apache.org/developers/release/releasing.html Can I do this as I'm not a PMC ? Any committer can stage and call for a vote. An other newbie question : what I have to do with gpg key. Is it needed for artifacts deployed on the repo ? Attach it to https://svn.apache.org/repos/asf/maven/project/KEYS and configure your .m2/settings.xml profile as in the release document above. It's needed for authenticating the upload of the staging artifacts. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
As version 1.0-alpha-14 has been staged for release, I'd like to call a vote for its release and the move out of the sandbox and to version 1.0-beta-1-SNAPSHOT. Staging area: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0-alpha-14/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.3.1, 2.4 and Shade
Dan Fabulich wrote: Well - it was recently agreed that no vote was required for alphas. That's surprising to me... I'd at least post to dev to make sure you don't get a -1. I distinctly remember that alphas should be released with more ease and not the same formality. But I decided to call for a vote unifying it to the move out of sandbox. I'll then double check the alpha release process and update the webpage for reference. Cheers
Re: Status of maven-shade-plugin?
Brian E. Fox wrote: We had to revert back to the codehaus version to do 2.0.8 because something in the apache version was definitely hosed. Brian, did you make a note of what rev of mojo src you took to start the repackaging and move? It would seem that shade-maven-plugin-1.0-alpha-12 was cut on Sep 1 and nothing's changed until rev 5633, when you applied the dependency fix for 1.0-alpha-13 (fix applied also to maven-shade-plugin, http://jira.codehaus.org/browse/MSHADE-10) On the other hand, maven-shade-plugin was imported on Sep 10, presumably from head rev (ie 5162) and initial commit has the src tar bundle (rev 574111). So the options are: 1. we could go through with fine comb to track any diffs. 2. we could plough ahead and write ITs for apache plugin, in particular the use case of maven-2.0.x distro. I would go for option 2, releasing alpha-14 - and only when we feel it's completely replace shade-maven-plugin cut beta-1. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release surefire 2.3.1?
Dan Fabulich wrote: Nope. SUREFIRE-347 is regression: plexus is not properly isolated which is what I'd wish we'd fix before we release 2.3.1. Rolled back commits for 2.3.1 staging release and added regression issue to 2.3.1 target again. Any other issue that can be fixed by weekend should also be added of course. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Surefire 2.3.1
Dan Fabulich wrote: -0. I can try to fix the three open 2.3.1 bugs sometime this weekend; if you can afford to wait that long, I think that'd be preferable. Dan, firstly, nothing prevents us from releasing a 2.3.2 right after a 2.3.1. Also, I had asked about anybody in the process of fixing the 3 outstanding issues but nobody had come forward. Now I need to fix the problem of the non-resolved version in surefire-providers POM, so I'll have to revert tag, fix and cut new release. If you say that you will to have a crack at them on the weeekend, shall we say that we'll cut it Sunday eve GMT, and any issues you can fix by then will be included? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Surefire 2.3.1
Marat Radchenko wrote:
surefire-providers has corrupt dependency:
dependency
groupId${project.groupId}/groupId
artifactIdsurefire-api/artifactId
version2.3.1-SNAPSHOT/version
!-- commenting this due to MNG-2339
version${project.version}/version
--
/dependency
should be 2.3.1 instead of 2.3.1-SNAPSHOT
Thanks for pointing it out. MNG-2339 strikes again :-)
I'll implement a workaround and re-release on the weekend.
Cheers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release surefire 2.3.1?
Brett Porter wrote: I was hesitant because at least one of them seemed to be a regression over 2.3. Anyway, my preference is to fix them first - but if someone is prepared to do a release - go for it. There's lots of good stuff in there already. I agree they should be fixed, but since no one has stepped forward to say that they're being worked on, I'll prepare release of what's currently there. I personally need some of the fixes released for at least one project. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Maven Ant Tasks 2.0.8
+1 Hervé BOUTEMY wrote: Hi, Following Maven release, I'd like to release Maven Ant Tasks 2.0.8. We solved 17 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533styleName=Htmlversion=13618 The tasks can be downloaded from: http://people.apache.org/~hboutemy/staging-repo/org/apache/maven/maven-ant-tasks/2.0.8/maven-ant-tasks-2.0.8.jar Staging repo: http://people.apache.org/~hboutemy/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/ant-tasks/tags/maven-ant-tasks-2.0.8/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Maven Surefire 2.3.1
Hi all, I'd like to release Maven Surefire 2.3.1 Issues solved: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541styleName=Htmlversion=13251 Staging repo: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/surefire/tags/surefire-2.3.1/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release surefire 2.3.1?
Hi, as there have been a number of useful fixes since 2.3, and in line with the release early-release often, I wanted to gauge opinions about the opportunity to release 2.3.1 as currently in branch and postponing outstanding 2.3.1 issues to a 2.3.2. Unless these outstanding issues are being worked on and a fix is imminent. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can you plz address this issue: http://jira.codehaus.org/browse/MRRESOURCES-26
Jason Dillon wrote: I need this puppy applied and released for the upcoming GShell 1.0-alpha-1 release, which is a dependency of the upcoming G 2.1 release... So if we can get this guy patched and published sooner rather than later it would really help. I know you are busy, but can you please take a look? Hi Jason, I've deployed latest snapshot for the moment. As there are no outstanding issues for 2.3 I'll prepare staging build for it. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can you plz address this issue: http://jira.codehaus.org/browse/MRRESOURCES-26
Mauro Talevi wrote: Jason Dillon wrote: I need this puppy applied and released for the upcoming GShell 1.0-alpha-1 release, which is a dependency of the upcoming G 2.1 release... So if we can get this guy patched and published sooner rather than later it would really help. I know you are busy, but can you please take a look? Hi Jason, I've deployed latest snapshot for the moment. As there are no outstanding issues for 2.3 I'll prepare staging build for it. Sorry got configured with MRESOURCES :-) MMRESOURCES is already staged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-remote-resources-plugin 1.0-beta-1
+1 Daniel Kulp wrote: I'd like to release version 1.0-beta-1 of the maven-remote-resources-plugin. This resolves one critical bug reported by Jason Dillon as well as fixes two other issues: Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-beta-1 ** Bug * [MRRESOURCES-26] - NPE in remote-resources:process while sorting orgs * [MRRESOURCES-27] - RemoteResourcesClassLoader isn't isolated from maven jar ** Wish * [MRRESOURCES-28] - Attaching the generated resources to the project should be optional (for webapps) Staging area: http://people.apache.org/~dkulp/stage-rr/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-beta-1/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.8 broken war build
Kev Jackson wrote: Hi, I've just been re-building my project with the new mvn 2.0.8 binary. Here's my experience so far. mvn clean install (jars) - works as 2.0.7 mvn clean package -Pprofile (war) - broken (re-tested on 2.0.7 and works) So something has changed in 2.0.8 that has affected surefire. Here is a snippet of the error Nov 29, 2007 10:09:01 AM com.seanergie.persistence.SessionsManager initialize SEVERE: Exception building Hibernate SessionFactory : Could not find datasource org.hibernate.HibernateException: Could not find datasource at org.hibernate.connection.DatasourceConnectionProvider.configure(Datas ourceConnectionProvider.java:56) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvi der(ConnectionProviderFactory.java:124) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvi For each unit test that uses Hibernate (v3 with Annotations HibernateSearch), the same error 'Could not find datasource'. For mvn 2.0.7 the build works perfectly. I haven't changed my hibernate.cfg.xml file between builds, I haven't changed any code or config between builds, the only thing I changed was MVN_HOME PATH to 2.0.8. As these errors occur during the surefire:test phase of the build I'm assuming that something has changed in the Classpath management for surefire? Any help would be appreciated. The one notable change is that test-classes now precedes classes dir: http://jira.codehaus.org/browse/MNG-3118 I would guess that before your tests picked up hibernate.cfg.xml from classes dir and now it picks it up from test. Check if both are needed. I would seem you only need the one in classes. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [take 2] release maven 2.0.8
+1 Brian E. Fox wrote: It's that time again, finally. The RC's have been floating for a few weeks now and no new issues have surfaced. (the packaging issues with the uber jar have been resolved since the last vote) The release is staged at: http://people.apache.org/~brianf/staging-repository The binary packages are here: http://people.apache.org/~brianf/2.0.8/ Release Notes - Maven 2 - Version 2.0.8 ** Bug * [MNG-2025] - POM is still not read using the right encoding * [MNG-2045] - Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) * [MNG-2061] - DistributionManagement properties don't get copied in cloned executionProject while lifecycle fork * [MNG-2254] - the encoding parameter in xml declaration of POM is ignored * [MNG-2277] - aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue * [MNG-2593] - Maven 2 stumbels upon non ASCII characters in the value of a localRepository value in the $HOME/.m2/settings.xml * [MNG-2685] - mvn.bat detection of 4NT syntax error * [MNG-2932] - Encoding chaos * [MNG-2961] - DefaultArtifact getBaseVersion is changed to -SNAPSHOT only if you first call isSnapshot() * [MNG-3046] - DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0 * [MNG-3077] - NullPointerException, if MojoExecutionException has no message * [MNG-3084] - mvn.bat in maven 2.0.7 does not return the correct error code. * [MNG-3095] - maven-plugin-testing-tools causes bad version in deployed artifacts after tests are run * [MNG-3134] - DefaultModelInheritence::assembleDistributionInheritence should be childPathAdjustment aware * [MNG-3141] - Build not working if pom.xml is a symbolic link * [MNG-3215] - Missing rar artifact handler descriptor * [MNG-3240] - maven-model RepositoryBase.equals() causes ClassCastException * [MNG-3245] - Maven Reporting API is binary incompatible in 2.0.8-SNAPSHOT by r579987 * [MNG-3254] - artifactId is not appended any more in distributionManagement.site.url in multi modules when it's not defined in a child ** Improvement * [MNG-2188] - Report mojos should check canGenerateReport() when called directly * [MNG-2290] - Generated URLs in POMs of child modules * [MNG-3024] - Missing artifact error text improvement * [MNG-3047] - DefaultArtifactVersion compareTo inconsistent with equals * [MNG-3062] - Allow access to mojoExecution from within plugin. * [MNG-3118] - Test-classes should come before classes in the classpath * [MNG-3152] - Change to plugin testing harness to allow the setting of ArtifactRepository on the ArtifactStub * [MNG-3201] - org.apache.maven.project.MavenProject needs a toString() ** New Feature * [MNG-2105] - Enable remote debugging command line option (+ docs) * [MNG-2166] - Provide the help listing as default when no arguments are provided ** Task * [MNG-3088] - update the assembly name ** Wish * [MNG-3207] - Order of repositories for download should be inverted if Archiva is used. Vote is open for 72hrs +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Nicolas de Loof as a committer
+1 Brett Porter wrote: I'd like to call a vote for Nicolas de Loof as a committer, based primarily on his work for Archiva, but also from being active in the general Maven community for quite some time. He has been relentlessly testing and identifying issues and providing patches recently. +1 from me - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven 2.0.8
olivier lamy wrote: Hi, I have an issue : [WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-clean-plugin' could not be retrieved from repository: rec-ap2-m2-plugins due to an error: Unsupported Protocol: 'http': Cannot find wagon which supports the requested protocol: http The problem is with the packaging of the uber jar. It skipped the wagon dependencies. jar tvf lib/maven-2.0.8-uber.jar | grep http - should yield wagon http provider classes but they are not present. I had fixed it and tested against the 2.0.8 tag created yesterday, but it seems to have re-appeared in the release. It may be down to the release plugin artifact resolution. A quick workaround to get release out would be to branch off 2.0.8 tag, fix and release from it. In the mean time, I'll investigate the release process packaging. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Naming convention for ITs
Hi all, there is a duplication of test classes in Surefire ITs, which leads to classpath conflicts when entire project is opened in an IDE. How about we adopt the convention to avoid these conflicts. Either: 1. We use different test class names, eg TestSurefireN.java where N is the test number. 2. We use packages to isolate ITs, eg org.apache.maven.surefire.itN.TestSurefire.java Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to build release from trunk?
aldana wrote: hi, i am living with severe bugs (see http://jira.codehaus.org/browse/MNG-3252) + transitive resolving which not only comes from assembly plugin (as stated in http://jira.codehaus.org/browse/MASSEMBLY-242) merely in maven core transitive resolving too. i would like to help to fix and to integrate the fixes in our current maven installation for it is critical in our development. how do i integrate the development from svn to my maven installation (haven't found docs about this)? for checking possible cleaned bugs, i first would like to build a release from the latest development: how do i build a release (maven distribution)? is there a script for this? i doubt a mvn deploy would do all... if the bugs are not resolved following questions: 1) is there a developer guide, so i can look at what places the bugs occur (in my case: transitive dependency management, snapshot download handling) 2) is it possible that i can commit bugfixes? thanks a lot! Hi, the guide to building maven can be found at: http://maven.apache.org/guides/development/guide-building-m2.html In general, it find a bug or what you see as a problem, you'd file a Jira issue, as you've correctly done, possibly with a patch containing the bugfix and (always very useful!) a test case or an integration test case proving the issue. It is then up to the committers to review the issue and apply the patch if considered appropriate. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-release-plugin 2.0-beta-7
+!
Brian E. Fox wrote:
I ran into an issue releasing 2.0.8 due to
http://jira.codehaus.org/browse/MRELEASE-296 and the addition of the
${mavenVersion} in the poms. This release is required for a release of
2.0.8.
Staging repo:
http://people.apache.org/~brianf/staging-repository/
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13560styleName
=HtmlprojectId=11144Create=Create
Vote will be open for 72hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Maven / shared / plugin parent poms
+1 Brian E. Fox wrote: +1 -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 5:00 PM To: Maven Developers List Subject: Re: [VOTE] release Maven / shared / plugin parent poms +1 for all Carlos Sanchez wrote: Please vote for a release of maven parent and two of the children Maven parent 7 - upgraded remote resources plugin and apache resources bundle to latest release - added javadoc urls - added developers maven-shared-components parent - use latest maven parent maven-plugins parent - use latest maven parent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven war plugin 2.1-alpha-1
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-changes-plugin 2.0-beta-3 (take 3)
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patches waiting to be applied
[EMAIL PROTECTED] wrote: I would also like to see an MJAR patch, especially if it includes http://jira.codehaus.org/browse/MJAR-30 Robert Egan William Ferguson [EMAIL PROTECTED] wrote on 10/10/2007 05:48:36 PM: I don't want to nag, but could someone please apply the patches for http://jira.codehaus.org/browse/MRESOURCES-47 and http://jira.codehaus.org/browse/MJAR-83 William All 3 patches applied and snapshots deployed. Please try out. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patches waiting to be applied
William Ferguson wrote: I don't want to nag, but could someone please apply the patches for http://jira.codehaus.org/browse/MRESOURCES-47 and http://jira.codehaus.org/browse/MJAR-83 William I've assigned them to me and I'll look at them over weekend. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commits mailing list now on Gmane
Hi All, for anybody like me that really can't live without gmane-supported lists, I've had the the commits list added to gmane group: gmane.comp.apache.maven.scm For those new to Gmane, it's a bi-directional mail-to-newsgroup service that allows to keeps on top of mailing lists without having to subscribe directly to them. More info on http://gmane.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Plugin Sites (was: Re: Plugins sandbox site)
Wendy Smoak wrote: On 10/4/07, Brian E. Fox [EMAIL PROTECTED] wrote: From: Wendy Smoak [mailto:[EMAIL PROTECTED] There is now (in v9) some config in the plugin parent for staging sites under maven-whatever-plugin-x.y-SNAPSHOT and I would like to get that trend started for plugin docs. Or at least see if there are objections and we need to talk about it more. Here's what it looks like: plugins/maven-whatever-plugin -- latest release plugins/maven-whatever-plugin-1.1.6 -- archived release docs plugins/maven-whatever-plugin-1.2.3 -- latest release, for archives plugins/maven-whatever-plugin-1.2.4-SNAPSHOT How does it move a site from the latest release to an archived one? Are you doing some rewrite rules or something? This is not currently in place, so it's not happening at all yet. :) I'd say we just publish to the staging area from the tag when the release vote is called (for review) and then do a normal 'mvn site-deploy' to the un-versioned/latest url once the vote passes (when you merge the staging repo artifacts). It could be done with symlinks on the server or rewrite rules in .htaccess also-- of the two I'd prefer .htaccess because it can be kept in svn. (It's also very easy to break the site with a typo. Not that I'd know...) The implementation doesn't matter too much to me, people who have been doing plugin releases probably have a better idea of the easiest way to do it. Wendy, I agree that having versioned deployments of plugins docs. If we go down this road, we could simply have the unversioned url (eg plugins/maven-whatever-plugin) point to the versioned deployment, rather than redeploying. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugins sandbox site
Hi, was thinking of creating a http://maven.apache.org/plugins/sandbox site to host the docs of the plugins in the maven-sandbox? I've not found any similar site - if so, what is it? If not, any objections to the sandbox site? We could also have it the other way around, ie http://maven.apache.org/sandbox/plugins and allow for other sandbox non-plugin components to have their docs uploaded. Thoughts? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Experiment with GIT
Jason van Zyl wrote: On 30 Sep 07, at 12:23 PM 30 Sep 07, Mauro Talevi wrote: This is a comparison with SVN I've found on the Git site: http://git.or.cz/gitwiki/GitSvnComparsion But one of the main issues IMO is the integration with IDEs - it took quite a long time for SVN to catch up to CVS standards. Until an analogous level is available for Git, how many will be willing to consider trading in the ease of development for the advantages it may offer? We're not going to be using GIT at Apache. In this case it's use GIT versus mail patches. I don't expect a landslide of people using this method, just the most determined and those who understand that using an SCM while working on their changes is a good idea. There is just no way to work like this with SVN, it was just not designed to work like this. Some one who is not a committer cannot incrementally check in their changes so the existing IDE integration doesn't help in this regard. There is someone working on an Eclipse GIT plugin, but anyone wanting to use the standard SVN diff and attach patches to JIRA can continue to do so. It's not like it's one or the other. Well - if the proposal is of an optional layer that sits on top of SVN and provides easy branching for patch submission/tracking, then yes it seems OTOH something really worth exploring. Once the Git infrastructure has been set up I'd be up for taking it for a spin. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
Jesse McConnell wrote: I actually would prefer to have an increased focus on maven and maven2 integration. tbh there are many different continuous integration servers and the ties with maven could be increased some more and leverage some really nice features in maven. I don't really think continuum needs to really try and compete in the shell script launched builds and tying ourselves to these kinda ideas limits the fun things that can be done. with increased maven integration we could integrate build and reporting tools automatically into the builds, just injecting these kinda reports into maven2 projects that are under CI. lots of things possible but increasing the maven2 support just my thoughts :) I'm not saying it should not have strong support and integration with m2. Just that it if Continuum wants to graduate from under the wings of maven umbrella, it should also address the concerns of other build systems. As much as possible try to offer the same feature set to all build tools, but also offer extra functionality leveraging on m2 features where it can. Cheers
Re: [VOTE] Release ArchetypeNG 2.0-alpha-1
Jason van Zyl wrote: On 30 Sep 07, at 12:41 AM 30 Sep 07, Stephane Nicoll wrote: On 9/29/07, Jason van Zyl [EMAIL PROTECTED] wrote: Why, and says who? These things are not cast in stone and we have the ability to adapt the process to make it more productive. [...] I don't really care. Staging a release is not a big deal, just invariably pointless for an alpha because 99% of the time no one will actually do anything with the staged copy. It's more important that the stuff gets cranked out for feedback so it can be fixed. I mean even with releases hardly anyone looks. It's nice idea in theory but if it serves no practical purpose what is the point. I was hopeful that the staged copy would illicit feedback but doesn't seem to have. Not much anyway. I agree with you but, even if those things are not cast in stone, it's commonly used. If we were to adapt for alphas, betas or anything else, I think it makes more sense to discuss it a bit instead of doing it on your side without telling anyone. That's not the first time you're doing this and it's personally confusing to me. All I want is a mechanism that encourages more use in the intermediary stages. It takes more then a week to push out subsequent releases for an alpha, the release plugin gets incrementally worse and has been breaking things on subsequent releases itself because it's not tested enough before pushing it out the door making the whole process more painful. The staging plugin was never meant as a solution and it's not all that great either. We are a project which encourages the use of binaries and agile development. We don't have an easy for people even to test in certain cases. If you start with no local repository and repositories in your settings activated by a profile with repositories it is unworkable. For tools like Archetype where you start with no POM the settings won't be used and there is no way to test it other then to give someone an archive they have to unpack locally or they have to build it themselves. Neither of these options are fantastic. Between our release model taking so long, people historically not looking at releases (which is normal people don't have a lot of spare time to look at everything), our tooling not being quite up to snuff, the staging plugin being a stopgap, and the release plugin breaking things with subsequent releases (though Dan is working on the GPG plugin I see) it becomes very hard to get these changes out to users to utilize and provide feedback. If we don't make this easy, fast and painless for users we lose them. A user having to wait 3 days to try a bug fixed version of an alpha while a developer is focused on it is painful. To be able to release it as it would be used in the wild is the best way. I have three very large clients who are very flexible in that they would try alphas of certainly things in their lifecycle. But they will not build from source, they will not introduce snapshot repositories into their builds in order to consume changes. Build from source is just not an option for a team who is suppose to be consuming this technology. Using snapshot repositories is just too unpredictable given the current mechanism, though I have tried to use them in order to consume changes it's just not practical given the instability so snapshots repositories have been ruled out. The groups that I'm working with cannot be the only groups like this in the world. If more alphas were produced it's very easy with a good parent POM to change the version and attempt using an alpha in a build. I would like to be able to crank out alphas as fast as humanly possible so we stop losing this feedback. I want to make the alpha process less painful for users so that more things are found so that it is possible to have betas that have been suitably tested. This simply is not the case with our plugins because we are missing feedback during the entire span of time between releases. I am pleading with you guys to help not make this process painful, tied down with bureaucracy and get incremental changes out in a usable form which Maven users are accustom to consuming. Building from source and snapshot repositories are just too much to expect from users who are simply trying to verify that issues have been corrected. It is unfortunate that using snapshots it is not clear what you are going to get but that's the situation we have right now and I think we would do ourselves a great service to: 1) Reduce the time required to release alphas i.e. take three +1 votes and kick it out 2) Realize that people do not have a lot of time here and the process of waiting 3 days is not adding much value because I would argue that the second the vote goes up anyone really interested is going to look at it very shortly 3) That in order for changes to be consumed by average users who are willing to give us feed back it has to be easy to use these changes. I
Re: An Experiment with GIT
Jason van Zyl wrote: Hi, For anyone who wants to make changes to Maven but doesn't have access I am going to setup a GIT repository to try and enable some distributed development. After using GIT for about a week I'm having a hard time using SVN but obviously we're not going to be switching anytime soon. But for anyone who has patches or wants to try and work with me to get changes in I am going to try this method of publishing Maven as a GIT repository which will allow anyone to clone the repository and work on any changes you like in a controlled way. Once you clone you can commit changes to your own copy of Maven and do whatever you like. Then in order for me to see your changes I can simply pull from your originally cloned repository to a branch on my side and merge. Merging is sooo easy with GIT. So easy in fact that it makes you wonder how SVN got it so wrong and makes it so painful compared to GIT. This is the model that the Linux kernel uses where anyone has a real copy of the repository, they work as they like, creating branches for features of what have you. I am trying this with Oleg Gusakov who has many ideas and is helping me do some experiments with the artifact resolution system. But anyone else who is interested in trying just let me know. This document is the most helpful: http://utsl.gen.nz/talks/git-svn/intro.html And a little collection of things I have read about GIT: http://del.icio.us/jvanzyl/git It is so damn fast it is unbelievable. With the visual tool that comes with it you can see the entire history of the project in a few minutes. It is very, very cool. I simply cannot believe how easy it is to merge bits from all over the place. My hope is that this method being truly distributed means that people can work on their branches in a way that's natural and we remove the immense tedium working with patches. If you have something good, it's now very easy for me to pull a branch from you and try it. If that branch works it then takes me a second to merge it. I test and them push back to subversion using the git-svn bridge. In the short term I really only want to try with a few people but if you're keen, want to learn about GIT (which I highly, highly recommend) then I will take your patches. I think any developer here and anyone who has ever tried to contribute changes sees that the JIRA+patch model is highly unworkable and bordering on completely useless. JIRA might be fine to raise the issue but with a reference to a GIT repository to pull from it will make life infinitely easier. People who are not committers can work with people that are in a way that resembles everyon being part of the team. Dealing with patches just sucks ass and as a result we don't look at them nearly as often as we should so I hope this can become a model that enables people to contribute in a more effective way. I'm going to try this with Oleg but I am highly hopeful. I will help anyone who wants to try this as I see this as a way to truly collaborate with the community. Down with JIRA+patches! All hail JIRA+GIT! :-) This is a comparison with SVN I've found on the Git site: http://git.or.cz/gitwiki/GitSvnComparsion But one of the main issues IMO is the integration with IDEs - it took quite a long time for SVN to catch up to CVS standards. Until an analogous level is available for Git, how many will be willing to consider trading in the ease of development for the advantages it may offer? Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
Emmanuel Venisse wrote: Hi, At the begin, Continuum was designed to support maven2 projects so we thought it was good to put it under the maven umbrella. But now it supports other project types (ANT, shell scripts) too so it isn't centered on maven projects. An other thing is that we have lot of users (not only maven users) with actually 450 subscribers to the users list, and I think we can get more with a TLP project. My last point is that with the maven project, it isn't easy to add new committers because a new committer have the hand on all maven umbrella code and not only one project. So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. WDYT? +1 for move to TLP, but the project needs to shift its emphasis from maven. Currently the Jira description still states: Continuum is a continuous integration tool designed specifically for use with maven project. It would also be good to have a comparison page with other open-source build tools - eg CruiseControl. Cheers
