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 |