Re: advance notice - PL/Java 1.5.0 is in beta - Mailing list pgsql-pkg-debian

Hi Christoph,

On 02/04/16 09:04, Christoph Berg wrote:

> Debian wants to be self-contained, which means we don't want to
> download stuff from external sources.

Hmm ... there's a puzzle here, this is a sensible enough policy on
its face, but where it comes to maven-based builds and build-time-
only dependencies, depending on how it's interpreted anyway, it seems
on a direct collision course with the exact way maven is designed
to operate. I am surprised if it has not seemed to cause trouble before
PL/Java.

> At least for the plexus-utils dependency, it looks like pljava is
> trying to use something that is older than what we have packaged in
> Debian. Maybe you could relax that?

This is a good illustration of the problem. pljava does not have
any direct dependency on plexus-utils. That's a transitive dependency
from some build plugin pljava does use. In fact it's probably a
transitive dependency from *several* plugins pljava uses (plexus-utils
being a library plugins would frequently use).

So you see there might be several different plugin authors I could
approach and say "debian only packages plexus-utils 1.5.15-4 and
they block maven from using the repo, so they'll never be able
to build *my* project unless all of you can please update *your*
projects simultaneously so that 1.5.15-4 is the exact version of
plexus-utils that all of your projects depend on, and then everything
will kind of work until the next time debian changes the one version
they happen to provide, could you please do that for me thank you?"

But the thing is--this is really important--*that is the exact
problem maven's design purpose was to never have*. The author of
every artifact and plugin is encouraged, as a best practice, to
specify each dependency with the version number that he or she
knows to work. Maybe some later version is all improved and also
works, maybe it isn't, maybe it breaks something if Maven unexpectedly
substitutes it. Some day each dependency author might evaluate a later
version and decide that it works too, and then update that dependency
version in their pom. There won't ever be a single day when the authors
of all plugins get together and do that and agree on the same one
dependency version that there happens to be a .deb for.

If I run a PL/Java build here starting with an empty local repo, and
collect the mvn -X output, I see that it downloaded the .pom files
for 22 different plexus-utils versions from the central repo.
Based on its own resolution analysis, it then downloaded 10 different
plexus-utils-*.*.jar files. It wrote 54 plexus-utils related
resolution tracking files.

All of that is exactly what Maven normally does, to solve a complicated
transitive dependency problem that we'd be insane to try to do by hand.
That's what makes Maven Maven. To try to apply a policy that says "maven
can't use the repo, we will solve all past/present/future dependency trees
by thinking about them, then settle on the 'blessed' subset of repo
artifacts that we will have .debs for and somehow things will work"
is going to be like cutting William Tell's arms off and then wondering
why he can't shoot straight.


But can all this be looked at another way?  What does "Debian wants to be
self-contained" really mean? This is all _build-time_ dependency management
we're talking about here, something that happens on a build server
somewhere, none of it changes the self-contained experience of a debian
installation where the generated .deb will be used.

My suggested approach on the build server would be, make whatever container/
tmpfs arrangements you want, point there for an initially empty maven
repository, sit back and watch maven go to town, then pluck the final
pljava-*.jar file out of there and throw the container away. Make a .deb
out of the jar file. It has exactly two dependencies as far as installation
is concerned: it will need PostgreSQL, and it will need Java. :)

I'm sure PL/Java will not be the last or only Maven-built artifact
that might become available for debian. The build approach I've suggested
here is really the only way I can see to approach it that seems at all
promising....

Cheers,
-Chap