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? Cheers, Andrew 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 > > > > >
signature.asc
Description: This is a digitally signed message part
