Hi,
I wanted to discuss some changes I'm checking into maven-shared and the
maven-remote-resources-plugin, to see whether anyone had feedback to offer.
First, the basic problem: The remote-resources plugin only generates a
DEPENDENCIES file (using the apache resource bundle) for dependencies in
the current project. When we build a multimodule project like doxia or
wagon, this means that the DEPENDENCIES file at the top - the one that
will wind up in the source-release assembly, and could wind up in a
whole-tree binary distro - is missing dependencies that are only
declared in modules. Since most dependencies are declared in
dependencyManagement high up, and only declared in the main dependencies
section where they are used, this means the parent project's
DEPENDENCIES file will miss most of the dependencies used by the project
as a whole.
To address this, I've started work on a maven-artifact-resolver project
in maven-shared. It's using replicas of fairly stable interfaces that
have been in maven trunk (3.x) for some time now, and I plan to keep the
two copies of the interfaces in sync. This should allow Maven 3.x to
filter out maven-artifact-resolver, and allow plugins that use it to
simply use the built-in interfaces/components instead.
The goal here is to provide something as close to single-line usage for
the plugin developer, whereby he can resolve the dependency closure for
a project or collection of projects, using a variety of scopes. It's
meant to be as simple as possible, to avoid all of the inconsistencies
that have resulted from implementing this sort of functionality in
places like the assembly plugin (which still has tons of trouble with
managed dependencies).
I have a working implementation that I just checked in (revId 808474,
and there are a couple more revisions I'll be adding shortly), but it
currently depends on Java 1.5. This means that any plugin using it will
have to declare a prerequisite on Java 1.5, and Maven users on 1.4 and
lower will not have access. I'd really prefer to leave this requirement
on 1.5 in place, to help us gradually pull ourselves out of the JDK 1.4
tarpit.
Are there any serious objections to leaving this in place? Does anyone
have anything else about this general approach they'd like to know more
about, or suggestions they'd like to make?
Thanks,
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
