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 >>>>>> 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 >>> >>> -- >>> 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 >> > > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > > --------------------------------------------------------------------- > 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
