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