MRRESOURCES-41 and project-resolution API

[John Casey <jd...@commonjava.org>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: MRRESOURCES-41 and project-resolution API

[Daniel Kulp <dk...@apache.org>]

The sooner we can start typing the collections so I know what's actually in 
them, the better, IMO.    :-)

Dan


On Mon August 31 2009 12:41:33 pm Brian Fox wrote:
> Ok here.
>
> On Fri, Aug 28, 2009 at 7:40 AM, Benjamin
>
> Bentmann<be...@udo.edu> wrote:
> > John Casey wrote:
> >> I have a working implementation [...] but it currently depends on Java
> >> 1.5. [...] 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.
> >
> > +1
> >
> >
> > Benjamin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: MRRESOURCES-41 and project-resolution API

[Brian Fox <br...@infinity.nu>]

Ok here.

On Fri, Aug 28, 2009 at 7:40 AM, Benjamin
Bentmann<be...@udo.edu> wrote:
> John Casey wrote:
>
>> I have a working implementation [...] but it currently depends on Java
>> 1.5. [...] 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.
>
> +1
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org