----- 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 > > 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 > >> > > > > > > > --------------------------------------------------------------------- > 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
