1 |
Joshua Nichols wrote: |
2 |
> I have been thinking recently, and I think I came up with a viable |
3 |
> solution for packaging this that use maven for building. |
4 |
> |
5 |
> The first problem is that maven will attempt to download jar |
6 |
> dependencies from a remote repository. This can be avoided by calling |
7 |
> maven with -o, for offline mode. |
8 |
> |
9 |
> This leads to the question of where, then, to get the jars from. I had |
10 |
> first thought at build time, we could populate a local repository with |
11 |
> symlinks to jars that we provide from packages. This would work, and |
12 |
> could be automated to some extent, but I think it would be tedious to |
13 |
> maintain a list of jars that each package needs. |
14 |
|
15 |
Even in the face of such tedium, there is one thing this gives us that |
16 |
your suggestion does not: the ability to actually check for hidden |
17 |
dependencies. |
18 |
|
19 |
If we create a local, minimal .jar environment for each maven-built |
20 |
package, we know exactly which jars (and therefore which ebuilds) it |
21 |
depends on. |
22 |
|
23 |
In the case where maven itself goes into the system and looks around for |
24 |
.jars that are there, we may quickly end up with it depending on stuff |
25 |
we didn't see. |
26 |
|
27 |
This happens with configure scripts and C/C++ applications all the time. |
28 |
Most of the time, we can do ./configure --enable/disable, but sometimes |
29 |
flipping this switch has no effect: it will still automatically |
30 |
autodetect stuff. |
31 |
|
32 |
|
33 |
Before abandoning the idea of ebuild-local maven repos, I think we |
34 |
should be very certain that we're not opening up this Pandora's box of |
35 |
bad mojo. |
36 |
|
37 |
That being said, a system-wide maven repo that users can avail |
38 |
themselves of would be great! And AFAICT, it would only need minor |
39 |
tweaks to the java-*.eclasses. |
40 |
|
41 |
|
42 |
Cheers, |
43 |
|
44 |
-- Karl T |
45 |
-- |
46 |
gentoo-java@g.o mailing list |