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 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
