Hi Mark,

Thanks for the response.

> This is probably why you have so much trouble:  two package managers
> fighting for control.

I don't really think of Maven as a "package manager" but rather as a
structural tool, which should help make Portage's job _easier_, not harder.
Maven documents how the package dependencies are organized, and also makes
the actual build trivial (unless the Maven project in question requires
something non-standard, of course).

> The middle path might be:  package the dependencies individually, work
> out a way for Maven to see them as being present in the local
> repository, build the dependent happily using Maven.

Right, that is what we were discussing already on the linked issue thread.

> I don't know the guts of Maven well enough to say how hard it would be
> to plug in a new local-repository provider that uses the Gentoo
> /usr/share/*/lib layout.

We could do that, sure. Or we could just cheat with symlinks, to
manufacture a transient, lightweight local repository in a shape that Maven
knows already. :-)

The main question I have is about Maven plugins: since Maven builds do some
bootstrapping, but Gentoo builds are not supposed to download things from
the network, it means we might need a pre-baked Maven local repository
containing all commonly used plugins at various release versions? If so,
that would be unfortunate. I was hoping for some insight from others here.

> Binary dependencies are going to be a royal pain no matter how you do
> them.  Ugh!

Well, they need to be built from source. If they are cleanly Maven-based,
then we do things recursively the "easy" way. Otherwise, we need a custom
build script for each dependency with custom build requirements.
Dependencies which are too arduous to build from source will kill
downstream potential for inclusion with Gentoo, but that's always/already
true for a 100% source-based distro.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Mon, Mar 20, 2017 at 8:45 AM, Mark H. Wood <mw...@iupui.edu> wrote:

> On Fri, Mar 17, 2017 at 02:11:20PM -0500, Curtis Rueden wrote:
> > I am currently discussing on GitHub with one of the Gentoo packagers the
> > possibility of packaging my group's Maven-based projects for Gentoo.
> >
> > The relevant issue is here:
> >      https://github.com/imagej/imagej/issues/162
> >
> > However, the issues are hardly unique to my projects. This has become a
> > very general discussion of rebuilding and packaging Maven projects.
> >
> > My questions are:
> > * Does anyone here use Gentoo?
>
> I do.
>
> > * Has anyone packaged their Maven-based stuff for it?
>
> No, I haven't contributed any packages to Gentoo yet.
>
> > * Does anyone know of a _general_ process for doing so?
>
> Typically a Gentoo package specifies all of its dependencies as Gentoo
> packages, and Portage does the dependency management.  This is
> probably why you have so much trouble:  two package managers fighting
> for control.  The "Gentoo Way" would seem to be:  first package all of
> the dependencies individually, get them into Portage, then add the
> dependent, adjust the POM to assume all dependencies will be supplied
> at runtime, and let Portage calculate the classpath.  Ick.
>
> There are some Gentoo packages based on projects which for some reason
> cannot or will not use stable releases of their dependencies, but
> instead package all of the source for those dependencies with the
> dependent code.  It's grating, but it works.  This is probably the
> easier route when using Maven in a Portage environment:  ship
> everything as subprojects and build it all together.
>
> The middle path might be:  package the dependencies individually, work
> out a way for Maven to see them as being present in the local
> repository, build the dependent happily using Maven.  I don't know the
> guts of Maven well enough to say how hard it would be to plug in a new
> local-repository provider that uses the Gentoo /usr/share/*/lib
> layout.
>
> Binary dependencies are going to be a royal pain no matter how you do
> them.  Ugh!  One thing this means is that your package can never exist
> for any architecture that the binary is not built for.  That's sadly
> not without precedent.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Reply via email to