Re: Build failed in Jenkins: maven-plugins-ITs-m3 #637
FYI: I'm working on this. Seems I broke the include/exclude rules due my incremental build fixes in combination with the fix for MCOMPILER-120. LieGrue, strub - Original Message - From: Apache Jenkins Server jenk...@builds.apache.org To: notificati...@maven.apache.org; strub...@apache.org; herve.bout...@free.fr; simone.trip...@gmail.com; bimargul...@gmail.com; br...@porterclan.net; stephane.nic...@gmail.com; rfscho...@apache.org; che...@codelutin.com; ol...@apache.org; denn...@apache.org; baerr...@gmail.com; kristian.rosenv...@gmail.com; ltheu...@apache.org Cc: Sent: Tuesday, September 11, 2012 2:43 AM Subject: Build failed in Jenkins: maven-plugins-ITs-m3 #637 See https://builds.apache.org/job/maven-plugins-ITs-m3/637/changes Changes: [struberg] MCOMPILER-21 add documentation for IT [Robert Scholte] Fix MINVOKER-138: Use groovy-all dependency to have xml support [hboutemy] formatting -- [...truncated 9964 lines...] Running org.apache.maven.plugins.shade.mojo.ShadeMojoTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.331 sec Running org.apache.maven.plugins.shade.mojo.RelativizePathTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec Running org.apache.maven.plugins.shade.mojo.ArtifactIdTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.maven.plugins.shade.DefaultShaderTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec Running org.apache.maven.plugins.shade.resource.AppendingTransformerTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformerTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.maven.plugins.shade.resource.XmlAppendingTransformerTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.maven.plugins.shade.resource.ApacheLicenseResourceTransformerTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformerTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec Running org.apache.maven.plugins.shade.filter.SimpleFilterTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.maven.plugins.shade.relocation.SimpleRelocatorParameterTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.maven.plugins.shade.relocation.SimpleRelocatorTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Results : Tests run: 27, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ maven-shade-plugin --- [INFO] Building jar: https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/maven-shade-plugin-2.0.1-SNAPSHOT.jar [INFO] [INFO] --- maven-plugin-plugin:3.1:addPluginArtifactMetadata (default-addPluginArtifactMetadata) @ maven-shade-plugin --- [INFO] [INFO] --- maven-jar-plugin:2.4:test-jar (default) @ maven-shade-plugin --- [INFO] Building jar: https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/maven-shade-plugin-2.0.1-SNAPSHOT-tests.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:install (integration-test) @ maven-shade-plugin --- [INFO] Installing https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/pom.xml to https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/local-repo/org/apache/maven/plugins/maven-shade-plugin/2.0.1-SNAPSHOT/maven-shade-plugin-2.0.1-SNAPSHOT.pom [INFO] Installing https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/maven-shade-plugin-2.0.1-SNAPSHOT.jar to https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/local-repo/org/apache/maven/plugins/maven-shade-plugin/2.0.1-SNAPSHOT/maven-shade-plugin-2.0.1-SNAPSHOT.jar [INFO] Installing https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/maven-shade-plugin-2.0.1-SNAPSHOT-tests.jar to https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/local-repo/org/apache/maven/plugins/maven-shade-plugin/2.0.1-SNAPSHOT/maven-shade-plugin-2.0.1-SNAPSHOT-tests.jar [INFO] [INFO] --- maven-invoker-plugin:1.6:integration-test (integration-test) @ maven-shade-plugin --- [INFO] Building: xml-transformer-ignores-dtd/pom.xml [INFO] run script https://builds.apache.org/job/maven-plugins-ITs-m3/ws/maven-shade-plugin/target/it/xml-transformer-ignores-dtd/verify.bsh [INFO] ..SUCCESS (4.6 s) [INFO] Building: attach-after-lifecycle-fork/pom.xml [INFO] run script
Re: [VOTE] Move Maven projects sources to git
+0 with a long explanation I'm really a friend of GIT in general. As some might remember I am even the guy who kicked off the GIT madness in maven land back in 2007 in the first place [1]. But I'm also a friend of using the right tool for the right job. GIT is great for projects which are not using dynamic modularity, because the concept of 'modules' is almost non-existing in GIT. I think GIT will work fine for maven-core and maven-scm, wagon or surefire which always get released as a whole. I think in those areas it would give us a certain benefit. But GIT sucks a bit when it comes to projects like maven-shared and maven-plugins which get released in portions. We already explained that with long words and we might have found a compromise which doesn't hurt too badly. But still it has to be verified if that works out. When it comes to community building I have my concerns that GIT will be of much benefit. We use GIT very successfully over in Apache DeltaSpike where it is very clear where the cannonical repository lives. If this is clear and all people know where they should get the main stuff from, then GIT is really great. And please forget about pull requests from some unknown github repos. We now count the year 1 after goog-vs-orcl and must really be cautious about intellectual property! This is just not possible because of the legal impacts as github doesnt check an authority of the authors. But here is another example where it did not work out: A few days ago a guy pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ versions around on github and none of them was working correctly. He didn't even know that the original one was still maintained in SVN in codehaus. So we went through all the versions on github and most of them contained different patches. And actually all of them only worked for a very specific situation. There was exactly 0 of them which worked on all 3 last OSX versions! What does this mean? If it's so much easier to make a private clone on github and fix exactly my own problem which I have right now, then this doesn't include feedback from others. And this not only bypasses the community but also confuses others. I'd really appreciate if people would be more careful with their clones and github would introduce a mandatory field [x] my original work [x] original code can be found: but that's another story. My summary: a project of that size is only working if there is a community around it. And whether you like a cannonical repo or not, it to some degrees forces users to talk with each others and give feedback! LieGrue, strub [1] https://github.com/struberg/maven-scm-providers-git/commit/e670863b2b03e158c59f34af1fee20f91b2bd852 - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Wednesday, September 5, 2012 1:04 PM Subject: [VOTE] Move Maven projects sources to git Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Dynamically determining the currently executing goal name
Add following member to your Mojo and inspect what is injected:
/**
* Mojo execution.
*
* @parameter default-value=${mojoExecution}
* @required
* @readonly
*/
private org.apache.maven.plugin.MojoExecution mojoExecution;
Hope helps,
~t~
On Mon, Sep 10, 2012 at 6:59 PM, Jeff Maxwell jeff.maxw...@gmail.comwrote:
I would like to dynamically determine the currently executing goal from a
MOJO.
I attempted this using reflection but the new annotations are not available
at runtime.
All other solutions I have seen appear to require access to the executing
MOJO's groupId and artifactId.
Anyone have a solution?
Is there an issue with having the annotations available at runtime?
--
View this message in context:
http://maven.40175.n5.nabble.com/Dynamically-determining-the-currently-executing-goal-name-tp5721050.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
+1 Emmanuel On Wed, Sep 5, 2012 at 1:04 PM, Olivier Lamy ol...@apache.org wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
On Tue, Sep 11, 2012 at 3:19 AM, Anders Hammar and...@hammar.net wrote: Switch to Maven 3 and this should work. Try it and report back! I did and it did. /Anders On Mon, Sep 10, 2012 at 11:22 PM, David Jencks david_jen...@yahoo.com wrote: Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: the simplest possible maven plugin, sort of
In Flexmojos you have to run the build twice (The first with minimal profile turned on), because otherwise maven will complain about the plugin not being available. As soon as there is any artifact with that name I am able to build with only one run, because the build replaces/updates the plugin in my repo and from then on the updated plugin is used. So I think you are all right. Chris -Ursprüngliche Nachricht- Von: Benson Margulies [mailto:bimargul...@gmail.com] Gesendet: Dienstag, 11. September 2012 12:17 An: Maven Developers List Betreff: Re: the simplest possible maven plugin, sort of On Tue, Sep 11, 2012 at 3:19 AM, Anders Hammar and...@hammar.net wrote: Switch to Maven 3 and this should work. Try it and report back! I did and it did. /Anders On Mon, Sep 10, 2012 at 11:22 PM, David Jencks david_jen...@yahoo.com wrote: Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven SCM Publish Plugin beta-1
Hi, I'd like to release Apache Maven SCM Publish Plugin beta-1. The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM As all ASF projects must move to svnpubsub for the end year, this plugin will help some ASF projects. Currently no Jira as it's the first release (I will create one) Staging repository: https://repository.apache.org/content/repositories/maven-050/ Staging documentation: http://maven.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/maven-scm-publish-plugin/ Vote open for 72H [+1] [0] [-1] -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM Publish Plugin beta-1
On Tue, 11 Sep 2012 13:38:40 +0200 Olivier Lamy ol...@apache.org wrote: +1 Note that the maven project logo is missing on generated site, what a shame :D thanks, tony Hi, I'd like to release Apache Maven SCM Publish Plugin beta-1. The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM As all ASF projects must move to svnpubsub for the end year, this plugin will help some ASF projects. Currently no Jira as it's the first release (I will create one) Staging repository: https://repository.apache.org/content/repositories/maven-050/ Staging documentation: http://maven.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/maven-scm-publish-plugin/ Vote open for 72H [+1] [0] [-1] -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM Publish Plugin beta-1
2012/9/11 Tony Chemit che...@codelutin.com: On Tue, 11 Sep 2012 13:38:40 +0200 Olivier Lamy ol...@apache.org wrote: +1 Note that the maven project logo is missing on generated site, what a shame :D Hehe. Note the test with using the svnpubsub mechanism: http://maventest.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/ :P thanks, tony Hi, I'd like to release Apache Maven SCM Publish Plugin beta-1. The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM As all ASF projects must move to svnpubsub for the end year, this plugin will help some ASF projects. Currently no Jira as it's the first release (I will create one) Staging repository: https://repository.apache.org/content/repositories/maven-050/ Staging documentation: http://maven.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/maven-scm-publish-plugin/ Vote open for 72H [+1] [0] [-1] -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
But GIT sucks a bit when it comes to projects like maven-shared and maven-plugins which get released in portions. We already explained that with long words and we might have found a compromise which doesn't hurt too badly. But still it has to be verified if that works out. Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard. We now count the year 1 after goog-vs-orcl and must really be cautious about intellectual property! How is accepting a patch in Jira from user fuzzyBear without any further credentials attached (and no visible identification of a real or imagined person) different form a github pull request ? So while I agree about being careful about IP, i can't see our current regime being a bit different from github. You may argue that we'd want to tighten this, but this is the current reality for over 1 million committs. I have no idea of how many John Smith accounts there are in our jira, but we pretend to ignore the fact. But here is another example where it did not work out: A few days ago a guy pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ versions around on github and none of them was working correctly. He didn't even know that the original one was still maintained in SVN in codehaus. So we went through all the versions on github and most of them contained different patches. And actually all of them only worked for a very specific situation. There was exactly 0 of them which worked on all 3 last OSX versions! What does this mean? It means you can't ignore your community and not maintain software when you're on git. But git has opened this entry point no matter what, it's like a box that's been opened for the whole community and there's no way back on that. The exclusive modification right that svn commit bit used to mean is gone. Once you learn to maintain a git fork you can permanently maintain a fork much simpler than before. It's actually something I think we should embrace, not frown upon. On my last project, we had *permanent* forks of three major frameworks that git allowed us to rebase and maintain with minimal or no effort. Characteristic of these patches were that A) we had submitted them but they were rejected B) we were invested in deprecated stuff that the communit weren't maintaing any more C) it was simply not of a quality that would be accepted Looking blindly at the github network graph does not give you this story, and it's like there's a whole new world of options available to OSS users. The act of submitting a patch (=pull request) simply means the creator of the patch is interested in submitting. The fact that I can browse all kinds of different hacks people have applied to my code does not really mean they are submitted or intended for submission. Combined with mailing list issue tracker activity, the stuff going on at github /is/ your community. If you see something cool in a branch on github, just add a comment requesting the author to submit this as a patch (or pull request if you permit it). If we can't accept pull requests we'll just have to do some other cool hack. Maybe we could write github plugin that could auto-submit a jira ;) It's all options, and we decide Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
well, for gods sake and (and for the peace of the bits on my ssd) I move my vote to +1 as well LieGrue, strub - Original Message - From: Kristian Rosenvold kristian.rosenv...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Tuesday, September 11, 2012 2:13 PM Subject: Re: [VOTE] Move Maven projects sources to git But GIT sucks a bit when it comes to projects like maven-shared and maven-plugins which get released in portions. We already explained that with long words and we might have found a compromise which doesn't hurt too badly. But still it has to be verified if that works out. Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard. We now count the year 1 after goog-vs-orcl and must really be cautious about intellectual property! How is accepting a patch in Jira from user fuzzyBear without any further credentials attached (and no visible identification of a real or imagined person) different form a github pull request ? So while I agree about being careful about IP, i can't see our current regime being a bit different from github. You may argue that we'd want to tighten this, but this is the current reality for over 1 million committs. I have no idea of how many John Smith accounts there are in our jira, but we pretend to ignore the fact. But here is another example where it did not work out: A few days ago a guy pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ versions around on github and none of them was working correctly. He didn't even know that the original one was still maintained in SVN in codehaus. So we went through all the versions on github and most of them contained different patches. And actually all of them only worked for a very specific situation. There was exactly 0 of them which worked on all 3 last OSX versions! What does this mean? It means you can't ignore your community and not maintain software when you're on git. But git has opened this entry point no matter what, it's like a box that's been opened for the whole community and there's no way back on that. The exclusive modification right that svn commit bit used to mean is gone. Once you learn to maintain a git fork you can permanently maintain a fork much simpler than before. It's actually something I think we should embrace, not frown upon. On my last project, we had *permanent* forks of three major frameworks that git allowed us to rebase and maintain with minimal or no effort. Characteristic of these patches were that A) we had submitted them but they were rejected B) we were invested in deprecated stuff that the communit weren't maintaing any more C) it was simply not of a quality that would be accepted Looking blindly at the github network graph does not give you this story, and it's like there's a whole new world of options available to OSS users. The act of submitting a patch (=pull request) simply means the creator of the patch is interested in submitting. The fact that I can browse all kinds of different hacks people have applied to my code does not really mean they are submitted or intended for submission. Combined with mailing list issue tracker activity, the stuff going on at github /is/ your community. If you see something cool in a branch on github, just add a comment requesting the author to submit this as a patch (or pull request if you permit it). If we can't accept pull requests we'll just have to do some other cool hack. Maybe we could write github plugin that could auto-submit a jira ;) It's all options, and we decide Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
+1, and I'm willing to volunteer if you still need more people. On 09/05/2012 06:04 AM, Olivier Lamy wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
On 09/11/2012 07:13 AM, Kristian Rosenvold wrote: But GIT sucks a bit when it comes to projects like maven-shared and maven-plugins which get released in portions. We already explained that with long words and we might have found a compromise which doesn't hurt too badly. But still it has to be verified if that works out. Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard. I would vote for just splitting the Maven plugins into separate git repos. I normally don't find myself needing to checkout/build/work on multiple plugins at once, so giving them each a separate lifecycle would be fine, IMO. But we could probably leave these migrations for later after we migrate Maven core and some of the other more monolithic projects. We now count the year 1 after goog-vs-orcl and must really be cautious about intellectual property! How is accepting a patch in Jira from user fuzzyBear without any further credentials attached (and no visible identification of a real or imagined person) different form a github pull request ? So while I agree about being careful about IP, i can't see our current regime being a bit different from github. You may argue that we'd want to tighten this, but this is the current reality for over 1 million committs. I have no idea of how many John Smith accounts there are in our jira, but we pretend to ignore the fact. I agree, if anything git patches give us a bit more protection regarding IP because it tracks the name and email of the author. In addition, we could make it our policy to not accept patches in git that don't appear to have a valid author name and email. But here is another example where it did not work out: A few days ago a guy pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ versions around on github and none of them was working correctly. He didn't even know that the original one was still maintained in SVN in codehaus. So we went through all the versions on github and most of them contained different patches. And actually all of them only worked for a very specific situation. There was exactly 0 of them which worked on all 3 last OSX versions! What does this mean? It means you can't ignore your community and not maintain software when you're on git. But git has opened this entry point no matter what, it's like a box that's been opened for the whole community and there's no way back on that. The exclusive modification right that svn commit bit used to mean is gone. Once you learn to maintain a git fork you can permanently maintain a fork much simpler than before. It's actually something I think we should embrace, not frown upon. On my last project, we had *permanent* forks of three major frameworks that git allowed us to rebase and maintain with minimal or no effort. Characteristic of these patches were that A) we had submitted them but they were rejected B) we were invested in deprecated stuff that the communit weren't maintaing any more C) it was simply not of a quality that would be accepted Looking blindly at the github network graph does not give you this story, and it's like there's a whole new world of options available to OSS users. The act of submitting a patch (=pull request) simply means the creator of the patch is interested in submitting. The fact that I can browse all kinds of different hacks people have applied to my code does not really mean they are submitted or intended for submission. Combined with mailing list issue tracker activity, the stuff going on at github /is/ your community. If you see something cool in a branch on github, just add a comment requesting the author to submit this as a patch (or pull request if you permit it). If we can't accept pull requests we'll just have to do some other cool hack. Maybe we could write github plugin that could auto-submit a jira ;) It's all options, and we decide Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
Changing my vote to +1 based on Kristian and Mark's recent exchanges. Wayne On Thu, Sep 6, 2012 at 11:28 AM, Wayne Fay wayne...@gmail.com wrote: [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) +0.5 Sorry but I will be no help, I have little git experience except as an end user. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM Publish Plugin beta-1
+1, just tested it now to deploy Archiva's site :) Also verified that the signatures and checksums of the artifacts are correct. Thanks, Deng On Tue, Sep 11, 2012 at 7:38 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven SCM Publish Plugin beta-1. The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM As all ASF projects must move to svnpubsub for the end year, this plugin will help some ASF projects. Currently no Jira as it's the first release (I will create one) Staging repository: https://repository.apache.org/content/repositories/maven-050/ Staging documentation: http://maven.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/maven-scm-publish-plugin/ Vote open for 72H [+1] [0] [-1] -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM Publish Plugin beta-1
+1 Regards, Hervé Le mardi 11 septembre 2012 13:38:40 Olivier Lamy a écrit : Hi, I'd like to release Apache Maven SCM Publish Plugin beta-1. The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM As all ASF projects must move to svnpubsub for the end year, this plugin will help some ASF projects. Currently no Jira as it's the first release (I will create one) Staging repository: https://repository.apache.org/content/repositories/maven-050/ Staging documentation: http://maven.apache.org/plugins/maven-scm-publish-plugin-1.0-beta-1/maven-sc m-publish-plugin/ Vote open for 72H [+1] [0] [-1] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
I don't think it's IF we should move to git, but WHEN and now seems to be the right time. +1 Robert Op Tue, 11 Sep 2012 14:49:46 +0200 schreef Paul Gier pg...@redhat.com: +1, and I'm willing to volunteer if you still need more people. On 09/05/2012 06:04 AM, Olivier Lamy wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
I'm +1 On Tue, Sep 11, 2012 at 1:39 PM, Robert Scholte rfscho...@apache.orgwrote: I don't think it's IF we should move to git, but WHEN and now seems to be the right time. +1 Robert Op Tue, 11 Sep 2012 14:49:46 +0200 schreef Paul Gier pg...@redhat.com: +1, and I'm willing to volunteer if you still need more people. On 09/05/2012 06:04 AM, Olivier Lamy wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Dynamically determining the currently executing goal name
This works fine:
/** The project. */
@Parameter(required = true, readonly = true, defaultValue =
${mojoExecution})
private MojoExecution mojoExecution;
@Override
public String getGoalName() {
return this.mojoExecution.getMojoDescriptor().getGoal();
}
It was a bit of effort to get it to work with AbstractMojoTestCase but
not too bad.
Thanks!
--
View this message in context:
http://maven.40175.n5.nabble.com/Dynamically-determining-the-currently-executing-goal-name-tp5721050p5721312.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Changes Plugin version 2.8
Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212styleName=Htmlversion=18484 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11212status=1 Staging repo: https://repository.apache.org/content/repositories/maven-053/ https://repository.apache.org/content/repositories/maven-053/org/apache/maven/plugins/maven-changes-plugin/2.8/maven-changes-plugin-2.8-source-release.zip Staging site (wait for the sync): http://maven.apache.org/plugins/maven-changes-plugin-2.8/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.8
+1 Regards, Hervé Le mardi 11 septembre 2012 21:55:16 Dennis Lundberg a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212styleName=H tmlversion=18484 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11212sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-053/ https://repository.apache.org/content/repositories/maven-053/org/apache/mave n/plugins/maven-changes-plugin/2.8/maven-changes-plugin-2.8-source-release.z ip Staging site (wait for the sync): http://maven.apache.org/plugins/maven-changes-plugin-2.8/ 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins build is back to normal : maven-plugins-ITs-m3 #641
yeah! Le mardi 11 septembre 2012 21:44:33 vous avez écrit : See https://builds.apache.org/job/maven-plugins-ITs-m3/641/changes - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-scm pull request: Fix for SCM-694
GitHub user fcamblor opened a pull request: https://github.com/apache/maven-scm/pull/3 Fix for SCM-694 Here is a pull request fixing SCM-694 (renamed files not handled during git commit) You can merge this pull request into a Git repository by running: $ git pull https://github.com/fcamblor/maven-scm SCM-694 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-scm/pull/3.patch commit b80ecb71ef9081e23742401076f147d3f4b75cf9 Author: Frédéric Camblor fcamb...@gmail.com Date: 2012-09-11T15:39:43-07:00 Added tests reproducing SCM-694 commit d8da38d5a320c25b645d792f74882a92e379adf0 Author: Frédéric Camblor fcamb...@gmail.com Date: 2012-09-11T16:08:00-07:00 Fix for SCM-694 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
