Re: RPMs for Maven 3?
On 23/03/2012, at 2:43 AM, Stanislav Ochotnicky wrote: Quoting Brett Porter (2012-03-21 21:06:05) http://svn.apache.org/repos/asf/maven/sandbox/trunk/rpm $ mvn install $ sudo rpm -ivh ~/.m2/repository/org/apache/maven/rpm/maven/3.0.4/maven-3.0.4.rpm Tested on CentOS 6.0. It installs to /usr/local/maven and /usr/local/bin/mvn. It also adds /etc/profile.d/maven.sh to add the bin directory to the PATH and M2_HOME variable, though neither are strictly necessary. Open to suggestions on improvements. I've had a look at the produced spec file and file layout and I do have a few suggestions: 1. Put maven into /usr/share/maven instead of /usr/local/maven. Or if you really want to put it into /usr/local subtree then /usr/local/share/maven. /usr/local/maven is...at least weird from FHS perspective. And then just symlink scripts into /usr/[local/]bin. 2. Your license tag doesn't state license, just copyright. In most RPM Linux distributions this would probably contain ASL 2.0. Full license name would be OK as well I guess 3. URL should probably be maven.apache.org instead of plain apache.org 4. Put settings.xml into /etc/ subtree (/etc/maven/ possibly) and symlink it back to M2_HOME (possibly same thing for m2.conf). It should also be marked as config file. 5. Handling of license/readme etc is different on different distros so I guess that can stay inside M2_HOME 6. A nice sensible %description copied from main site would be nice :-) These all sound like good changes to me - I'll have a look when I can, or if you want to patch it please do! I removed and requirement on a JDK package, to avoid requiring one alternative over another. Open to suggestions if there is a better way to express that in the spec file. 7. I have asked around a bit and it might make sense to add Requires: java (or java-devel) to the resulting RPM/spec. It would work at least on Fedora/SuSE/Mageia stack I would assume that works as well. But proprietary Oracle JDK rpm doesn't have this provides so it means we'd still pull in additional jdk. Oh well.. I see a lot of hosts with the Oracle RPMs on there, so it seems better to omit rather than force someone to use --nodeps or double up, IMO. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Quoting Brett Porter (2012-03-21 21:06:05) http://svn.apache.org/repos/asf/maven/sandbox/trunk/rpm $ mvn install $ sudo rpm -ivh ~/.m2/repository/org/apache/maven/rpm/maven/3.0.4/maven-3.0.4.rpm Tested on CentOS 6.0. It installs to /usr/local/maven and /usr/local/bin/mvn. It also adds /etc/profile.d/maven.sh to add the bin directory to the PATH and M2_HOME variable, though neither are strictly necessary. Open to suggestions on improvements. I've had a look at the produced spec file and file layout and I do have a few suggestions: 1. Put maven into /usr/share/maven instead of /usr/local/maven. Or if you really want to put it into /usr/local subtree then /usr/local/share/maven. /usr/local/maven is...at least weird from FHS perspective. And then just symlink scripts into /usr/[local/]bin. 2. Your license tag doesn't state license, just copyright. In most RPM Linux distributions this would probably contain ASL 2.0. Full license name would be OK as well I guess 3. URL should probably be maven.apache.org instead of plain apache.org 4. Put settings.xml into /etc/ subtree (/etc/maven/ possibly) and symlink it back to M2_HOME (possibly same thing for m2.conf). It should also be marked as config file. 5. Handling of license/readme etc is different on different distros so I guess that can stay inside M2_HOME 6. A nice sensible %description copied from main site would be nice :-) I removed and requirement on a JDK package, to avoid requiring one alternative over another. Open to suggestions if there is a better way to express that in the spec file. 7. I have asked around a bit and it might make sense to add Requires: java (or java-devel) to the resulting RPM/spec. It would work at least on Fedora/SuSE/Mageia stack I would assume that works as well. But proprietary Oracle JDK rpm doesn't have this provides so it means we'd still pull in additional jdk. Oh well.. All in all seems we've both chosen to produce rpms of maven. I've taken the approach from RPM side and you from Maven side, both producing workable RPMS. Your approach could work in Jenkins more easily I guess to produce new builds of maven. By the time I got here I realized I could have just prepared a patch for your pom.xml instead of writing all this :-/ Anyway, I if you want to help with this feel free to get in touch off-list and I'll help when I can. If nothing else I believe I have pretty good idea what Linux distributions prefer/expect when dealing with rpms. On 22/03/2012, at 6:29 AM, Brett Porter wrote: On 22/03/2012, at 1:01 AM, Brian Fox wrote: Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? We've had one at MaestroDev for a while. I'll clean it up, give it a spin, and put it in the sandbox. Interested users can at least build their own then. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- 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: RPMs for Maven 3?
This is all really great. Now we just need sensibly designed deb like. I believe Tim did something like that in the past which could be the start for it http://discursive.com/2011/04/21/installing-maven-3-from-a-binary-deb-on-ubuntu/ manfred On 12-03-22 08:43 AM, Stanislav Ochotnicky wrote: Quoting Brett Porter (2012-03-21 21:06:05) http://svn.apache.org/repos/asf/maven/sandbox/trunk/rpm $ mvn install $ sudo rpm -ivh ~/.m2/repository/org/apache/maven/rpm/maven/3.0.4/maven-3.0.4.rpm Tested on CentOS 6.0. It installs to /usr/local/maven and /usr/local/bin/mvn. It also adds /etc/profile.d/maven.sh to add the bin directory to the PATH and M2_HOME variable, though neither are strictly necessary. Open to suggestions on improvements. I've had a look at the produced spec file and file layout and I do have a few suggestions: 1. Put maven into /usr/share/maven instead of /usr/local/maven. Or if you really want to put it into /usr/local subtree then /usr/local/share/maven. /usr/local/maven is...at least weird from FHS perspective. And then just symlink scripts into /usr/[local/]bin. 2. Your license tag doesn't state license, just copyright. In most RPM Linux distributions this would probably contain ASL 2.0. Full license name would be OK as well I guess 3. URL should probably be maven.apache.org instead of plain apache.org 4. Put settings.xml into /etc/ subtree (/etc/maven/ possibly) and symlink it back to M2_HOME (possibly same thing for m2.conf). It should also be marked as config file. 5. Handling of license/readme etc is different on different distros so I guess that can stay inside M2_HOME 6. A nice sensible %description copied from main site would be nice :-) I removed and requirement on a JDK package, to avoid requiring one alternative over another. Open to suggestions if there is a better way to express that in the spec file. 7. I have asked around a bit and it might make sense to add Requires: java (or java-devel) to the resulting RPM/spec. It would work at least on Fedora/SuSE/Mageia stack I would assume that works as well. But proprietary Oracle JDK rpm doesn't have this provides so it means we'd still pull in additional jdk. Oh well.. All in all seems we've both chosen to produce rpms of maven. I've taken the approach from RPM side and you from Maven side, both producing workable RPMS. Your approach could work in Jenkins more easily I guess to produce new builds of maven. By the time I got here I realized I could have just prepared a patch for your pom.xml instead of writing all this :-/ Anyway, I if you want to help with this feel free to get in touch off-list and I'll help when I can. If nothing else I believe I have pretty good idea what Linux distributions prefer/expect when dealing with rpms. On 22/03/2012, at 6:29 AM, Brett Porter wrote: On 22/03/2012, at 1:01 AM, Brian Fox wrote: Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? We've had one at MaestroDev for a while. I'll clean it up, give it a spin, and put it in the sandbox. Interested users can at least build their own then. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Thu, Mar 22, 2012 at 9:38 AM, Manfred Moser manf...@mosabuam.com wrote: This is all really great. Now we just need sensibly designed deb like. I believe Tim did something like that in the past which could be the start for it Yes, this is looking great! Thanks for working on this, gentlemen! Cheers, Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Agh ok, I only read the sentence at the top not the see more below... Somebody should fix that as the top section makes it seem the way I thought esp the way it calls it out, On Wednesday, 21 March 2012, Ralph Goers ralph.go...@dslextreme.com wrote: On Mar 20, 2012, at 5:23 PM, Stephen Connolly wrote: Actually -1 votes don't count. You cannot veto releases, you only need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release manager is still allowed to proceed with the release! [It would be bad form to proceed from my PoV, but the rules allow it] Stephen, This is absolutely incorrect. Please re-read http://www.apache.org/foundation/voting.html and you will see you need more +1's than -1's. Ralph
Re: RPMs for Maven 3?
Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? It seems like this would be the best of both worlds. Hardly anything ever changes in the package, people get easy access to sudo apt get install/upgrade maven and there isn't a big concern about this bundle being a different beast entirely. I realize this suggestion might be blasphemy in some circles because it isn't built again from scratch, yada yada, but it seems like the hurdle that needs to be solved is simply download and untar the bundle and set the path and env, and this has nothing to do with rebuilding and tweaking the package. my .02 On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to
Re: RPMs for Maven 3?
On 22/03/2012, at 1:01 AM, Brian Fox wrote: Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? We've had one at MaestroDev for a while. I'll clean it up, give it a spin, and put it in the sandbox. Interested users can at least build their own then. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
http://svn.apache.org/repos/asf/maven/sandbox/trunk/rpm $ mvn install $ sudo rpm -ivh ~/.m2/repository/org/apache/maven/rpm/maven/3.0.4/maven-3.0.4.rpm Tested on CentOS 6.0. It installs to /usr/local/maven and /usr/local/bin/mvn. It also adds /etc/profile.d/maven.sh to add the bin directory to the PATH and M2_HOME variable, though neither are strictly necessary. Open to suggestions on improvements. I removed and requirement on a JDK package, to avoid requiring one alternative over another. Open to suggestions if there is a better way to express that in the spec file. Cheers, Brett On 22/03/2012, at 6:29 AM, Brett Porter wrote: On 22/03/2012, at 1:01 AM, Brian Fox wrote: Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? We've had one at MaestroDev for a while. I'll clean it up, give it a spin, and put it in the sandbox. Interested users can at least build their own then. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On 21/03/2012, at 8:54 AM, Stephen Connolly wrote: My point is that even if you were a committer, the Apache by-laws state that the PMC must vote at least 3 x +1 to release a binary, so if you cannot find 3 of the current 24 who are even willing to consider voting on RPMs then you are not going to get binary RPMs released, not because we don't want to, or because we think they are pointless, etc... no simply because of the rules that govern the Apache release process. Some clarification is needed here. First, the bylaws say nothing about releases, project voting procedures, or anything on the technical side of the foundation for that matter :) You're thinking of the release policy: http://www.apache.org/dev/release.html The only thing a vote is about is the source code. What binary packages we distribute from that is a matter for what we are comfortable will have had enough testing and support. To illustrate: I guarantee there are not 3 people on each vote that have checked all 3 binary tarballs/zips unpack and run, let alone tested it across different platforms. Note that some projects don't ship binaries at all, for example Subversion lets others make their RPMs: http://subversion.apache.org/packages.html The main hassle in producing an RPM is that it constrains where the build environment can be. I'm fine with us producing it for releases if someone does it as a separate process along with, or after the success of, the release vote. That gets back to the main point you and others are making though - whether we do that is a matter for if we are comfortable it'll be suitably tested, and we can support it - particularly keeping in mind how it might conflict with packages from particular distros. I guess the upside is that it might help encourage distros to follow a more consistent layout. On that point, I'm happy either way. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
- Original Message - From: Manfred Moser manf...@mosabuam.com To: dev@maven.apache.org Sent: Tuesday, March 20, 2012 12:32:26 AM Subject: Re: RPMs for Maven 3? Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Well, this is misleading information. We (Fedora Java team): * no longer ship Maven 2, thus aggressively forcing people onto Maven 3 * actively port away from outdated libs (e.g. check Maven/Mojo jiras for porting away from plexus-maven-plugin to plexus-component-metadaat). FWIW a number of these (PLXCOMP-186,PLXCOMP-187, PLXCOMP-188, WAGON-345, MRELEASE-703, MCHANGES-264, MNGECLIPSE-676, MASSEMBLY-564) contain patches waiting to be integrated for more than half a year. * actively port and help third party projects to build properly with Maven 3 This might not be true for all OSes. And while I can agree that there might be different views on certain things we do our best to improve the whole stack but if our non-controversial(at least my opinion) patches stay like this and noone pays attention this doesn't help collaboration either. So can we try to collaborate more? There are a number of similar issues we have done which haven't been upstreamed because people start to think why bother opening jiras if noone cares. To get back to the slow uptake - every OS has it's target audience - much in the same way every build system has it's target audience so let's not say that all OS are holding back updates because some OS push to the maximum for getting things uptodate. Alex manfred On 12-03-19 02:57 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 2:20 PM, Benson Marguliesbimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 5:08 PM, Jos Backusj...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zylja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zylja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. I would just leave it out of the package altogether. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log,cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. Who cares if they reject it, if they are not offering anything better. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. Well, what scales better: packagers associated with a single distro trying to package thousands of packages, or packagers associated with a single package packaging that package
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. I like your approach. Kudos for handling this conversation in a civilized manner even though you were (more-less) turned down. Let's see if we can ease your pain a little bit... -- 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: RPMs for Maven 3?
Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. I like your approach. Kudos for handling this conversation in a civilized manner even though you were (more-less) turned down. Let's see if we can ease your pain a little bit... -- 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: RPMs for Maven 3?
I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. I like your approach. Kudos for handling this conversation in a civilized manner even though you were (more-less) turned down. Let's see if we can ease your pain a little bit... -- Stanislav Ochotnicky sochotni...@redhat.com
Re: RPMs for Maven 3?
To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer
Re: RPMs for Maven 3?
On Mar 20, 2012, at 10:19 AM, Stanislav Ochotnicky wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? Consuming the already produced output is the most viable approach. I don't think anyone here wants to actively support and test an RPM. It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's
Re: RPMs for Maven 3?
On Tue, March 20, 2012 7:19 am, Stanislav Ochotnicky wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. This all looks pretty good. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion That would be very useful imho. I am using and contributing to https://github.com/juven/maven-bash-completion that has a lot more plugins and stuff.. maybe you could pull some of this in ... ideally a upstream maintained bash completion would be nice. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to
Re: RPMs for Maven 3?
No problem with adding committers... Demonstrate commitment to the project. Produce good patches, and presto chango, we will invite you. My point is that even if you were a committer, the Apache by-laws state that the PMC must vote at least 3 x +1 to release a binary, so if you cannot find 3 of the current 24 who are even willing to consider voting on RPMs then you are not going to get binary RPMs released, not because we don't want to, or because we think they are pointless, etc... no simply because of the rules that govern the Apache release process. We are always on the look out for new committers... I actually think that Maven is one of the easiest projects to get commit access... as long as you demonstrate some ability via good patches attached to JIRA issues etc. -Stephen On 20 March 2012 20:45, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to
Re: RPMs for Maven 3?
On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason It's actually simpler than this. If someone posts a reasonable patch -- where reasonable means (in my opinion), could be part of the automated Jenkins builds, doesn't inordinately inconvenience people building the core on Windows, then some committer might commit it. *I* might commit it. If one of my fellow PMC members found it bottomlessly horrible, they could exercise their post-commit review powers and tell me to yank it until we had a formal vote. Once it was in place, then the next question would be, Would any release manager take responsibility for including the results in a vote? Now, keep in mind that Apache releases are SOURCE releases. The binaries are for convenience only. Still, I agree with Stephen C. that it would be bad form to put RPMs on /dist that hadn't been supervised by the PMC. The final question, then, as Stephen has pointed out, would be, would a sufficiency of PMC members vote +1 and not -1 for a release with them. So far, no PMC member has expressed any enthusiasm for that step. On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the
Re: RPMs for Maven 3?
On 20 March 2012 22:49, Benson Margulies bimargul...@gmail.com wrote: On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason It's actually simpler than this. If someone posts a reasonable patch -- where reasonable means (in my opinion), could be part of the automated Jenkins builds, doesn't inordinately inconvenience people building the core on Windows, then some committer might commit it. *I* might commit it. I might commit it too, but I ain't going to have time to test it, and I would only commit it in a separate module in a separate tree so that it could be released separately, but others may have a different view... I don't see myself raising veto on RPM builds If one of my fellow PMC members found it bottomlessly horrible, they could exercise their post-commit review powers and tell me to yank it until we had a formal vote. Once it was in place, then the next question would be, Would any release manager take responsibility for including the results in a vote? Now, keep in mind that Apache releases are SOURCE releases. The binaries are for convenience only. Still, I agree with Stephen C. that it would be bad form to put RPMs on /dist that hadn't been supervised by the PMC. The final question, then, as Stephen has pointed out, would be, would a sufficiency of PMC members vote +1 and not -1 for a release with them. So far, no PMC member has expressed any enthusiasm for that step. Actually -1 votes don't count. You cannot veto releases, you only need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release manager is still allowed to proceed with the release! [It would be bad form to proceed from my PoV, but the rules allow it] -Stephen On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they
Re: RPMs for Maven 3?
On 3/20/12 5:23 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 March 2012 22:49, Benson Margulies bimargul...@gmail.com wrote: On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason It's actually simpler than this. If someone posts a reasonable patch -- where reasonable means (in my opinion), could be part of the automated Jenkins builds, doesn't inordinately inconvenience people building the core on Windows, then some committer might commit it. *I* might commit it. I might commit it too, but I ain't going to have time to test it, and I would only commit it in a separate module in a separate tree so that it could be released separately, but others may have a different view... I don't see myself raising veto on RPM builds I agree that they should be separate modules, I would expect some type of integration tests that would be written with the modules. However, that is problematic unless maven has a CI environment that could ramp up VM's quickly for the different distributions and test them. Anyway, I would love to see RPM's, but I am not really interested myself in doing them either. Hopefully, someone else can find a good solution and do this work and we can get it added, but I do see the challenges. If one of my fellow PMC members found it bottomlessly horrible, they could exercise their post-commit review powers and tell me to yank it until we had a formal vote. Once it was in place, then the next question would be, Would any release manager take responsibility for including the results in a vote? Now, keep in mind that Apache releases are SOURCE releases. The binaries are for convenience only. Still, I agree with Stephen C. that it would be bad form to put RPMs on /dist that hadn't been supervised by the PMC. The final question, then, as Stephen has pointed out, would be, would a sufficiency of PMC members vote +1 and not -1 for a release with them. So far, no PMC member has expressed any enthusiasm for that step. Actually -1 votes don't count. You cannot veto releases, you only need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release manager is still allowed to proceed with the release! [It would be bad form to proceed from my PoV, but the rules allow it] -Stephen On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rp m I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the
Re: RPMs for Maven 3?
On Mar 20, 2012, at 5:23 PM, Stephen Connolly wrote: Actually -1 votes don't count. You cannot veto releases, you only need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release manager is still allowed to proceed with the release! [It would be bad form to proceed from my PoV, but the rules allow it] Stephen, This is absolutely incorrect. Please re-read http://www.apache.org/foundation/voting.html and you will see you need more +1's than -1's. Ralph
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-16 19:55:31) Hi Stanislav, On Fri, Mar 16, 2012 at 3:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. Okay, I will try to find the SRPM and rebuild it on my CentOS 6 box. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. Thanks for the pointer and your response. Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. Good luck, -- 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: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 2:45 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. I was really hoping for there to be a Download RPMs link to be available on the Maven website, especially since there's a plugin that makes it easy to create RPMs from Maven builds (assuming the main Maven builds use Maven to build itself). If it's easy, can someone make this happen, please? Thanks! Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 12:28 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 2:45 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. I was really hoping for there to be a Download RPMs link to be available on the Maven website, especially since there's a plugin that makes it easy to create RPMs from Maven builds (assuming the main Maven builds use Maven to build itself). I am -1 to this. Maven is very dubiously useful without connectivity to central. A 'self-contained' Maven build is only self-contained until you try to do something interesting with it. If you have connectivity, it's better to just stick with the pattern that the maven distro is minimal and downloads the rest of what it needs from central. However, my opinion notwithstanding, the only way something like this would happen is if someone offered up a patch with a complete, automated solution. If it's easy, can someone make this happen, please? Thanks! Jos -- Jos Backus jos at catnook.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
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 9:36 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 12:28 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 2:45 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. I was really hoping for there to be a Download RPMs link to be available on the Maven website, especially since there's a plugin that makes it easy to create RPMs from Maven builds (assuming the main Maven builds use Maven to build itself). I am -1 to this. Maven is very dubiously useful without connectivity to central. A 'self-contained' Maven build is only self-contained until you try to do something interesting with it. If you have connectivity, it's better to just stick with the pattern that the maven distro is minimal and downloads the rest of what it needs from central. This is about providing the core Maven distribution as an RPM in addition to a tarball, to make the bootstrapping of a Maven installation easier. That seems orthogonal to the issue you raise here. As an aside, for integrity and repeatability reasons I'd like to have some control over what Maven builds pull so a common pattern is to mirror (the relevant parts of) 'central' (as you call it). Again, this is unrelated to the issue of initial installation, for which I'd like to use the OS-supplied packaging tools and not a tarball. However, my opinion notwithstanding, the only way something like this would happen is if someone offered up a patch with a complete, automated solution. Thanks, Jos If it's easy, can someone make this happen, please? Thanks! Jos -- Jos Backus jos at catnook.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 -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. On Mar 19, 2012, at 12:36 PM, Benson Margulies wrote: On Mon, Mar 19, 2012 at 12:28 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 2:45 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. I was really hoping for there to be a Download RPMs link to be available on the Maven website, especially since there's a plugin that makes it easy to create RPMs from Maven builds (assuming the main Maven builds use Maven to build itself). I am -1 to this. Maven is very dubiously useful without connectivity to central. A 'self-contained' Maven build is only self-contained until you try to do something interesting with it. If you have connectivity, it's better to just stick with the pattern that the maven distro is minimal and downloads the rest of what it needs from central. However, my opinion notwithstanding, the only way something like this would happen is if someone offered up a patch with a complete, automated solution. If it's easy, can someone make this happen, please? Thanks! Jos -- Jos Backus jos at catnook.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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 4:14 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. 1) Easy is always in the eye of the proposer. If you want to supply a patch to the build of maven that builds an RPM that you think is useful, it might well get committed. Whether the results of running it end up on dist would be the output of more discussion. 2) I find it hard to take seriously the proposition that 'download, untar, run' is a high enough bar to fit anything interesting under it. Jos -- Jos Backus jos at catnook.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
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 1:18 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 4:14 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. 1) Easy is always in the eye of the proposer. If you want to supply a patch to the build of maven that builds an RPM that you think is useful, it might well get committed. Whether the results of running it end up on dist would be the output of more discussion. Fair enough, but I figured the Maven people would be interested in building this as a service to their user base. Guess not. 2) I find it hard to take seriously the proposition that 'download, untar, run' is a high enough bar to fit anything interesting under it. Package management (among other benefits) makes it so you don't have to do something special/different for each package to be installed/upgraded on a machine. But never mind, it's clear that you are not interested in helping people this way. Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. I think the people that care about the RPM-based distributions already have RPMs you can use. If we make RPMs then I think we have to be fair and make other packages and that's not really our job and none of us are probably that interested or good at it or it would have been done already. Apparently none of us really care that much. I don't think you want us making these things. I think you want people who care and who are experts in those systems making the packages for those systems. If someone in the Fedora project is making a Maven RPM I think you can expect a higher level of quality there then you're going to get from us. Jos -- Jos Backus jos at catnook.com - 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 - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. I don't know Maven at all but I would expect someone who does and who has some experience with (say) RHEL/CentOS should have little trouble packaging it, especially since I understand there's a plugin which aids in packaging build artifacts as RPMs. I think the people that care about the RPM-based distributions already have RPMs you can use. If we make RPMs then I think we have to be fair and make other packages and that's not really our job and none of us are probably that interested or good at it or it would have been done already. Apparently none of us really care that much. I don't think you want us making these things. I think you want people who care and who are experts in those systems making the packages for those systems. If someone in the Fedora project is making a Maven RPM I think you can expect a higher level of quality there then you're going to get from us. I understand. Thanks for explaining your reasoning. Jos Jos -- Jos Backus jos at catnook.com - 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 - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 5:08 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log, cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On 19 March 2012 21:20, Benson Margulies bimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 5:08 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log, cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. Please not Gentoo the crazy sh1t they do is just plain insane when it comes to Maven... The key thing you need to understand is that any piece of software released by Apache has to have at least 3 x +1 votes from the project's PMC committee... I cannot speak for the other PMCs, I can only speak for my self, but I only vote +1 on things I have actually tested myself... most of the time I try to rebuild the artifact from the source bundle, as that is another thing that the PMC is supposed to verify, and I try to look out for the LICENSE.txt and NOTICE.txt files too... I am not going to be in a position to add testing an RPM build into that mix (being not on an RPM based OS... OK I could spin up a VM, but that is not going to happen with the bandwidth I currently have), certainly not going to be able to test the RPM in a reasonable cross-section of the OSes that would give me a confident +1 and MSI support I have no time to test, let alone set up the toolchain to support generating the MSI... then I'd need the DEB toolchain and test VMs I am not going to veto, but I am -0.9 on adding RPMs into the Maven build, i.e. I have no intention of being in a position to vote +1 on a RPM binary being released by Maven -Stephen - 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: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 2:20 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 5:08 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. I would just leave it out of the package altogether. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log, cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. Who cares if they reject it, if they are not offering anything better. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. Well, what scales better: packagers associated with a single distro trying to package thousands of packages, or packagers associated with a single package packaging that package for a few (major) distros? Jos - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. manfred On 12-03-19 02:57 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 2:20 PM, Benson Marguliesbimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 5:08 PM, Jos Backusj...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zylja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zylja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. I would just leave it out of the package altogether. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log,cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. Who cares if they reject it, if they are not offering anything better. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. Well, what scales better: packagers associated with a single distro trying to package thousands of packages, or packagers associated with a single package packaging that package for a few (major) distros? Jos - 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: RPMs for Maven 3?
Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. Jos manfred On 12-03-19 02:57 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 2:20 PM, Benson Marguliesbimargul...@gmail.com wrote: On Mon, Mar 19, 2012 at 5:08 PM, Jos Backusj...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zylja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zylja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. I would just leave it out of the package altogether. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log,cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. Who cares if they reject it, if they are not offering anything better. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. Well, what scales better: packagers associated with a single distro trying to package thousands of packages, or packagers associated with a single package packaging that package for a few (major) distros? Jos - 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 -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: RPMs for Maven 3?
-Original Message- From: Jos Backus [mailto:j...@catnook.com] Sent: Thursday, March 15, 2012 16:04 To: dev@maven.apache.org Subject: RPMs for Maven 3? Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Should not be to hard, there are rpm building tools for mote platforms and if you can execute a shell script in your CI then you can do it. Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Thanks, Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. -- 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: RPMs for Maven 3?
I would also point out that the plugins do not need packaging, as maven will download them. Only the base distribution needs to be RPM'd. Sent from my iPhone On 16/03/2012, at 9:46 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
- Original Message - From: Chris Graham chrisgw...@gmail.com To: Maven Developers List dev@maven.apache.org Sent: Friday, March 16, 2012 1:42:37 PM Subject: Re: RPMs for Maven 3? I would also point out that the plugins do not need packaging, as maven will download them. Only the base distribution needs to be RPM'd. Well, there are variety of cases when builds are required to happen offline in which case having the plugins packaged is mandatory. Not for every use case but this needs to be pointed out too. Alex Sent from my iPhone On 16/03/2012, at 9:46 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. -- 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 - 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: RPMs for Maven 3?
Hi Stanislav, On Fri, Mar 16, 2012 at 3:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. Okay, I will try to find the SRPM and rebuild it on my CentOS 6 box. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. Thanks for the pointer and your response. Cheers, Jos -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Fri, Mar 16, 2012 at 5:22 AM, Aleksandar Kurtakov akurt...@redhat.com wrote: - Original Message - From: Chris Graham chrisgw...@gmail.com To: Maven Developers List dev@maven.apache.org Sent: Friday, March 16, 2012 1:42:37 PM Subject: Re: RPMs for Maven 3? I would also point out that the plugins do not need packaging, as maven will download them. Only the base distribution needs to be RPM'd. Well, there are variety of cases when builds are required to happen offline in which case having the plugins packaged is mandatory. Not for every use case but this needs to be pointed out too. True. I'm am trying to set up a self-contained build environment but we have Maven supported repositories on-site so I'm going to assume that we can store any plugins there, the idea being that we configure things such that only the local repositories will be queried. I'd hate to duplicate the packaging infrastructure that's already present and working. Thanks, Jos Alex Sent from my iPhone On 16/03/2012, at 9:46 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. -- 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 - 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 -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RPMs for Maven 3?
Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Thanks, Jos -- Jos Backus jos at catnook.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
