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 |