1 |
On Wed, 2005-12-14 at 19:39 +0100, Karl Trygve Kalleberg wrote: |
2 |
> Joshua Nichols wrote: |
3 |
< SNIPPED > |
4 |
> > This leads to the question of where, then, to get the jars from. I had |
5 |
> > first thought at build time, we could populate a local repository with |
6 |
> > symlinks to jars that we provide from packages. This would work, and |
7 |
> > could be automated to some extent, but I think it would be tedious to |
8 |
> > maintain a list of jars that each package needs. |
9 |
> |
10 |
> Even in the face of such tedium, there is one thing this gives us that |
11 |
> your suggestion does not: the ability to actually check for hidden |
12 |
> dependencies. |
13 |
|
14 |
Karl, |
15 |
I'm a little confused by the above statement. Are you agreeing with |
16 |
Josh, or disagreeing? In other words, are you in favor of the tedium |
17 |
because it gives the ability to check for hidden dependencies? |
18 |
|
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 |
This sounds like what Josh was suggesting in one way, but I can't be |
25 |
sure if you're saying that you like his idea or rather the idea of |
26 |
making smaller, separate repositories. Just wondering. |
27 |
|
28 |
|
29 |
> In the case where maven itself goes into the system and looks around for |
30 |
> .jars that are there, we may quickly end up with it depending on stuff |
31 |
> we didn't see. |
32 |
|
33 |
I agree, although this really is an upstream problem I think. If they |
34 |
aren't even properly documenting what libraries their application |
35 |
depends on, I see that as a bigger problem we shouldn't necessarily try |
36 |
to fix for them. I understand that this does happen in the real world, |
37 |
however. :-) |
38 |
|
39 |
Greg |