Gentoo Archives: gentoo-java

From: Joshua Nichols <nichoj@g.o>
To: Gentoo Java <gentoo-java@l.g.o>
Subject: Re: [gentoo-java] ideas for packages which use maven to build
Date: Thu, 15 Dec 2005 01:15:11
Message-Id: 1134609265.13651.22.camel@metaverse
In Reply to: Re: [gentoo-java] ideas for packages which use maven to build by Karl Trygve Kalleberg
1 On Wed, 2005-12-14 at 19:39 +0100, Karl Trygve Kalleberg wrote:
2 > Joshua Nichols wrote:
3 > > I have been thinking recently, and I think I came up with a viable
4 > > solution for packaging this that use maven for building.
5 > >
6 > > The first problem is that maven will attempt to download jar
7 > > dependencies from a remote repository. This can be avoided by calling
8 > > maven with -o, for offline mode.
9 > >
10 > > This leads to the question of where, then, to get the jars from. I had
11 > > first thought at build time, we could populate a local repository with
12 > > symlinks to jars that we provide from packages. This would work, and
13 > > could be automated to some extent, but I think it would be tedious to
14 > > maintain a list of jars that each package needs.
15 >
16 > Even in the face of such tedium, there is one thing this gives us that
17 > your suggestion does not: the ability to actually check for hidden
18 > dependencies.
19 >
20 > If we create a local, minimal .jar environment for each maven-built
21 > package, we know exactly which jars (and therefore which ebuilds) it
22 > depends on.
23 >
24 > In the case where maven itself goes into the system and looks around for
25 > .jars that are there, we may quickly end up with it depending on stuff
26 > we didn't see.
27 >
28 > This happens with configure scripts and C/C++ applications all the time.
29 > Most of the time, we can do ./configure --enable/disable, but sometimes
30 > flipping this switch has no effect: it will still automatically
31 > autodetect stuff.
32
33 >
34 > Before abandoning the idea of ebuild-local maven repos, I think we
35 > should be very certain that we're not opening up this Pandora's box of
36 > bad mojo.
37 As I mentioned, we could do sanity checks. The project.xml of the
38 project lists EVERY dependency of the project. So, we could parse this
39 file and know what jars will be used from the local repo. We can check
40 if the jar's symlink is valid (the package is installed), and based on
41 where it points to, you can figure out what package it comes from, and
42 consequently check that this package is in DEPEND or RDEPEND.
43
44 > That being said, a system-wide maven repo that users can avail
45 > themselves of would be great! And AFAICT, it would only need minor
46 > tweaks to the java-*.eclasses.
47
48 I was just thinking, and there wouldn't be much needed to support both
49 standard java eclasses and the ones from axxo-overlay.
50
51 Maven has some properties for specifying which target/source to use, so
52 if it's on a system using axxo-overlay, it could use
53 java-pkg_get-{source,target}, and otherwise default to 1.4.
54
55
56 I do have an alternative approach (which I thought I had discussed on
57 the list at some point...).
58
59 Instead of having a local repo, there would be a file that contains
60 information about how a repo path maps to a jar from a package. For
61 example,
62
63 commons-logging/jars/commons-logging-api-1.0.8=commons-logging-api@commons-logging
64
65 >From here, there are a couple of paths... there could either be a
66 package that provides this file for every jar under the sun, this file
67 could live somewhere in /usr/portage. Alternatively, there could be a
68 file for each package/version... but this would add a bit of extra
69 maintenence.
70
71
72 At this point I think either approach would be sufficient. Right now,
73 I'm leaning towards the symlink-populated repo package. It has the added
74 benefit of providing a local repository that a user could use if they
75 wanted
76
77 - Josh
78 --
79 gentoo-java@g.o mailing list