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