Joshua Nichols wrote:
> I have been thinking recently, and I think I came up with a viable
> solution for packaging this that use maven for building.
> The first problem is that maven will attempt to download jar
> dependencies from a remote repository. This can be avoided by calling
> maven with -o, for offline mode.
> This leads to the question of where, then, to get the jars from. I had
> first thought at build time, we could populate a local repository with
> symlinks to jars that we provide from packages. This would work, and
> could be automated to some extent, but I think it would be tedious to
> maintain a list of jars that each package needs.
Even in the face of such tedium, there is one thing this gives us that
your suggestion does not: the ability to actually check for hidden
If we create a local, minimal .jar environment for each maven-built
package, we know exactly which jars (and therefore which ebuilds) it
In the case where maven itself goes into the system and looks around for
.jars that are there, we may quickly end up with it depending on stuff
we didn't see.
This happens with configure scripts and C/C++ applications all the time.
Most of the time, we can do ./configure --enable/disable, but sometimes
flipping this switch has no effect: it will still automatically
Before abandoning the idea of ebuild-local maven repos, I think we
should be very certain that we're not opening up this Pandora's box of
That being said, a system-wide maven repo that users can avail
themselves of would be great! And AFAICT, it would only need minor
tweaks to the java-*.eclasses.
-- Karl T
email@example.com mailing list