Gentoo Archives: gentoo-java

From: Joshua Nichols <nichoj@g.o>
To: gentoo-java@l.g.o
Subject: Re: [gentoo-java] ideas for packages which use maven to build
Date: Fri, 30 Dec 2005 07:24:07
Message-Id: 43B4E072.6060500@gentoo.org
1 Jose Gonzalez Gomez wrote:
2
3 > 2005/12/15, Joshua Nichols <nichoj@g.o
4 > <mailto:nichoj@g.o>>:
5 >
6 > On Wed, 2005-12-14 at 19:39 +0100, Karl Trygve Kalleberg wrote:
7 > > Joshua Nichols wrote:
8 > > > I have been thinking recently, and I think I came up with a viable
9 > > > solution for packaging this that use maven for building.
10 > > >
11 > > > The first problem is that maven will attempt to download jar
12 > > > dependencies from a remote repository. This can be avoided by
13 > calling
14 > > > maven with -o, for offline mode.
15 > > >
16 > > > This leads to the question of where, then, to get the jars
17 > from. I had
18 > > > first thought at build time, we could populate a local
19 > repository with
20 > > > symlinks to jars that we provide from packages. This would
21 > work, and
22 > > > could be automated to some extent, but I think it would be
23 > tedious to
24 > > > maintain a list of jars that each package needs.
25 > >
26 > > Even in the face of such tedium, there is one thing this gives
27 > us that
28 > > your suggestion does not: the ability to actually check for hidden
29 > > dependencies.
30 > >
31 > > If we create a local, minimal .jar environment for each maven-built
32 > > package, we know exactly which jars (and therefore which
33 > ebuilds) it
34 > > depends on.
35 > >
36 > > In the case where maven itself goes into the system and looks
37 > around for
38 > > .jars that are there, we may quickly end up with it depending on
39 > stuff
40 > > we didn't see.
41 > >
42 > > This happens with configure scripts and C/C++ applications all
43 > the time.
44 > > Most of the time, we can do ./configure --enable/disable, but
45 > sometimes
46 > > flipping this switch has no effect: it will still automatically
47 > > autodetect stuff.
48 >
49 > >
50 > > Before abandoning the idea of ebuild-local maven repos, I think we
51 > > should be very certain that we're not opening up this Pandora's
52 > box of
53 > > bad mojo.
54 > As I mentioned, we could do sanity checks. The project.xml of the
55 > project lists EVERY dependency of the project. So, we could parse this
56 > file and know what jars will be used from the local repo. We can check
57 > if the jar's symlink is valid (the package is installed), and
58 > based on
59 > where it points to, you can figure out what package it comes from, and
60 > consequently check that this package is in DEPEND or RDEPEND.
61 >
62 >
63 > This is true no more for maven 2.0. They have added transitive
64 > dependencies to the project building, so now you only list in the
65 > project descriptor ( pom.xml) the direct dependencies and their scope.
66 > Maven takes care of reading project descriptors of those other
67 > dependencies from the remote repository and builds the whole real list
68 > of dependencies. So I think such an approach wouldn't work for Maven2.
69 >
70 You are correct. With some work though, I think it could work. We could
71 mirror the pom.xml's in the gentoo maven repo. Then we could check the
72 dependencies the immediate package has, at the least.
73
74 > Have you thought of patching the maven sources to intercept dependency
75 > resolution and download and do something like calling emerge? I
76 > haven't taken a look at maven sources, so I don't have any idea if
77 > this is really feasible, or I'm just babbling.
78
79 It has been thought of in the past. Of course, just saying, 'hey, let's
80 patch maven to do it!' is a lot easier than actually getting it working.
81
82 The place that we'd want to get control, if you would, is the point
83 where dependencies get downloaded. Given that the maven infrastructure
84 is all about plugins for extending functionality, you'd think it'd just
85 be a matter of writing a plugin in. I've spoken with some of the folks
86 in #maven on irc.codehaus.org, and apparently it wouldn't be quite that
87 simple.
88
89
90 -- Josh
91 --
92 gentoo-java@g.o mailing list