Eivind Tagseth wrote: > * J�rg Schaible <[EMAIL PROTECTED]> [2004-01-28 > 01:57:49 +0100]: > >> what should we do with Java ebuilds using Maven? The current Maven ebuild >> does not set the local repository location i.e. every user will have its >> own repository in its home directory. While this is what the Maven folks >> recommend, it is not very good for Gentoo. > > No, it isn't. Maven seems to try to solve many of the same problems as > gentoo/portage does. Portage just does it better (IMO).
IMHO they have different targets. Maven is a tool for developers building their app and they will often have to deal with snapshot releases, that sould never made it into Gentoo anyway, not even masked. What sucks is, that their repository does not even has a concept for source balls. [snip] >> Therefore I would suggest to use a common repository in Gentoo somewhere >> in /var/cache/maven. We'll just have to take care for the permissions, >> since the normal user will have to write into the repository also if he >> is using Maven. > > I think the Maven approach of downloading binaries into a repository is > all > wrong (not for other distributions maybe, but certainly for gentoo). If > I've gone through the trouble of creating an excellent ebuild file for > building commons-foo from scratch (maybe even with certain patches), then > I'd expect (and want) that result to be used when later emerging package > java-bar that depends on commons-foo. Anything else rather violates the > gentoo spirit of things. Well, this is not a Maven problem, just look at Cocoon. Its source ball comes with 14 jars declared as core libs. Three of them *are* snapshot releases. Not counting the endorsed and optional libs. They even deliver an own ant release to build Cocoon. The ebuild now just calls build.sh to build Cocoon using their internal Ant. Do you really expect that anyone is willing to create that much ebuilds for all these dependent jars, test any functionality exchanging all the snapshot packages with official releases (IMHO not feasable anyway) and create for every release a big patch for the build files, that it will use the already installed versions? *shrug* > So rather than patching maven to make a central repository for it's binary > downloads, I'd like to propose fixing/changing maven to use what's > already installed by gentoo. If this means creating a custom downloader > that copies files from /usr/share/<package>, then fine. If it means > making maven use java-config to find it's required packages and use them > where they are, even better. Has anyone looked into how much work this > would be? Well, you would have to create a fork of Maven. Jason would never put something like that into Maven regardless of any patches sent on this topic. But as I mensioned, it is not Maven alone! Maven is just the most offensive tool violating the rule "build anything from source". > I've seen comments from people saying that maven builds often requires > version 3.4.5.2.3.1.3 of a certain package, and that this means that > downloading that binary is the only thing that would work. I'd say that > such a package probably shouldn't be made a stable package in the > portage three. But even if it did, I'd prefer an ebuild for that > binary, perhaps in it's own slot, just to keep things tidy. see Cocoon. IMHO I cannot see your vision going to happen, sorry. I really understand your point and also the motivation, but take again a look at the Cocoon package: Building it here on my machine natively, I get a big fat warning, that my generated version will depend on JDK 1.4.x and will not run for JDK 1.3.x and earlier. As a developer, this is a show-stopper. If I have to build an app for WebLogic or Webshpere I *have* to use 1.3.x, since these apps are not certified by their vendors for newer JDKs and your on your own regarding support. The Gentoo version of Cocoon would be useless to me. While I can argue for Java applications to build anything from source, I cannot do so for a development environment. And this problem might increase with the upcoming JDK 1.5. OTOH, what's so wrong with the prebuild Java package? It is Java's nature to have precompiled code already optimized for its processor - the VM. To change the processor, change the VM. I might just rebuild the VM itself or at least native enhancements beeing used with JNI to gain a more optimized version for my processor. Same applies to .NET assemblies running on mono. I believe that most Java programmers here are just pragmatic about this topic and the effort created by the source-only-solution is not worth the outcome. If the source-only-rule will be applied I believe, that you will not be able to create a community maintaining the necessary ebuilds and the Java packages in portage will always be so outdated, that no-one really cares about them. If you do not believe me, look into portage/dev-java, this is what currently already happens. IMHO we need some guilde lines for Java ebuilds and ground is layed with java-pkg eclass. I would be happy, if any Java ebuild would obey some global USE flags for doc, java-source, maven and samples and installs itself smoothly into the file system: /usr/share/<package>-<slot>/lib /usr/share/docs/<package>-<slot> /usr/share/docs/<package>-<slot>/license /usr/share/docs/<package>-<slot>/api [+doc] /usr/share/<package>-<slot>/lib/<package>-src.jar [+java-source] /usr/share/<package>-<slot>/lib/samples [+samples] /var/cache/maven/<package>/jars/<package>-<version> [+maven] /var/cache/maven/<package>/license/LICENSE [+maven] (while the Maven entries could be symlinks). Just my 2 cents. Regards, J�rg -- [EMAIL PROTECTED] mailing list
