Hi Andrew, Let's go back to Maven business... Le 17/09/2014 22:57, Andrew Schurman a écrit : > 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. You mean that a plugin can't be invoked from the command line if the metadata file is missing, right? In this case I think we can live with it. We don't execute many plugins when a package is built, the javadoc plugin is probably the only one. The maven.mk script could be tweaked to replace the javadoc:javadoc argument with the full GAV, it should be easy to fetch the version installed with some shell scripting. > 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. I think this could be done with a trigger. I agree this would be a very nice optimization, but we may do it in a later phase if it turns out to be too complicated. We could just start by generating the metadata when the repository is copied, and do it for the plugins only. Or even simpler, if this is just an issue with the javadoc plugin, we could add the metadata to this package only, we'll never get multiple versions of this plugin in Debian, so a static file is fine in this case (and the metadata file with the prefixes for the plugins under the org.apache.maven.plugins group could be intalled with the maven-debian-helper package as a static file copied from Maven Central). > The metadata might also be used to obsolete some of the > maven-repo-helper logic. What do you guys think? What logic would be obsoleted? If we could leverage the version ranges and get rid of the generic 'debian' and '2.x' versions that would be awesome. Emmanuel Bourg
Attachment:
signature.asc
Description: OpenPGP digital signature