Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Jason van Zyl (2012-07-30 17:43:13) On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: The only reason to do this from my PoV is if the plugin requires features only available in Maven 3. There are still a significant number of users who use Maven 2.2.1, yeah I would love to get them to jump up to 3.0.4, but I acknowledge that is something that may be beyond their control. Forcing plugin dependencies up without a valid driving requirement is just forcing unnecessary pain on the end users. IMHO features should drive the upgrading of dependencies, nothing else. +1 There is little value in updating plugins to use Maven 3.x components for the sake of it. The reason we spent so much time making sure that 3.x runs older components was to ensure no one has to do this. Apparently sending out inquiries before leaving for 2 week vacation was not ideal :-) So my view was somewhat different. I would hope you would like to get rid of direct dependencies on old Maven 2.x code. And as you've said Maven 3.x runs older components just fine, so this wouldn't have to be Let's switch tomorrow. Instead it could be a gradual maintenance cleanup. Removing dead and/or unmaintained code. But I understand people using Maven 2.2.1 would be unable to upgrade their dependencies to new versions using Maven 3.x artifacts (or at least it's not a supportable use-case even though it might work). In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Chris Graham (2012-07-30 15:43:31) I work with a lot of older (sometimes out of service software [customers pay a fortune but are prepared to live with it]) so I'm generally a fan of the lowest common denominator. Indeed nothing wrong with it What do you hope to achieve by the? Each released version still using Maven 2.x code prolongs its life. If you never stop supporting it, people will never start moving to new versions :-) I would expect people who want to live with old (or even out-of-service) software don't need (or want) to live with new plugins. Or so I would guess. But I understand they can give you task which requires feature of a new plugin, but new plugin would then need new Maven which they don't want to update not to break their other builds. There are solutions for that though (parallel installation being one) Are there any specific outstanding issues that need this change to solve? Nothing specific, just looking 10 years into the future where Maven 2.x still lives happily. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
On 17 August 2012 11:33, Stanislav Ochotnicky sochotni...@redhat.comwrote: Quoting Jason van Zyl (2012-07-30 17:43:13) On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: The only reason to do this from my PoV is if the plugin requires features only available in Maven 3. There are still a significant number of users who use Maven 2.2.1, yeah I would love to get them to jump up to 3.0.4, but I acknowledge that is something that may be beyond their control. Forcing plugin dependencies up without a valid driving requirement is just forcing unnecessary pain on the end users. IMHO features should drive the upgrading of dependencies, nothing else. +1 There is little value in updating plugins to use Maven 3.x components for the sake of it. The reason we spent so much time making sure that 3.x runs older components was to ensure no one has to do this. Apparently sending out inquiries before leaving for 2 week vacation was not ideal :-) So my view was somewhat different. I would hope you would like to get rid of direct dependencies on old Maven 2.x code. And as you've said Maven 3.x runs older components just fine, so this wouldn't have to be Let's switch tomorrow. Instead it could be a gradual maintenance cleanup. Removing dead and/or unmaintained code. But I understand people using Maven 2.2.1 would be unable to upgrade their dependencies to new versions using Maven 3.x artifacts (or at least it's not a supportable use-case even though it might work). Upgrading dependencies just to force people to upgrade Maven will leave a bad taste in user's mouths. Again, it is *features* that will and must drive the upgrading of dependencies. Where I have a new *feature* that mandates using newer dependencies, then users wanting that feature will have to upgrade to use the new feature. A case in point is some of the experiments I have been working on with regard to handling dynamic changes in a multi-module reactor while running a webapp (like jetty:run or tomcat:run) from that reactor to allow for live development: jszip.org I started off using only Maven 2.2.1 dependencies (because I was requiring Java 1.5 and Maven 2.2.1 is the first recommended version of Maven that mandates Java 1.5+ [2.1.0 and 2.2.0 have critical bugs in signing artifacts for deployment to remote repos and other issues, hence not recommended, and 2.0.11 runs with Java 1.4]) However, I reached a point where, to handle some of the types of model restructuring that takes place when you allow people to edit the pom, I was forced to up the dependencies to Maven 3.0 When I get jszip-maven-plugin to feature complete I suspect/hope that it will be sufficiently compelling that anyone doing webapp development with Maven will *just have to use it* and hence the features it adds will compel people to upgrade to Maven 3.0.4+ A dependency version should be the lowest version that provides compatibility with the latest code and exposes the features you require. If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. Apache releases never die (which is why we cannot stop people (a.k.a. fools) downloading Maven 2.1.0) We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or Maven 4.0 (depends on how big a change we think things are) I would suspect that a 3.1 or 4.0 might consider dropping support for JRE 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain a link to the last version that only requires JRE 1.5 such as we are currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop the 2.0.11 link at that point in time is a different question. The links are there to help users that have specific requirements for Maven versions, but there is absolutely nothing stopping anyone from going and downloading the older versions, e.g. http://archive.apache.org/dist/maven/binaries/ -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
On 17 August 2012 12:32, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On 17 August 2012 11:33, Stanislav Ochotnicky sochotni...@redhat.comwrote: Quoting Jason van Zyl (2012-07-30 17:43:13) On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: The only reason to do this from my PoV is if the plugin requires features only available in Maven 3. There are still a significant number of users who use Maven 2.2.1, yeah I would love to get them to jump up to 3.0.4, but I acknowledge that is something that may be beyond their control. Forcing plugin dependencies up without a valid driving requirement is just forcing unnecessary pain on the end users. IMHO features should drive the upgrading of dependencies, nothing else. +1 There is little value in updating plugins to use Maven 3.x components for the sake of it. The reason we spent so much time making sure that 3.x runs older components was to ensure no one has to do this. Apparently sending out inquiries before leaving for 2 week vacation was not ideal :-) So my view was somewhat different. I would hope you would like to get rid of direct dependencies on old Maven 2.x code. And as you've said Maven 3.x runs older components just fine, so this wouldn't have to be Let's switch tomorrow. Instead it could be a gradual maintenance cleanup. Removing dead and/or unmaintained code. But I understand people using Maven 2.2.1 would be unable to upgrade their dependencies to new versions using Maven 3.x artifacts (or at least it's not a supportable use-case even though it might work). Upgrading dependencies just to force people to upgrade Maven will leave a bad taste in user's mouths. Again, it is *features* that will and must drive the upgrading of dependencies. Where I have a new *feature* that mandates using newer dependencies, then users wanting that feature will have to upgrade to use the new feature. A case in point is some of the experiments I have been working on with regard to handling dynamic changes in a multi-module reactor while running a webapp (like jetty:run or tomcat:run) from that reactor to allow for live development: jszip.org I started off using only Maven 2.2.1 dependencies (because I was requiring Java 1.5 and Maven 2.2.1 is the first recommended version of Maven that mandates Java 1.5+ [2.1.0 and 2.2.0 have critical bugs in signing artifacts for deployment to remote repos and other issues, hence not recommended, and 2.0.11 runs with Java 1.4]) However, I reached a point where, to handle some of the types of model restructuring that takes place when you allow people to edit the pom, I was forced to up the dependencies to Maven 3.0 When I get jszip-maven-plugin to feature complete I suspect/hope that it will be sufficiently compelling that anyone doing webapp development with Maven will *just have to use it* and hence the features it adds will compel people to upgrade to Maven 3.0.4+ A side note is that I hope to expose the features of jszip-maven-plugin as an extension to Maven that other Maven plugins can leverage, in which case even if jszip-maven-plugin is not used by anyone, the API that I hope to develop may well end up widely in use and as different plugin's pick up its features that will drive upgrading. A dependency version should be the lowest version that provides compatibility with the latest code and exposes the features you require. If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. Another point is that Peter Reilly (from Apache ANT) wrote a Jenkins (née Hudson) plugin many years ago which he compiled and ran against version 1.128 or something like that. That plugin *still* works on Jenkins 1.475 unmodified (you just have to compile it with the 1.128 toolchain) That is a successful API In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. Apache releases never die (which is why we cannot stop people (a.k.a. fools) downloading Maven 2.1.0) We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or Maven 4.0 (depends on how big a change we think things are) I would suspect that a 3.1 or 4.0 might consider dropping support for JRE 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain a link to the last version that only requires JRE 1.5 such as we are currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop the 2.0.11 link at that point in time is a different
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
I have 2 remarks to add: 1. even if a plugin has a dependency on an old Maven core artifact, it's at compile time but not runtime: the artifact used at runtime is the artifact from the actual Maven version used, the old artifact isn't even downloaded. Then there is really no problem with plugins using old Maven core artifacts during their compilation 2. even given greatest efforts done, not everything works perfectly with Maven 3: maven-dependency-plugin:tree and maven-project-info-reports- plugin:dependencies used to give sometimes wrong information with Maven 3 until their 2.5 release, which only happened at the beginning of this month (yes, less than one month). AFAIK, these were the last known compatibility problems with Maven 3 by core plugins at Apache. I suppose there are still such problems for some (rare) plugins outside. And users still report some regressions with Maven 3 in advanced situations: once again, they are very rare since there was a huge work to avoid them, but nobody is perfect. Definitely, Maven 3 is the way to go for anybody starting a project today, but we cannot simply drop 2.2.1 today and leave most advanced users with remaining problems: if they cannot upgrade, believe me, that's not because they don't want to or are unable to do the job but because there are still little but very hard to find and fix bugs in Maven 3 or some plugins Regards, Hervé Le vendredi 17 août 2012 12:32:54 Stephen Connolly a écrit : On 17 August 2012 11:33, Stanislav Ochotnicky sochotni...@redhat.comwrote: Quoting Jason van Zyl (2012-07-30 17:43:13) On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: The only reason to do this from my PoV is if the plugin requires features only available in Maven 3. There are still a significant number of users who use Maven 2.2.1, yeah I would love to get them to jump up to 3.0.4, but I acknowledge that is something that may be beyond their control. Forcing plugin dependencies up without a valid driving requirement is just forcing unnecessary pain on the end users. IMHO features should drive the upgrading of dependencies, nothing else. +1 There is little value in updating plugins to use Maven 3.x components for the sake of it. The reason we spent so much time making sure that 3.x runs older components was to ensure no one has to do this. Apparently sending out inquiries before leaving for 2 week vacation was not ideal :-) So my view was somewhat different. I would hope you would like to get rid of direct dependencies on old Maven 2.x code. And as you've said Maven 3.x runs older components just fine, so this wouldn't have to be Let's switch tomorrow. Instead it could be a gradual maintenance cleanup. Removing dead and/or unmaintained code. But I understand people using Maven 2.2.1 would be unable to upgrade their dependencies to new versions using Maven 3.x artifacts (or at least it's not a supportable use-case even though it might work). Upgrading dependencies just to force people to upgrade Maven will leave a bad taste in user's mouths. Again, it is *features* that will and must drive the upgrading of dependencies. Where I have a new *feature* that mandates using newer dependencies, then users wanting that feature will have to upgrade to use the new feature. A case in point is some of the experiments I have been working on with regard to handling dynamic changes in a multi-module reactor while running a webapp (like jetty:run or tomcat:run) from that reactor to allow for live development: jszip.org I started off using only Maven 2.2.1 dependencies (because I was requiring Java 1.5 and Maven 2.2.1 is the first recommended version of Maven that mandates Java 1.5+ [2.1.0 and 2.2.0 have critical bugs in signing artifacts for deployment to remote repos and other issues, hence not recommended, and 2.0.11 runs with Java 1.4]) However, I reached a point where, to handle some of the types of model restructuring that takes place when you allow people to edit the pom, I was forced to up the dependencies to Maven 3.0 When I get jszip-maven-plugin to feature complete I suspect/hope that it will be sufficiently compelling that anyone doing webapp development with Maven will *just have to use it* and hence the features it adds will compel people to upgrade to Maven 3.0.4+ A dependency version should be the lowest version that provides compatibility with the latest code and exposes the features you require. If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition
Optimizing archiver performance by sniffing file headers ?
In the following patch https://github.com/krosenvold/plexus-archiver/commit/e525cf9ad07ef2e96b1c4281945c06e2f59f7d5a I added sniffing of the file ZIP header to the archive function, and if the file being added is already zipped, I store it instead of deflating it in the archive (avoiding recompressing the already compressed file). This doubled the performance of the war plugin on my build. Is there any reason why I can't just make this the default behaviour of the archiver ? (Making your JAR files uncompressed and then the WAR file compressed sounds weird to me...?) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Optimizing archiver performance by sniffing file headers ?
(Making your JAR files uncompressed and then the WAR file compressed sounds weird to me...?) This may actually make sense since zipping an uncompressed ZIP file will be more like tar/gz and will result in better compression performance (because zip dictionaries are contiguous over multiple files). Proof of concept: lucene/ files, zipped (max. compression): 30,535,633 bytes lucene/ files, zipped (no compression): 64,491,998 bytes zipped zip file (no compression): 27,265,084 bytes. It's a compilation time/ size tradeoff in other words. Dawid - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Stephen Connolly (2012-08-17 13:32:54) If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. I honestly didn't mean to make this into fail/win type scenario. In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. Apache releases never die (which is why we cannot stop people (a.k.a. fools) downloading Maven 2.1.0) I'll try to be less metaphorical next time. I meant when they will stop to be supported by their developers. The links are there to help users that have specific requirements for Maven versions, but there is absolutely nothing stopping anyone from going and downloading the older versions, e.g. http://archive.apache.org/dist/maven/binaries/ I am aware of archive, but having download available does not mean that version is alive. Or should I try bugreporting against those old versions? My guess is that those bugs would be just closed as won't fix. So in that sense, I believe 3.x is basically the only alive version of Maven. 2.2.x and 2.0.x branches will likely not receive any security or any major fixes. For you they are done, and there's nothing wrong with that really, but for me it means those versions have no active upstream (pretty please take this with a grain of salt). Hence the curiosity. We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or Maven 4.0 (depends on how big a change we think things are) I would suspect that a 3.1 or 4.0 might consider dropping support for JRE 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain a link to the last version that only requires JRE 1.5 such as we are currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop the 2.0.11 link at that point in time is a different question. OK. I can live with uncertainty and speculations. This is enough for me. Thank you! -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
On Friday, 17 August 2012, Stanislav Ochotnicky wrote: Quoting Stephen Connolly (2012-08-17 13:32:54) If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. I honestly didn't mean to make this into fail/win type scenario. In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. Apache releases never die (which is why we cannot stop people (a.k.a. fools) downloading Maven 2.1.0) I'll try to be less metaphorical next time. I meant when they will stop to be supported by their developers. The links are there to help users that have specific requirements for Maven versions, but there is absolutely nothing stopping anyone from going and downloading the older versions, e.g. http://archive.apache.org/dist/maven/binaries/ I am aware of archive, but having download available does not mean that version is alive. Or should I try bugreporting against those old versions? My guess is that those bugs would be just closed as won't fix. So in that sense, I believe 3.x is basically the only alive version of Maven. 2.2.x and 2.0.x branches will likely not receive any security or any major fixes. For you they are done, and there's nothing wrong with that really, but for me it means those versions have no active upstream (pretty please take this with a grain of salt). Hence the curiosity. Actually there are a number of minor things to do with inter-op which may mean I spin a 2.0.12 and a 2.2.2 (specifically the metadata format change to handle resolving artifacts with classifiers) so not dead yet We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or Maven 4.0 (depends on how big a change we think things are) I would suspect that a 3.1 or 4.0 might consider dropping support for JRE 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain a link to the last version that only requires JRE 1.5 such as we are currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop the 2.0.11 link at that point in time is a different question. OK. I can live with uncertainty and speculations. This is enough for me. Thank you! -- Stanislav Ochotnicky sochotni...@redhat.com javascript:; Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
