On Sat, Jan 10, 2004 at 08:17:36PM +0100, J�rg Schaible wrote: > Karl Trygve Kalleberg wrote: > > Are you aware of Maven?
Yes. > This is also a build tool for Java apps and I know meanwhile some of > them using it. Basically the Maven community maintains a repository > for Java archives (currently at http://ibiblio.org/maven), that will > never (!?!) be cleared from old versions. Maven builds an app > according to a project description that contains dependencies. The > dependent archives are downloaded into a local repository during the > build. > > What has this to do with portage? Well, if I would like to create an ebuild > e.g. Apache Merlin from the Avalon project, I will have to use Maven within > the ebuild, since the build generates its own Maven plugins used in the > build itself again (and this is common for Maven builds). Additionally all > dependent archives will ignore portage at all and download the Java > archives from ibiblio (and cache them in a local repo). We have a similar (currently unsolved problem) with Eclipse; it updates itself from the net, bypassing portage entirely. > The difference to portage is, that each dependency references always the > exact version of the dependen archive. And this is often a snapshot from a > specific date. I've build enough apps based on the Apache stuff and > normally all the versions are not binary compatible and will break stuff, > sometimes very subtile. The dependency system of Maven gives you at least a > chance to have a running app ... I certainly agree that many java applications seem to have extremely fickle dependencies, that will only work with one particular snapshot of a given package. The practice of Maven to download these extra libraries at build time will not in general work in Gentoo, as we have an implicit rule saying that you can do emerge -f package to download the required files, then log off the net and do building offline. For now, I don't think we have any packages that use maven to build, but this is definitely a problem that needs to be resolved when we do. The idea of a SLOT for libraries is that all versions of an ebuild sharing a particular SLOT are binary-compatible. When snapshots are required, we would need to set the SLOT="snapshot-id", and make certain that several SLOTed versions of the same library can coexist. This is usually trivial for libraries that do not have user-visible shell scripts. For libraries that do, we most likely need to tag the shell script name with the library version or the SLOT version (in so much as they differ). I'll see if I can't have a peek at Apache Merlin to see how we can solve this, after I've cleared up a few other issues. > Well, do not forget EARs or WARs. You have to modify sometimes the classpath > before you start the server. The problem is: Into which app server or > servlet container should an ebuild for such an application merge the > application ... The classpath modification would have to be done in the startup script for the server, a script that would rely on java-config to do the dirty work. As for installing libraries into a particular servlet container: that's what we have USE flags for, which are merge-time switches to the ebuild about how it should configure itself. Of course, we need to come up with a provision for the sysadm to add merged packages somewhat cleanly to existing servers/containers without needing to remerge the package every time. Kind regards, Karl T -- [EMAIL PROTECTED] mailing list
