> planetapache.org knows everything :)

Yes, I just caught your post :)

> This is cool.
> -what is the local cache name/layout?

Configurable, defaults to ~/.m2/repository and uses the "default"
layout, which is the new one.

> I'll add maven2 lib support to ant CVS_HEAD and make it the default
> there, same for  Smartfrog; in both cases I'll provide support for the
> old layout somehow too. That'll be a good test of how well architected
> the different classes are -if adding a new repository layout only
> changes one class.

Earlier, there was some talk about whether it would be appropriate to
get Wagon up to release quality and use that. What are your thoughts
on this?

The main limitation is that it currently requires JDK 1.4, which
conflicts with your message:
It doesn't have any additional dependencies (I may have added some
utils, but we can take them back out). I'm pretty sure the API could
be cut back to 1.2 if that is required, though it would be nicer to
keep it. It is possible that it could be an optional feature for 1.4
users... how do you feel about this?

We can move the maven-artifact (or portions thereof) code to Wagon
too. It currently only depends on the container, but I am about to
take a pass at cleaning it up, so I can send the design past here to
see if we are on the same page if you are interested.

Some of the wagon providers require JDK 1.4 and external dependencies
(eg, the httpclient version of the http provider - not the default,
and the SCP implementation). I don't imagine it is a problem to
document this.

As for your other mail:
- classifier is for stuff derived from a single groupId:artifactId
(shares the POM). eg -client for an ejb client, -bin and -src on a
- yes, extension should be able to be null or empty - will fix
- we have really been trying to discourage the absence of a version in
the repository, but we can have that restriction in Maven, not in
maven-artifact if that is what you want.

So, how do we move forward on this?


Reply via email to