Rafael Schloming wrote:
Jason van Zyl wrote:
I don't remember a specific instance, but I'm sure there are some who
would like them. Either way, we need to consider Fedora as a consumer
of Maven and that they know what their users want, which apparently
is Maven bundled with Fedora.
I doubt they have asked but I would be pleasantly surprised if the
impetus was actually Maven users and not simply a desire to package
Maven up on Redhat.
There are multiple projects that we develop on that use maven and need
to go into distros. FWIW this makes use maven users that would really
like to see maven work well with distros.
Yes, now that RedHat owns JBoss, there is an opportunity to do a
complete server side and client side dev stacks, in which everything
comes as an RPM.
another use case is the dynamic-image-creation story, where something
creates a kickstart package list on the fly, to create an ISO image that
VMWare or Xen can boot off. In this use case the requirements to be
sysadmin and bias towards single-version is irrelevant, the image has a
lifespan of 2-48 hours, and will only have the packages the ops team
want on it.
>We also agree that usability is the key objective. That's exactly why
we want
> to work out a solution and not distribute a modified version of maven
just to
> satisfy our bootstrapping requirements.
That is a final point to note. The linux distro teams will package your
files if they see a need, and will produce whatever distro they want.
You can either work with them & JPackage to produce something everyone
is happy with, or you end up fielding support calls related to a
modified fork of your app. i.e. the JBoss fork of Axis, the debian
Apache HTTPD .deb, and such like. If maven distributed by redhat doesnt
work right, who gets the blame? Maven, that's who.
My recommendation would be to work with the downstream distributors;
understand their needs and get them to understand yours, to produce
something where they distribute the JARs unaltered, and stick things in
a place you are happy with. They can do good testing in exchange.
The biggest troublespot will be clashing versions. When a user installs
their own version of maven by hand, it *must* take precedence over the
RPM-installed one, and the origin of the maven must be visible to the
naked eye. Ant -diagnostics does that, but you could imagine the command
line detecting an RPM install from some
this.getClass().getClassloader().getURI() kind of diagnostics, and
printing it out:-
Apache Maven 2.0.x (linux distribution)
Actually, that's kind of cool. I may make Ant do that.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
