maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: RPMs for Maven 3?
Date Wed, 21 Mar 2012 00:23:00 GMT
On 20 March 2012 22:49, Benson Margulies <> wrote:
> On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee
> <> 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]


>> On 3/20/12 7:47 AM, "Stephen Connolly" <>
>> 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
>>>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
>>>Profiles would be evil for this case... separate module outside of the
>>>main build is fine.
>>>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 <>
>>>> 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:
>>>> SRPM URL:
>>>> 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
>>>> someplace? We have a slightly modified version in Fedora.
>>>> [1]
>>>> Quoting Jason van Zyl (2012-03-20 13:33:32)
>>>>>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
>>>>>>><> wrote:
>>>>>>>> Jos,
>>>>>>>> I agree with you in the sense that any open source project
>>>>>>>>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
>>>>>>>> imho.
>>>>>>> Yes. It increases adoption by lowering the threshold to
>>>>>>> the software.
>>>>>>>> However for Maven this is clearly not going to happen from
>>>>>>>>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
>>>>>>> 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
>>>>>> FHS proponents get angry (too much). If it gets commited: woot. If
>>>>>> 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
>>>>>>>> it to other people as well.
>>>>>>> Indeed.
>>>>>> If you disregard a bit of common sense of Linux distribution wrt
>>>>>> similar things you could create rpm by using binary maven tarball.
>>>>>> is definitely easier than adding rpm output to Maven and supporting
>>>>>> on different distributions :-)
>>>>>>>> You could try to push it to rpm repositories outside Fedora/Red
>>>>>>>>in case
>>>>>>>> any one is interested but it all depends on the effort you
want to
>>>>>>>> Most people want to be sure they have an Apache quality package
>>>>>>>>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
>>>>>>>>available that
>>>>>>>> would get automatically updates as part of regular updates..
>>>>>>> Yes, I think so, too. Not providing packages hampers adoption
>>>>>>> versions because people will stick with the old versions that
>>>>>>> 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,
>>>>>>> sounds like it's not a priority.
>>>>>>> Thanks for your response, Manfred, and for everyone else's input
>>>>>>>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
>>>>>> if we can ease your pain a little bit...
>>>>>> --
>>>>>> Stanislav Ochotnicky <>
>>>>>> Software Engineer - Base Operating Systems Brno
>>>>>> PGP: 7B087241
>>>>>> Red Hat Inc.                     
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>>Jason van Zyl
>>>>>Founder,  Apache Maven
>>>>>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 <>
>>>> Software Engineer - Base Operating Systems Brno
>>>> PGP: 7B087241
>>>> Red Hat Inc.                     
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>>To unsubscribe, e-mail:
>>>For additional commands, e-mail:
>> ________________________________________________________________________
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message