Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
I've done something for the javaee6 archetypes at mojo. I suppose you are talking the same problem. Only compilation now, not surefire. It's a solution within current constraints only. When leaving these behind, I would go for endorsed scope. http://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/webapp-javaee6/src/main/resources/archetype-resources/pom.xml Milos On Mon, Nov 9, 2009 at 10:55 PM, Daniel Kulp wrote: > > While at ApacheCon last week, I talked to Jarek Gawor a bit and then > followed > up with a quick conversation with Brett about a problem that is soon going > to > hit CXF/Axis2/Geronimo. > > Basically, we're going to need a mechanism to easily "endorse" a few api > jars > when we call javac and when surefire runs. I'm ok with limiting the > endorsing to when those plugins are in their "fork" mode. There are a few > options that could be pursued: > > 1) Require all developers to drop some jars in jre/lib/endorsed. That > really > sucks. Not exactly viable, IMO. > > 2) Require all devs to copy the jars someplace and add > -Djava.endorsed.dirs=.. > to their MAVEN_OPTS.Also sucks. > > 3) In all modules, configure dependency:copy to copy the artifacts into a > dir > in target, then add the -D thing as system flags for compiler plugin and > surefire. This is better than (2) as it can be all automatic in the poms, > but > it's a ton of configuration if dealing with a lot of poms and projects and > such. > > 4) Add some mechanism to compiler and surefire (and maybe others) to do > some > of (3) automatically. I'm thinking something like: > > > org.apache.maven.plugins >maven-compiler-plugin > > > > ... > ... > > > > > > > and similar configuration for surefire. Maybe make optional and > it > would pick up a version from a dependency. > > 5) Maybe some extension to the ToolChains stuff (which I don't know enough > about, need to dig further if this is viable) to handle this. > > Anyway, does anyone have any other thoughts? > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Proposal after-the-fact: Experimental multithreading support
On Mon, Nov 9, 2009 at 8:02 PM, Dan Fabulich wrote: > I attempted to check in the code in time for 3.0-alpha-3 a few days ago. > That code was rolled back over the weekend and now lives in the MNG-3004 > branch, because it broke integration tests. All integration tests now pass > on my machine with the MNG-3004 branch, so I'd like to land it back in trunk > again and re-cut 3.0-alpha-3 with this additional feature. I think we should let the alpha-3 vote continue as-is with however many months of changes have accumulated, and you can do alpha-4 with this new feature. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven dependency version inprovment
It's not done yet. On Sat, Nov 7, 2009 at 5:38 AM, Gilles Scokart wrote: > 2009/11/6 Stephen Connolly > >> >> I suspect that the plug-ability being introduced in 3.0 will mean that >> we are able to provide a hook for m3 to "discover" how to handle newer >> model versions, so that once m3 is available and widely used, we will >> be able to consider schema changes. >> >> > Is there any page documenting this, or threads discussing that somewhere? > > If that becomes a required step to read correctly a maven repository, I > guess that tools like Apache Ivy or Apache Buildr should be adpated. > > Gilles > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-3
> I haven't tested alpha-3 yet, but I don't want to see anything derail that, > since it's been a long time coming. I think it would be better for issues > found after the last 11 months of changes to be separate from anything > introduced by a multi-threaded build. Agreed. Unless you can attach the new code in such a way that a default of 0 causes the exact old code to run, I think it's too risky. (My assumption on Friday was that this was the case) We've been running the current code and incrementally improving stability, I wouldn't want that thrown out the window with a break in the new code. Having in the trunk for Alpha-4 is going to get plenty of testing prior to a release since we run the trunk at Sonatype for Nexus and on the grid. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-3
On 10/11/2009, at 2:05 PM, Dan Fabulich wrote: I just posted a proposal that the code I checked in before this announcement should make it in to alpha-3. I think if I vote -1 that will veto the release. I don't think that's professional (I did just break the build three days before the release vote, and I'm still quite ashamed by it), so I'll just say -0.9. There's no vetoes on releases. I think we should land the MNG-3004 branch to trunk and cut a new RC for alpha-3. Otherwise, I guess I'll try to kick off an alpha-4 vote shortly after alpha-3, which seems wasteful. Versions are cheap :) I haven't tested alpha-3 yet, but I don't want to see anything derail that, since it's been a long time coming. I think it would be better for issues found after the last 11 months of changes to be separate from anything introduced by a multi-threaded build. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-3
I just posted a proposal that the code I checked in before this announcement should make it in to alpha-3. I think if I vote -1 that will veto the release. I don't think that's professional (I did just break the build three days before the release vote, and I'm still quite ashamed by it), so I'll just say -0.9. I think we should land the MNG-3004 branch to trunk and cut a new RC for alpha-3. Otherwise, I guess I'll try to kick off an alpha-4 vote shortly after alpha-3, which seems wasteful. -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Proposal after-the-fact: Experimental multithreading support
On Friday I was playing cowboy with my experimental thread support, but here's a more formal proposal around parallel project support in Maven 3.0. OUTSTANDING ISSUES In my earlier revision 833566, I attempted to fix MNG-3004: "Allow build lifecycle to execute projects in parallel" http://jira.codehaus.org/browse/MNG-3004 The general consensus around this bug (which has 25 votes) is that multithreading support can't work correctly right now because of MNG-2802: "Concurrent-safe access to local Maven repository" http://jira.codehaus.org/browse/MNG-2802 Several people have remarked in comments to MNG-3004 that it's appropriate to try to fix MNG-3004 (parallel projects) without fixing MNG-2802 (thread-safe local repo). In doing so, we'll allow users to optionally enable building multiple projects simultaneously. This is worth doing, because it can be tested in the wild, and because for some users, it will be immediately useful (e.g. especially if you use --offline mode). I agree with these comments, and attempted to implement them in revision 833566. MY PROPOSAL I attempted to check in the code in time for 3.0-alpha-3 a few days ago. That code was rolled back over the weekend and now lives in the MNG-3004 branch, because it broke integration tests. All integration tests now pass on my machine with the MNG-3004 branch, so I'd like to land it back in trunk again and re-cut 3.0-alpha-3 with this additional feature. As I stated on Friday, using the MNG-3004 branch, you can now do this: mvn install -Dmaven.threads.experimental=4 It works on my machine. If it works for you great; if it doesn't, we can figure out what's wrong together. WHY ALPHA-3? I'd like to land it back in alpha-3 because: * alpha-2 was in February; I don't want to wait for even four months to start testing this in the wild * I did check it in before alpha-3 was released, but it was rolled back quickly before the release vote was called * Otherwise I'd want to try to release alpha-4 immediately after alpha-3, which seems wasteful A NOTE ABOUT DEFAULTS Currently the code defaults to maven.threads.experimental=1. This fires up a single executor thread who does all work; the main thread joins to wait for it to finish. It's also possible to set maven.threads.experimental=0, in which case everything is done on the main thread, just like in alpha-2. If there is consensus, I'd be happy to set the default value to 0, though that increases the risk that the multithreaded code will get less coverage in the wild. I think leaving the value at 1 is a good compromise between avoiding complex threading issues and exercising tricky code. WHAT'S IN THE FUTURE? Post alpha-3 I'm keen on implementing a settings.xml option allowing users to configure their local repository layout. This will allow users to choose an alternate implementation that is thread-safe. Additionally, I think that this feature needs more tooling to make parallel projects understandable. The logger should be enhanced to identify which projects are logging which messages, and the final output of Maven should report more clearly which projects had warning/error messages, and how many such messages were reported. What do you say? -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
9) use a new plugin (let's call it maven-java-plugin) to give us namespacing in the pom. you'd add the plugin to the API pom and its configuration section would annotate the pom with information about what jdk versions the dependency is provided in, what versions it shod be endorsed in, what minimum java version it depends on, etc we'd then provide a component to parse the info for a set of dependencies against a specific toolchain to give, eg endorsed config, filter out unnecessary deps, etc. this would also let us decide on what extended info is needed in pom 5.0.0 Sent from my [rhymes with tryPod] ;-) On 9 Nov 2009, at 22:58, Stephen Connolly > wrote: 2009/11/9 Daniel Kulp : While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. I've already hit some "interesting" poms towards that end of the projects built with maven... though it could be camel, or activemq... whereby the pom "helpfully" adds dependencies when you compile on java 1.5... which is just plain wrong with toolchains in the mix. Basically, we're going to need a mechanism to easily "endorse" a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their "fork" mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. Not a runner, too much will go wrong. 2) Require all devs to copy the jars someplace and add - Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. Not a runner IMHO 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. Ugly, but works right now 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: org.apache.maven.plugins maven-compiler-plugin ... ... and similar configuration for surefire. Maybe make optional and it would pick up a version from a dependency. Might be the easiest way to get this going... but I'd rather get maven-compiler-plugin 2.1 out the door before you go adding it in. and we'd probably run a surefire 2.5 release before too (just to get a baseline, and both of these need releasing. with the maven plugin enforcer we should be ablet to release the core plugins more often) 7) a maven-endorsed-plugin which would hold the configuration of endorsed artifacts, push it into MavenSession and then compiler, surefire, etc could pull the information back out of MavenSession. That would at least reduce the duplication of information... it would also remove the dual-purposing of toolchains 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. I can't see this being as easy. Basically, toolchains gives you a way to define toolchains and to find them again. We could modify the jdk toolchain to allow defining endorsed libs, but it will not do what you are trying to achieve in the "maven" way, i.e. it would require either serious hacks (exposing the artifacts we need as extensions in within the configuration section of mavev-toolchains-plugin), or rolling a custom config for each project (which is just wrong and makes setting up from checkout difficult)... though with the custom plexus reader we could possibly do something whereby you'd have maven-toolchains-plugin 1.5 ... ... ... It would require changing the JDKToolchain impl to pick up the info and not use it for matching the toolchain but instead for populating the toolchain afterwards. I don;t like that I have to type in the dependency information twice though 6) Add a new scope: endorsed Actually there are a number of valid cases where new scopes are needed. It might be no harm to start looking into adding new scopes. IMHO a scope of "endorsed" is the "right" way to solve this problem. I could be convinced that there is a more correct way, but of the solutions on the table, IMHO, this is the best. On the other hand, a scope of "endorsed" smells a bit too close to "system", which we don't want! Plus, there is the prospect of cross-cutting (which we already have), i.e. we have endorsed-compile, endorsed-provided, endorsed-runrtime, endorsed-test-compile, endorsed-test-runtime, etc. It would be good if we could specify multiple scopes in the sc
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
2009/11/9 Daniel Kulp : > > While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed > up with a quick conversation with Brett about a problem that is soon going to > hit CXF/Axis2/Geronimo. I've already hit some "interesting" poms towards that end of the projects built with maven... though it could be camel, or activemq... whereby the pom "helpfully" adds dependencies when you compile on java 1.5... which is just plain wrong with toolchains in the mix. > > Basically, we're going to need a mechanism to easily "endorse" a few api jars > when we call javac and when surefire runs. I'm ok with limiting the > endorsing to when those plugins are in their "fork" mode. There are a few > options that could be pursued: > > 1) Require all developers to drop some jars in jre/lib/endorsed. That really > sucks. Not exactly viable, IMO. Not a runner, too much will go wrong. > > 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. > to their MAVEN_OPTS. Also sucks. Not a runner IMHO > > 3) In all modules, configure dependency:copy to copy the artifacts into a dir > in target, then add the -D thing as system flags for compiler plugin and > surefire. This is better than (2) as it can be all automatic in the poms, but > it's a ton of configuration if dealing with a lot of poms and projects and > such. Ugly, but works right now > > 4) Add some mechanism to compiler and surefire (and maybe others) to do some > of (3) automatically. I'm thinking something like: > > > org.apache.maven.plugins > maven-compiler-plugin > > > > ... > ... > > > > > > > and similar configuration for surefire. Maybe make optional and it > would pick up a version from a dependency. Might be the easiest way to get this going... but I'd rather get maven-compiler-plugin 2.1 out the door before you go adding it in. and we'd probably run a surefire 2.5 release before too (just to get a baseline, and both of these need releasing. with the maven plugin enforcer we should be ablet to release the core plugins more often) 7) a maven-endorsed-plugin which would hold the configuration of endorsed artifacts, push it into MavenSession and then compiler, surefire, etc could pull the information back out of MavenSession. That would at least reduce the duplication of information... it would also remove the dual-purposing of toolchains > > 5) Maybe some extension to the ToolChains stuff (which I don't know enough > about, need to dig further if this is viable) to handle this. > I can't see this being as easy. Basically, toolchains gives you a way to define toolchains and to find them again. We could modify the jdk toolchain to allow defining endorsed libs, but it will not do what you are trying to achieve in the "maven" way, i.e. it would require either serious hacks (exposing the artifacts we need as extensions in within the configuration section of mavev-toolchains-plugin), or rolling a custom config for each project (which is just wrong and makes setting up from checkout difficult)... though with the custom plexus reader we could possibly do something whereby you'd have maven-toolchains-plugin 1.5 ... ... ... It would require changing the JDKToolchain impl to pick up the info and not use it for matching the toolchain but instead for populating the toolchain afterwards. I don;t like that I have to type in the dependency information twice though 6) Add a new scope: endorsed Actually there are a number of valid cases where new scopes are needed. It might be no harm to start looking into adding new scopes. IMHO a scope of "endorsed" is the "right" way to solve this problem. I could be convinced that there is a more correct way, but of the solutions on the table, IMHO, this is the best. On the other hand, a scope of "endorsed" smells a bit too close to "system", which we don't want! Plus, there is the prospect of cross-cutting (which we already have), i.e. we have endorsed-compile, endorsed-provided, endorsed-runrtime, endorsed-test-compile, endorsed-test-runtime, etc. It would be good if we could specify multiple scopes in the scope, e.g. comma/space separated values (given that we are somewhat limited by the pom schema)... but that feels like schema hacking > Anyway, does anyone have any other thoughts? > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > - > 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
endorsing: ToolChain thing or compiler/surefire plugin thing or ....
While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily "endorse" a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their "fork" mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: org.apache.maven.plugins maven-compiler-plugin ... ... and similar configuration for surefire. Maybe make optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-3
+0 (non binding) I'm using m2eclipse from the trunk, using the embedded maven 3 from the trunk, to build several in-house projects. No problems for now 2009/11/9 Arnaud HERITIER : > +1 > Tested with success on several projects > It becomes to be interesting :-) > > Arnaud Héritier > Software Factory Manager > eXo platform - http://www.exoplatform.com > --- > http://www.aheritier.net > > > On Mon, Nov 9, 2009 at 5:44 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> +1 from me >> >> 2009/11/9 Benjamin Bentmann : >> > Hi, >> > >> > OK, here we go, another alpha release of Maven, for all those brave guys >> > that want to take it for a test drive ;-) >> > >> > We solved many issues: >> > >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14719 >> > >> > There are still a couple of issues left in JIRA: >> > >> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 >> > >> > Staging repo: >> > https://repository.apache.org/content/repositories/maven-004/ >> > >> > Staged source and binary distros: >> > >> https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0-alpha-3/ >> > >> > Guide to testing staged releases: >> > http://maven.apache.org/guides/development/guide-testing-releases.html >> > >> > Vote open for 72 hours. >> > >> > [ ] +1 >> > [ ] +0 >> > [ ] -1 >> > >> > +1 from me >> > >> > >> > Benjamim >> > >> > - >> > 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
Re: svn commit: r833566 - in /maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven: execution/MavenSession.java lifecycle/DefaultLifecycleExecutor.java
Benjamin Bentmann wrote: Benjamin Bentmann schrieb: So I wouldn't like to see such experiments on trunk, given we are trying to stabilize it. Hence I created a branch with your changes and reverted them on trunk. In talking with Dan and Wendy on IRC I realized that my immediate reaction of reverting Dan's commit was not the proper way of dealing with this situation. So I would like to apologize for my rude action on this topic. There are apparently emotions on both sides of this story and I hope we can clear this. I also would like to apologize for checking in broken code. I'll attempt to fix my mistake today. Onward! :-) -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r833566 - in /maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven: execution/MavenSession.java lifecycle/DefaultLifecycleExecutor.java
Benjamin Bentmann schrieb: So I wouldn't like to see such experiments on trunk, given we are trying to stabilize it. Hence I created a branch with your changes and reverted them on trunk. In talking with Dan and Wendy on IRC I realized that my immediate reaction of reverting Dan's commit was not the proper way of dealing with this situation. So I would like to apologize for my rude action on this topic. There are apparently emotions on both sides of this story and I hope we can clear this. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-3
+1 Tested with success on several projects It becomes to be interesting :-) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Mon, Nov 9, 2009 at 5:44 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > +1 from me > > 2009/11/9 Benjamin Bentmann : > > Hi, > > > > OK, here we go, another alpha release of Maven, for all those brave guys > > that want to take it for a test drive ;-) > > > > We solved many issues: > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14719 > > > > There are still a couple of issues left in JIRA: > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-004/ > > > > Staged source and binary distros: > > > https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0-alpha-3/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > +1 from me > > > > > > Benjamim > > > > - > > 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] Release Apache Maven 3.0-alpha-3
+1 from me 2009/11/9 Benjamin Bentmann : > Hi, > > OK, here we go, another alpha release of Maven, for all those brave guys > that want to take it for a test drive ;-) > > We solved many issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14719 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-004/ > > Staged source and binary distros: > https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0-alpha-3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > +1 from me > > > Benjamim > > - > 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] Release Apache Maven 3.0-alpha-3
Hi, OK, here we go, another alpha release of Maven, for all those brave guys that want to take it for a test drive ;-) We solved many issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14719 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0-alpha-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamim - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Repository Delegation
Hi All, Maybe this has been discussed (although Google didn't find anything in the archives). What about... a Repository Delegation mechanism, like zone delegation in DNS? IE. the central repo could delegate the com.mycompany group (and all children) to my hosted repo, and I manage whats below that. I dont know the maven internals much, and I haven't really thought much about pros and cons. Just an idea. I see each company configuring repositories as similar to each company managing a /etc/hosts file, or a DNS root. With delegation, I no longer need to configure separate repos, I just ask you nice people to delegate my reverse domain name group to my http:// hosted repo and I'll do the rest from there. Thoughts? Thanks, Jesse - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Experimental multithreading support
Dan, Also curious if you just did this because it was on trunk, or you find working with trunk code easier. On 2009-11-06, at 10:49 PM, Dan Fabulich wrote: In revision 833566, I checked in experimental support for multithreaded builds in Maven 3.0 trunk. This works on my machine: "mvn install -Dmaven.threads.experimental=4" This is a totally naive implementation. It's in no way guaranteed to work. Builder beware. You'd be crazy to use it. But... if you want it... This works on my machine: mvn install -Dmaven.threads.experimental=4 -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Overriding the Default Lifecycle
Is there any way to override the clean lifecycle I have overridden the default lifecycle and it would be useful to add a goal to the pre-clean phase. The pom would be cleaner if I add that in components.xml. thanks
Re: Fix for MRELEASE-415?
You simply have to realize that your priorities are not our priorities and though you have a patch we might all be busy which is generally the case. There are patches available for lots of things, it's still very time consuming to test and I don't see any tests associated with that patch which is one thing that immediately makes me stop looking. I can't speak for the other committers but I consider a patch without tests a halfway complete thing. We know that it's hard to make tests for things like the release plugin, which is why no one has touched the patch. It's not just a simple matter of applying your patch and hoping for the best regardless of how simple it may appear. On 2009-11-09, at 8:50 AM, Reinhard Nägele wrote: I really wonder why none of the committers at least comments on this issue. There is even a patch available. Could this please get some attention? Thanks, Reinhard Hello, Is there a chance that MRELEASE-415 (http://jira.codehaus.org/browse/MRELEASE-415 ) gets fixed any time soon? I provided a patch for the issue quite some time ago. Thanks, Reinhard - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Experimental multithreading support
I think Benjamin already commented on this, but you need to write to keep this on a branch and write a lot of ITs and make sure it all works on the grid before putting this in trunk. It is super, super stable at the moment and we rely on trunk for everything in M2Eclipse so you kill us tossing in half-baked stuff at this point. The multi- threading stuff is awesome but Benjamin has set a new standard for quality and you should respect that. On 2009-11-06, at 10:49 PM, Dan Fabulich wrote: In revision 833566, I checked in experimental support for multithreaded builds in Maven 3.0 trunk. This works on my machine: "mvn install -Dmaven.threads.experimental=4" This is a totally naive implementation. It's in no way guaranteed to work. Builder beware. You'd be crazy to use it. But... if you want it... This works on my machine: mvn install -Dmaven.threads.experimental=4 -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
