On 9 Dec 06, at 11:06 AM 9 Dec 06, David Whitehurst wrote:
I'm an AppFuse person that listens here and I agree wholeheartedly
with
Jason. All of the linux variations have a graphical file explorer
and some
unzip facility. You just do the following:
Just for clarification I am not opposed to people using Maven on
these distros. I am opposed to them having a bad experience with
Maven because distro makers insist on Maven conforming to the distro
at hand when it really doesn't fit. Especially for Java users. If
you're starting use Maven for building C/++ stuff then some
adjustments would have to be made but I work with people who build
RPMs with Maven just fine without it conforming to the distro. These
are not small builds either.
I myself have two clients who are massive Redhat users and they are
using Redhat on a daily basis in production and they are building
RPMs with Maven. One of the clients attempted to build an RPM of
Maven for training and it caused a great deal of grief. I had my own
Maven bundle that I had made for training and the RPM laid down stuff
in completely different places and it took me 10 minutes to figure
out what was going on. This is the most likely outcome of trying to
wedge Maven into Redhat as an RPM.
Requiring a bootstrap that builds from sources? Not going to happen.
Why on earth would we attempt that with Java? We started down that
path and it made the bootstrap incomprehensible to a someone trying
to understand the bootstrap to fix problems. Dan Fabulich cleaned up
our bootstrap and turned a big mess we had into 200 lines of Ant (yes
we use Ant to bootstrap so that would cause you even more grief).
Going through all those contortions to satisfy a throwback of having
to build with C/++ where you do need to build from source to
guarantee that it will work on a given platform is not something we
need. We can guarantee you get the same binaries using checksums or
PGP signatures.
Changing the layout of Maven on distros? Not going happen. Unless you
want to fully support it on your own mailings lists. When users come
here it is a fundamental principle of Maven that users here being
able to talk some common lingo and that goes all the way down the
layout of their install. Infrastructure matters. Here I would say
that how Maven users interoperate is more important then how Redhat
users interoperate. At least for our community.
Keeping up with our changes? As we become more modular and pieces of
Maven can be replaced then you are going to have a hard time keeping
up and users often pull down snapshots to try out new things. Trying
to keep the infrastructures for Redhat/Solaris/BSD/Unbuntu in sync
with what we are doing would be an absolute nightmare and strain our
resources on matters that are ultimately of no concern to the average
Maven users.
If you really wanted to determine the importance of this issue then
have Redhat sponsor a survey and we will find out empirically. Get an
account on SurveyMonkey for 20 bucks and ask Maven users. If you had
a significant response in favour of distro packaging then I would
recant everything I have said and help you as I only have my
qualitative experience of 6 years of working with Maven, watching the
mailings lists, and working with clients in the enterprise who use
Maven.
Jason.
- drag the tar.gz to where you're unzipping
- ln -s /usr/local/maven-2.0.4 /usr/local/maven
- set M2_HOME=/usr/local/maven
- export PATH=${M2_HOME}/bin: .... $PATH
That works ... and you don't have to change anything.
-I put eclipse on Ubuntu using their package manager and it didn't
work
directly
-I put Tomcat on Ubuntu using their package manager and it didn't work
out-the-box with AppFuse (permissions)
I'm all for "quit trying to support Linux users who don't know
Linux/UNIX"
My two-cents (or Euro's)
David Whitehurst
On 12/9/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
Carl Trieloff <[EMAIL PROTECTED]> writes:
>1. Get rpm from jpackage. Check if it is set to build natively.
> If not,
> Build it, run it through spec-gcj-convert (file attached),
verify
> new spec, rebuild it, make sure it conforms to Fedora
guidelines
> for everything except the release number and all, that
should be
> jpackage specific. Then upload this to jpackage.
> If it is:
> Do nothing
Oh, if only you would 'do nothing'.
That is IMHO the point where your 'community' falls apart and why I'm
a strong opponent to "including Java into FLOSS distributions".
I don't want my components compiled with a half-baked, non-standards
compliant, gobbled together thing that defies any certification
because "it wants to be free". And the readiness that RedHat/Fedora
embraces that kludge because it claims to be "free".
I don't care. If you want to use Java in an "more than hobbist"
environment, you want to use one of the commercial JDKs. And if you
defy to at least compile the Java components with a certified JDK,
they are useless. Native compilation? Bulls*hit. You don't seem to
understand Java at all.
There are a number of other decisions (like insisting on ripping
perfectly well packaged software like ant or tomcat apart because
they
"contain components that we have elsewhere") but trying to do native
compilation is by far the worst.
JPackage got it wrong, you got it wrong. As long as you insist on
doing it wrong, IMHO it is better to *not* do it at all.
Or at least clearly label all
"environment-that-is-not-Java-because-we-are-not-allowed-to-call-
it-so"
packages so that one can get rid of them easily.
Thanks & Best regards
Henning
--
Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
