Brett Porter wrote: ...
Wagon's scope is really only transport though - uploading and
downloading through a variety of providers with a common Java API
(there was also an Ant task at one point - though since Ant have
developed their own there is little point in updating the wagon one).

I disagree here.

Ant is adding a task so that providers can plug into it, and Wagon can continue to be used in Ant.

If we splinter implementations, the repository effort will always be half-baked, and acceptance will suffer.

MD5 hashing is handled, and I'd like to add PGP signing obviously.

However, the repository layout code is no longer in there. It is in a
separate component of Maven, so there can be some discussion on our
end about whether that really makes it part of the Wagon project, but
not the Wagon API. That's really administrative more than anything.

What interests me WRT repository is that it's possible for Ant users to install an antlib that makes Wagon usable in Ant, and for Eclipse and Netbeans users to be able to integrate it nicely in their artifact stuff. Depot had an Eclipse pluin BTW.

If this means that we also need a maven.jar in the classpath, I have no problem with it, as long as users are not forced to run maven itself to download the artifacts.

The Depot project SVN
is still there, ready to be used if/when needed by the Maven project.

I'll take a look, thanks. Is there any doco available on what depot's advantages were, why it came into being and why it eventually closed?

(Update was caller Ruper)

Thus I would add that the [EMAIL PROTECTED] list and wikis should
support and point users to the Maven repository handling code.

Does this sound reasonable?

Sounds good to me.

I'll try and get my thoughts together and onto the wiki soon. I
noticed several requirements are missing, and the road map is probably
out of date.

Out of interest, this is the proposed future repository layout for Maven:

Any recommendation on how to move on from there, keeping in mind that there are already two wikis with different specs and two different lists ([EMAIL PROTECTED] and this one)?

From what I remember, it takes into account all of the points raised
on the ASFRepository wiki layout document.

The extra features needed are Apache mirroring support and use of the Sourceforge system without needing to recreate a repository, that Depot somewhat supported.

I'm fine with the proposed layout, or any other reasonable alternative, as it does not interfere with the above, being still http and file based.

Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Reply via email to