Re: [VOTE] Release Maven 3.2.1
Cool. No dire rush. On Feb 16, 2014, at 2:31 PM, Stephen Connolly wrote: > Jason, FYI I intend testing tomorrow AM (GMT). Expect my vote by noon/1pm > GMT > > On Sunday, 16 February 2014, Mirko Friedenhagen > wrote: > >> +1 (non-binding) >> Regards Mirko >> -- >> http://illegalstateexception.blogspot.com/ >> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) >> https://bitbucket.org/mfriedenhagen/ >> >> >> On Sun, Feb 16, 2014 at 10:14 PM, Baptiste Mathus >> > >> wrote: >>> +1 (non-binding). >>> >>> >>> 2014-02-16 4:59 GMT+01:00 Mark Derricutt >>> : >>> +1 here, seems to be working for all my projects. Don't seem to be getting the aether lock up either now, now I'm just suffering version-range hell of mixed feature branches there ( a hell >> of my own making ;p ) Mark On 15 Feb 2014, at 6:58, Jason van Zyl wrote: Specifically the zip, tarball, and source archives can be found here: > https://repository.apache.org/content/repositories/maven- > 1006/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >>> -- >>> Baptiste MATHUS - http://batmat.net >>> Sauvez un arbre, >>> Mangez un castor ! >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > -- > Sent from my phone Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: [VOTE] Release Maven 3.2.1
Jason, FYI I intend testing tomorrow AM (GMT). Expect my vote by noon/1pm GMT On Sunday, 16 February 2014, Mirko Friedenhagen wrote: > +1 (non-binding) > Regards Mirko > -- > http://illegalstateexception.blogspot.com/ > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) > https://bitbucket.org/mfriedenhagen/ > > > On Sun, Feb 16, 2014 at 10:14 PM, Baptiste Mathus > > > wrote: > > +1 (non-binding). > > > > > > 2014-02-16 4:59 GMT+01:00 Mark Derricutt > >: > > > >> +1 here, seems to be working for all my projects. > >> > >> Don't seem to be getting the aether lock up either now, now I'm just > >> suffering version-range hell of mixed feature branches there ( a hell > of my > >> own making ;p ) > >> > >> Mark > >> > >> > >> On 15 Feb 2014, at 6:58, Jason van Zyl wrote: > >> > >> Specifically the zip, tarball, and source archives can be found here: > >>> https://repository.apache.org/content/repositories/maven- > >>> 1006/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > > > -- > > Baptiste MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] Release Maven 3.2.1
+1 (non-binding) Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sun, Feb 16, 2014 at 10:14 PM, Baptiste Mathus wrote: > +1 (non-binding). > > > 2014-02-16 4:59 GMT+01:00 Mark Derricutt : > >> +1 here, seems to be working for all my projects. >> >> Don't seem to be getting the aether lock up either now, now I'm just >> suffering version-range hell of mixed feature branches there ( a hell of my >> own making ;p ) >> >> Mark >> >> >> On 15 Feb 2014, at 6:58, Jason van Zyl wrote: >> >> Specifically the zip, tarball, and source archives can be found here: >>> https://repository.apache.org/content/repositories/maven- >>> 1006/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.2.1
+1 (non-binding). 2014-02-16 4:59 GMT+01:00 Mark Derricutt : > +1 here, seems to be working for all my projects. > > Don't seem to be getting the aether lock up either now, now I'm just > suffering version-range hell of mixed feature branches there ( a hell of my > own making ;p ) > > Mark > > > On 15 Feb 2014, at 6:58, Jason van Zyl wrote: > > Specifically the zip, tarball, and source archives can be found here: >> https://repository.apache.org/content/repositories/maven- >> 1006/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: [VOTE] Maven 2.x is end of life
+1 14. feb. 2014 01:32 skrev "Olivier Lamy" følgende: > +1 > > On 14 February 2014 02:14, Stephen Connolly > wrote: > > We have not made a release of Maven 2.x since 2.2.1 which was August > 2009. > > > > During that period no release manager has stepped up to cut a release. > > > > I would argue that we should just therefore just declare Maven 2.x as end > > of life. > > > > This vote is therefore to resolve this issue. > > > > The vote will be decided on the basis of committer votes cast. If the > > majority of votes from committers (which includes PMC members) are in > > favour then we will declare 2.x end of life. > > > > If you are a committer and voting -1, then we will assume that you are > > willing to step up and act as a release manager to get a 2.2.2 release > out > > (which would hopefully include being able to not barf on > maven-metadata.xml > > that uses the schema generated by Maven 3.x but the > > release manager gets to decide what it is they want to release) > > > > The decision on this is actually quite simple as if there is nobody > > committer to act as a release manager for the 2.x line, then it is end of > > life. > > > > +1: Maven 2.x is end of life, I am not willing to act as release manager > > for this line of releases > > 0: I have no opinion > > -1: Maven 2.x is not end of life, I am willing to act as release manager > > for this line of releases > > > > The vote will be open for 72h and may be closed earlier in the unlikely > > event that all Maven committers have cast a vote before the 72h are up. > > > > -Stephen > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > 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] Maven 2.x is end of life
+1 with a side remark. For those, who still rely on Maven 2 one should first annouce an EOL roadmap like this: 1. Make the announcement 2. Release 2.2.2 (only one open ticket in JIRA which can me dismissed) say 4 weeks later and announce that as the last version of 2.x 3. Encourage to switch to 3.1.x/3.2.x Take Apache Tomcat as an example, they announced 5.5.x as EOL with several months in advance. I think, it's unfair to announce something as EOL straight away. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property anymore?
Hi Jörg, There's a little of confusion here: you're talking about the effective pom, which is the fully resolved pom. However, you seem to be talking about a consumer pom, as we started to call it since our thread about model 5.0.0 [1]. Here we try to make a clear separation between the information to *build* this project and to *use* this project. This separation will give us a chance to upgrade the pom.xml with a list of long standing requests. As long as this is not implemented, we need to thing of another way. Right now the correct way would be: have a Maven Plugin generate the consumer pom.xml and bind it to the Maven Project, probably during the 'package'-phase. This way the rest of the plugins can depend on this new pom.xml, so there's no need to change the maven-install-plugin or maven-deploy-plugin. The problem will be solved "the Maven Way". Control over the pom.xml has been moved from specific parameters for the install and deploy plugin to this single new plugin and has become much more handy (to quote with your own words ;) ). thanks, Robert [1] http://markmail.org/thread/eqsv7pkel5eczndl Op Sun, 16 Feb 2014 16:39:03 +0100 schreef Jörg Hohwiller : Am 04.02.2014 20:42, schrieb Robert Scholte: Hi Jörg, Hi Robert, thanks for your response. if we would change this for the maven-install-plugin, you'll hit it again with the maven-deploy-plugin. I know. The feature also used to work with the older version of maven-deploy-plugin and this would then be my next request. This should indicate there's something wrong with the process. This seems to be the answer I am getting all the time from the maven community. What am I doing wrong? 1. I was asking for a removed feature to come back or some workaround for it. 2. IMHO a build tool should not dictate the process and the philosophy in a way that things get not handy any more. I was describing an actual problem and see a flaw in maven, when you have a large project and want to release parts of the project (not sub-trees but single modules) and you need to maintain the inter-module dependencies and ensure consistent releases. If there is any other solution with maven that I am missing please let me know. Otherwise it would be lovely to hear some constructive suggestion for the problem. I will try to write a MOJO and test if project.setFile will help. Then I can write the minified POM within that MOJO directly as the effective-pom was only a workaround for the actual goal to install and deploy a POM with only the config that is required for runtime. And maybe there are other plugins which expect the same change. Right. maven-gpg-plugin for instance. In my opinion, the pom.xml which is copied/uploaded during the install/deploy should also be the file used to build this project. I think there are 2 solutions: - build the project with the effective pom.xml - let a plugin calculate the effective pom and bind it to the MavenProject These are solid solutions, which ensure that the jar/ear/etc. can really be built with that pom.xml As I already wrote my opinion differs and I want and need to distinguish between information required to tell maven how to build the project and information that is required for deployment and runtime. I do not need to install the effective POM but a POM where dependencies to parent POM, unnecessary indirections (e.g. variables, dependency management, etc.) are stripped off and simplified. Imagine if maven would have been designed this way already, then all the nice features that have been discussed in the last years but have been dropped due to compatibility could have been realized easily. I am aware that there are also features and workflows possible due to the fact that the development configuration can be distributed via a repository but we could have the best of both worlds (e.g. if there is an option to tell maven what you want). FYI: the parameter has been marked as deprecated in favor of the installAtEnd support. Such feature (long standing) in Maven Core would have a huge impact, so by moving it to the plugins we offered a solution which works for the average Maven Project. There are still some rare cases which aren't covered, though. What is the average Maven Project? I always thought Maven is addressed and designed for complex projects. Am I wrong? Thanks, Robert Thanks Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
+1 > Am 13.02.2014 um 16:14 schrieb Stephen Connolly > : > > We have not made a release of Maven 2.x since 2.2.1 which was August 2009. > > During that period no release manager has stepped up to cut a release. > > I would argue that we should just therefore just declare Maven 2.x as end > of life. > > This vote is therefore to resolve this issue. > > The vote will be decided on the basis of committer votes cast. If the > majority of votes from committers (which includes PMC members) are in > favour then we will declare 2.x end of life. > > If you are a committer and voting -1, then we will assume that you are > willing to step up and act as a release manager to get a 2.2.2 release out > (which would hopefully include being able to not barf on maven-metadata.xml > that uses the schema generated by Maven 3.x but the > release manager gets to decide what it is they want to release) > > The decision on this is actually quite simple as if there is nobody > committer to act as a release manager for the 2.x line, then it is end of > life. > > +1: Maven 2.x is end of life, I am not willing to act as release manager > for this line of releases > 0: I have no opinion > -1: Maven 2.x is not end of life, I am willing to act as release manager > for this line of releases > > The vote will be open for 72h and may be closed earlier in the unlikely > event that all Maven committers have cast a vote before the 72h are up. > > -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
On Thu, Feb 13, 2014 at 9:14 AM, Stephen Connolly wrote: > We have not made a release of Maven 2.x since 2.2.1 which was August 2009. > > +1: Maven 2.x is end of life, I am not willing to act as release manager > for this line of releases Here's my +1. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property anymore?
Am 04.02.2014 20:42, schrieb Robert Scholte: Hi Jörg, Hi Robert, thanks for your response. if we would change this for the maven-install-plugin, you'll hit it again with the maven-deploy-plugin. I know. The feature also used to work with the older version of maven-deploy-plugin and this would then be my next request. This should indicate there's something wrong with the process. This seems to be the answer I am getting all the time from the maven community. What am I doing wrong? 1. I was asking for a removed feature to come back or some workaround for it. 2. IMHO a build tool should not dictate the process and the philosophy in a way that things get not handy any more. I was describing an actual problem and see a flaw in maven, when you have a large project and want to release parts of the project (not sub-trees but single modules) and you need to maintain the inter-module dependencies and ensure consistent releases. If there is any other solution with maven that I am missing please let me know. Otherwise it would be lovely to hear some constructive suggestion for the problem. I will try to write a MOJO and test if project.setFile will help. Then I can write the minified POM within that MOJO directly as the effective-pom was only a workaround for the actual goal to install and deploy a POM with only the config that is required for runtime. And maybe there are other plugins which expect the same change. Right. maven-gpg-plugin for instance. In my opinion, the pom.xml which is copied/uploaded during the install/deploy should also be the file used to build this project. I think there are 2 solutions: - build the project with the effective pom.xml - let a plugin calculate the effective pom and bind it to the MavenProject These are solid solutions, which ensure that the jar/ear/etc. can really be built with that pom.xml As I already wrote my opinion differs and I want and need to distinguish between information required to tell maven how to build the project and information that is required for deployment and runtime. I do not need to install the effective POM but a POM where dependencies to parent POM, unnecessary indirections (e.g. variables, dependency management, etc.) are stripped off and simplified. Imagine if maven would have been designed this way already, then all the nice features that have been discussed in the last years but have been dropped due to compatibility could have been realized easily. I am aware that there are also features and workflows possible due to the fact that the development configuration can be distributed via a repository but we could have the best of both worlds (e.g. if there is an option to tell maven what you want). FYI: the parameter has been marked as deprecated in favor of the installAtEnd support. Such feature (long standing) in Maven Core would have a huge impact, so by moving it to the plugins we offered a solution which works for the average Maven Project. There are still some rare cases which aren't covered, though. What is the average Maven Project? I always thought Maven is addressed and designed for complex projects. Am I wrong? Thanks, Robert Thanks Jörg smime.p7s Description: S/MIME Cryptographic Signature
Re: Convert everything to Git
Linking to podcasts and articles is intertresting, especially for those who haven't done it before. What this needs i a volunteer to do the task. K 16. feb. 2014 04:07 skrev "Mark Derricutt" følgende: > A really good podcast on the subject of migration a large project, and > large team from subversion to git can be heard at: > > http://episodes.gitminutes.com/2013/08/gitminutes-20- > mick-wever-on-migrating.html > > Also: > > http://episodes.gitminutes.com/2013/12/gitminutes-26- > campbell-barton-on-tricky.html > > was a very good episode on tricky migrations to git. Recommending > listening for anyone contemplating such a large migration. > > This was a blog post I wrote ages ago on my own svn->git migration: > > http://www.theoryinpractice.net/post/1350252794/ > repository-migration-from-subversion-to-git > > Once I got my workflow down with doing filter-branch's it was reasonably > painless to extract a repository into smaller repositories. Time consuming, > but not t difficult. > > Mark > > > On 14 Feb 2014, at 21:35, Fred Cooke wrote: > > Some of the converters/one of the converters correctly creates git tags >> from svn branches, however I'm unsure what happens if the "tag" has been >> committed to as sometimes happens with n00b devs in SVN land. >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
