Jose Gonzalez Gomez wrote:
> 2005/12/15, Joshua Nichols <email@example.com
> On Wed, 2005-12-14 at 19:39 +0100, Karl Trygve Kalleberg wrote:
> > 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
> > > 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
> > dependencies.
> > If we create a local, minimal .jar environment for each maven-built
> > package, we know exactly which jars (and therefore which
> ebuilds) it
> > depends on.
> > 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
> > 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
> > flipping this switch has no effect: it will still automatically
> > autodetect stuff.
> > 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
> > bad mojo.
> As I mentioned, we could do sanity checks. The project.xml of the
> project lists EVERY dependency of the project. So, we could parse this
> file and know what jars will be used from the local repo. We can check
> if the jar's symlink is valid (the package is installed), and
> based on
> where it points to, you can figure out what package it comes from, and
> consequently check that this package is in DEPEND or RDEPEND.
> This is true no more for maven 2.0. They have added transitive
> dependencies to the project building, so now you only list in the
> project descriptor ( pom.xml) the direct dependencies and their scope.
> Maven takes care of reading project descriptors of those other
> dependencies from the remote repository and builds the whole real list
> of dependencies. So I think such an approach wouldn't work for Maven2.
You are correct. With some work though, I think it could work. We could
mirror the pom.xml's in the gentoo maven repo. Then we could check the
dependencies the immediate package has, at the least.
> Have you thought of patching the maven sources to intercept dependency
> resolution and download and do something like calling emerge? I
> haven't taken a look at maven sources, so I don't have any idea if
> this is really feasible, or I'm just babbling.
It has been thought of in the past. Of course, just saying, 'hey, let's
patch maven to do it!' is a lot easier than actually getting it working.
The place that we'd want to get control, if you would, is the point
where dependencies get downloaded. Given that the maven infrastructure
is all about plugins for extending functionality, you'd think it'd just
be a matter of writing a plugin in. I've spoken with some of the folks
in #maven on irc.codehaus.org, and apparently it wouldn't be quite that
firstname.lastname@example.org mailing list