[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: maven-debian-helper to maven3

Hey guys,

I'm now able to create a deb package of the maven-debian-helper, built
using itself. But the javadoc issue that I had trouble with before is
more serious than I first thought. It appears maven 3 is unable to
resolve plugin prefixes without metadata xml files in the local
repository which the debian repo does not have. We'll need to either i)
specify the full GAV when executing a plugin as a target as opposed to a
phase. This is not really desireable since you would need to hardcode
plugin versions in the maven-debian-helper or have a method outside
Maven to determine them. This also has implications for all existing
packages which depend on the maven-debian-helper. Or ii) generate the
metadata xml files for the maven repo.

I think (ii) is the way to go. They can potentially be generated when
copying the debian repo while building the deb, but I think they will be
more useful if included in the debian repo proper. This way, you could
use the debian repo as an actual remote repo if you wanted to. This
could potentially speed up creating a deb file as you could let maven
download (copy) only the dependencies it needed rather than copying the
entire maven repo. Of course, the settings would need to be configured
online and with the single (local) debian repository which mirrors all
other repos (effectively offline mode). The only problem is the metadata
contents. They span multiple versions so can't be static files in the
deb. For example, I have org.apache.maven:maven-core with 3 versions on
this system (2.2.1, 3.0.5, 3.x) which are not all part of the same deb
package. I think they may need to be created using a deb post install
hook or something. I'm not sure how you would do the initial update of
existing artifacts in the repo though.

The metadata might also be used to obsolete some of the
maven-repo-helper logic. What do you guys think?


On Sat, 2014-09-06 at 15:40 -0700, Andrew Schurman wrote:
> On Sat, 2014-09-06 at 10:51 +0200, Emmanuel Bourg wrote:
> > Hi Andrew,
> > 
> > Thank you for tackling this issue.
> > 
> > Le 06/09/2014 06:53, Andrew Schurman a écrit :
> > 
> > > I've been taking a look at what it would take to update the
> > > maven-debian-helper package to use maven 3 [0]. This includes all the
> > > changes that I made manually to test that maven 3 could work with some
> > > packages with minimal changes as well as a few extras. I've used the
> > > assumption that maven3 will completely replace maven2 rather than
> > > supporting both. For most projects, this should be a valid assumption.
> > 
> > I agree, we should aim for the removal of Maven 2 in Jessie+1.
> > 
> > > Unfortunately, it isn't yet able to build a deb package because
> > > debian/rules uses ant to build which uses a custom classpath filled with
> > > maven2 dependencies; it fails to resolve maven3 dependencies. I see 2
> > > solutions:
> > 
> > What about updating the classpath with the Maven 3 dependencies? Would
> > that work?
> Since a lot of the build is generated as part of the ant helper, it's
> not that simple. See below.
> > 
> > > 1) Get maven-debian-helper to use itself to build (and hence use maven3
> > > internally to build). This will then use the libraries included in maven
> > > itself, rather than packaged dependencies, and would therefore change if
> > > the version of maven changes. It seems this was tried before (in part?)
> > > and removed in 5e4fa2b4.
> > 
> > I like the idea.
> I'm more inclined to use this solution as well.
> > 
> > > 2) Break up/extend the maven package so its dependencies are available
> > > in a format maven-ant-helper expects, i.e. debian-versioned poms. This
> > > will mean the package will be build with maven2 until the
> > > maven-ant-helper is updated, but shouldn't be an issue as long as it
> > > builds.
> > 
> > How should the maven package be modified to achieve that?
> Since the current build is using the ant helper, it expects debian
> versioned dependencies, i.e. maven-core with the version debian. It
> seems only the maven 2 dependencies are versioned this way, i.e.
> libmaven2-core-java, while maven 3 dependencies are embedded in the
> maven 3 package without supplementary debian versioned poms. For this
> solution I'd expect all the maven 3 dependencies be amended like the
> maven 2 ones, either as separate packages or in the maven 3 package with
> additional debian versioned poms.
> I'm not a big fan of this solution because it's more work to maintain.
> This will also need some thought so that it doesn't break when maven 3.2
> gets packaged.
> > 
> > > One thing to note: there are failing unit tests in the
> > > maven-packager-utils module, which were failing before my changes. I'm
> > > not sure if this is just my machine or an actual failure.
> > 
> > I have a test failure too:
> > 
> > Failed tests:
> > testInstallJarToRepo(org.debian.maven.plugin.InstallMojoTest): Resource
> > /plexus-compiler/debian/libplexus-compiler-java/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler-test/1.x/plexus-compiler-test-1.x.jar
> > not found in the classpath
> >   testInstallJarToRepoAndUsj(org.debian.maven.plugin.InstallMojoTest):
> > Resource
> > /plexus-compiler/debian/libplexus-compiler-java/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler-api/1.x/plexus-compiler-api-1.x.jar
> > not found in the classpath
> That's odd. I'm seeing different test failures in
> org.debian.maven.packager.DependenciesSolverTest. Specifically
> testSolvePlexusActiveCollectionsDependencies and
> testSolveBuildhelperPluginDependencies. Both fail because the
> maven.Depends is not setup correctly in the substvars file. It looks
> like they both call out to dpkg which means they rely on state outside
> of the test. This doesn't make them good tests.
> I found one was introduced in 14064dfc, but the other appears for quite
> a bit longer.
> > 
> > 
> > Emmanuel Bourg
> > 
> > 

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: