harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Trygve Kalleberg <kar...@gentoo.org>
Subject Re: Status updates and distribution integration
Date Wed, 11 May 2005 22:02:14 GMT
Stefano Mazzocchi wrote:
> Mark Wielaard wrote:
> 
>> Hi Stefano,
>>
>> On Wed, 2005-05-11 at 11:02 -0400, Stefano Mazzocchi wrote:
>>
>>>> Similar things work out of the box by doing a yum install of some of
>>>> the
>>>> packages in the above list (ant, eclipse, jakarta-*, bcel, junit,
>>>> struts, gjdoc, etc). All use gcj.
>>>
>>>
>>> Mark, is there anything similar to that for debian and/or gentoo?
>>> (just curious, since I run debian those on my servers).
>>
>>
>>
>> Not yet. As I said FC4 test 3 was just released yesterday and they beat
>> every other distribution in this particular area. But similar things are
>> planned for future Debian and Ubuntu releases:
>> http://java.debian.net/index.php/DebianJavaRoadMap
>> http://java.debian.net/index.php/MovingJavaToMain
>> (They are monitoring the Gump results with Kaffe with great interest.)
>> http://www.ubuntulinux.org/wiki/JavaIntegration
>> http://www.ubuntulinux.org/wiki/JavaPackagingProgress
>>
>> Karl (CCed) can probably give you a similar plan for Gentoo.
>>
>> The consesus seems to be to follow the http://www.jpackage.org/ project
>> as much as possible. Even though at the moment they are very RPM based.
>> That is probably one of the reasons Gentoo and Debian are a bit behind.
>> They cannot just lift the packages from jpackage, but need to do some
>> more work to adapt them cleanly to their distribution.
> 
> 
> Any thoughts of using maven? [again, not criticizing, just curious]

>From the Gentoo camp:

Maven is a very problematic us Gentoo packagers. It makes our lives
difficult. In fact, in Gentoo, we have adopted the stance of just
ripping out the Maven project.xml and replacing it with a build.xml, so
that we can get proper packaging done (figuratively; we just generate a
build.xml and run ant).

Problems we've had with Maven itself:

1) For a long time, it turned out to be difficult or impossible find
   the source code for all its dependencies. I believe that the last
   external project with missing source has now been integrated into
   the Maven codebase and that the remaining external deps have
   fetchable source.

2) If you look at the dependency tree for Maven[1], you will see that
   bootstrapping it in a source-based distro is extremely tricky,
   is it depends on itself through a second-level indirection.
   (I.e., it requires maven-jelly-tags to be built, and
   maven-jelly-tags will only build with maven).

   Interestingly, Maven 1.x actually depends on ant. Go figure;)


Problems with the Maven model:

1) Part of Maven's seductive appeal is its readily available package
   set which may be used by all Maven users. Need antlr? Sure, just add
   it to your deps, and it'll be fetched for you at build time.

   Needless to say, this is problematic or us packagers. We expressly
   do _not_ want every package to come with its transitive closure of
   dependencies. Imagine every Java library having its own copy of
   GNU Classpath. Sheesh. If you find this unrealistic, take a close
   look at what's happening with the xml*.jars. These are duplicated
   in practically *every* open-source Java project out there that has
   to do with web development.

2) License awareness is not part of its (current) design. None of the
   packages in the Maven repo come with source code. As packagers, we
   don't always have a good clue which upstream version a given .jar
   was taken from. And worst of all, the repo does not contain any
   information about the license for a given .jar. This means it is
   the duty of any developer to closely track down the origin of any
   .jar he includes from the Maven repo, to determine its licensing
   conditions.


In a way, Maven is more a hindrance to packaging than a help. When we
package a program incidentally written in Java, we want it to use the
existing Java libraries we have already packaged. Just as we don't want
Gentoo packages downloading .deb files[2] on the fly as part of the
build process, we don't want it to download unsigned .jar files from the
Maven repo either. In Gentoo, we already have system for signing,
checking and distributing source files for a given project. The default
behaviour of Maven circumvents this.

Of course, we could "always just write a mapping" from the Maven repo to
our own repo, and disable Maven's auto download feature, or have it
"fetch" its jars from our "virtual" repo. We've looked into that, but
you know what? For packaging, it turns out to be a lot easier just to
resort to plain ant.

I believe the idiosyncracies of Maven to be less intrusive in binary
distros, so I'll leave it to the other guys to reply on that.


-- Karl T

[1] See the RDEPEND variable in
https://bugs.gentoo.org/attachment.cgi?id=46886&action=view

[2] We have nothing against Debian nor .deb files.

Mime
View raw message