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.
