From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EmhiB-00035Y-D0 for garchives@archives.gentoo.org; Thu, 15 Dec 2005 01:15:11 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBF1EMBe026285; Thu, 15 Dec 2005 01:14:22 GMT Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.61]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBF1EL9b021780 for ; Thu, 15 Dec 2005 01:14:21 GMT Received: from 146-115-26-214.c3-0.abr-ubr1.sbo-abr.ma.cable.rcn.com (HELO [192.168.1.110]) ([146.115.26.214]) by smtp01.mrf.mail.rcn.net with ESMTP; 14 Dec 2005 20:14:20 -0500 X-IronPort-AV: i="3.99,255,1131339600"; d="scan'208"; a="142229823:sNHT26389432" Subject: Re: [gentoo-java] ideas for packages which use maven to build From: Joshua Nichols To: Gentoo Java In-Reply-To: <43A066CA.9070708@gentoo.org> References: <1134579920.4739.23.camel@francisco-repilado.nfic.com> <43A066CA.9070708@gentoo.org> Content-Type: text/plain Date: Wed, 14 Dec 2005 20:14:25 -0500 Message-Id: <1134609265.13651.22.camel@metaverse> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 794806de-4333-42ac-b16e-04c4a9223754 X-Archives-Hash: 2db43a777cc6ecbfb2ac154dc83318d0 On Wed, 2005-12-14 at 19:39 +0100, Karl Trygve Kalleberg wrote: > Joshua Nichols wrote: > > I have been thinking recently, and I think I came up with a viable > > solution for packaging this that use maven for building. > > > > The first problem is that maven will attempt to download jar > > dependencies from a remote repository. This can be avoided by calling > > maven with -o, for offline mode. > > > > This leads to the question of where, then, to get the jars from. I had > > first thought at build time, we could populate a local repository with > > symlinks to jars that we provide from packages. This would work, and > > could be automated to some extent, but I think it would be tedious to > > maintain a list of jars that each package needs. > > Even in the face of such tedium, there is one thing this gives us that > your suggestion does not: the ability to actually check for hidden > dependencies. > > If we create a local, minimal .jar environment for each maven-built > package, we know exactly which jars (and therefore which ebuilds) it > depends on. > > In the case where maven itself goes into the system and looks around for > .jars that are there, we may quickly end up with it depending on stuff > we didn't see. > > This happens with configure scripts and C/C++ applications all the time. > Most of the time, we can do ./configure --enable/disable, but sometimes > flipping this switch has no effect: it will still automatically > autodetect stuff. > > Before abandoning the idea of ebuild-local maven repos, I think we > should be very certain that we're not opening up this Pandora's box of > bad mojo. As I mentioned, we could do sanity checks. The project.xml of the project lists EVERY dependency of the project. So, we could parse this file and know what jars will be used from the local repo. We can check if the jar's symlink is valid (the package is installed), and based on where it points to, you can figure out what package it comes from, and consequently check that this package is in DEPEND or RDEPEND. > That being said, a system-wide maven repo that users can avail > themselves of would be great! And AFAICT, it would only need minor > tweaks to the java-*.eclasses. I was just thinking, and there wouldn't be much needed to support both standard java eclasses and the ones from axxo-overlay. Maven has some properties for specifying which target/source to use, so if it's on a system using axxo-overlay, it could use java-pkg_get-{source,target}, and otherwise default to 1.4. I do have an alternative approach (which I thought I had discussed on the list at some point...). Instead of having a local repo, there would be a file that contains information about how a repo path maps to a jar from a package. For example, commons-logging/jars/commons-logging-api-1.0.8=commons-logging-api@commons-logging >>From here, there are a couple of paths... there could either be a package that provides this file for every jar under the sun, this file could live somewhere in /usr/portage. Alternatively, there could be a file for each package/version... but this would add a bit of extra maintenence. At this point I think either approach would be sufficient. Right now, I'm leaning towards the symlink-populated repo package. It has the added benefit of providing a local repository that a user could use if they wanted - Josh -- gentoo-java@gentoo.org mailing list