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
