Jason van Zyl wrote:

On 6 Dec 06, at 11:38 AM 6 Dec 06, Carl Trieloff wrote:

I have spoken with a few committers over IRC, ApacheCon etc about this so here it comes. Some of us would like to include maven into Fedora distributions. There are two components to this, one technical and the other process similar to the Apache incubator process in that you need a sponsor, need to pass review etc...


To be frank, I'm not so sure this would be a good thing for Maven users. It's not terribly hard to install and here are some of the problems I see:

1. Who is going to maintain this? It seems rather complicated when we have something that works pretty easily.

2. On Redhat would Maven be laid out differently then our stock install? For documentation, and learning purposes having Maven be laid out different and work differently on different platforms is not something I would like to see. It will just make it more difficult for Maven users. Maven does more then Java but we are about platform neutrality and having something that works in a specific way on Redhat that doesn't translate to working on OS/X is not a good thing.

3. What about multiple versions? This would make Maven bound to the OS which is also not a good thing. I have often run into many problem where multiple versions are not allowed. I run 4 different versions of Maven and using RPMs here would make this difficult.

I would be extremely hesitant to make this the standard offering for Maven users on Redhat. I would be hesitant to off anything that did not work in a standard way, or as much of a standard way as possible, between all platforms. I do not see this as a great benefit to Maven users.

Jason.


From the Ant team's perspective, having the jpackage people work on a distro has been mostly beneficial, as it gets things out to a broader audience. The value is not so much for deep java developers (who can install the full stuff and a proper IDE), but for people who dont know or care what maven is, but who use products that depend upon it it. It also lets organisations with configuration management tools to push out upgrades across an organisation. This is a benefit.

Now, I'm with Jason in that RPMs are not ideal, as they dont have a good model of side-by-side versioning; you are manipulating the entire system state and normally only allowing the latest version of things to exist. Compare and contrast with the m2 depencency logic, which is per user installs, per-project versions and way more flexible.

At the same time, I like being able to upgrade 20 machines simultaneously. And I think Java/Java apps should make steps to integrate well with the distributions. After all, most C/C++ apps can be installed standalone, but people use the distribution managers because its easier, and because they like the ability of the tools to keep the installations up to date.

1. Ant has some special hooks for jpackage installs; I forget what they are, but I think the main thing is that if ANT_HOME is undefined and the exe is in the place where jpackage installs it, it looks for ANT_HOME where jpackage puts it.

2. sometimes these cause problems, as people download ant, run ant.sh and find that an older jpackage version gets started. Mostly they dont notice this, they notice some other thing like <echo> complaining about an unknown attribute. I'd say this bugrep happens about once a month -half the frequency of people encountering older versions of Ant from weblogic on websphere.

3. Ubuntu and presumably Fedora ship with a free java, not Sun Java. Does Maven support this? the only good RPM comes from jpackage, and right now that is incomplete due to legacy licensing rules

If you opt to go with RPM/DEB distro, I'd make a couple of recommendations
-work with the JPackage people. They understand the java packages, and will help you get things right. -Consider taking on the problem, for the control and the synchronisation (admittedly, Ant does, and smartfrog delegates to our friends in Cern, but that's just laziness) -Think about what other hooks for RPM installation you'd need. Suddenly you may have a maven system cache that is world readable but not writeable.

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to