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

Absolutely - all I meant was that Wagon maintaining its own Ant task
was probably not necessary given that. Wagon can plugin in to that.

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

I agree.

> 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.

Can you elaborate on how it was integrated into Eclipse and Netbeans?
I assume this would be when you add a dependency to a project - if so,
that's definitely something that has been talked about (the MevenIDE
project may have already done this - I'm not sure), and could use what
was in depot to do so.

> 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.

Right. It wouldn't even be maven.jar - just a smaller JAR that does
the repository and snapshot handling. It's definitely separate.

> > Out of interest, this is the proposed future repository layout for Maven:
> > http://docs.codehaus.org/pages/viewpage.action?pageId=8003
> 
> 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)?

I don't think discussing the repository format is helpful at this
point - it is a big undertaking to change and I think there are other
priorities (security, mirroring and cleanup). That seems to be where
this list got bogged down last time, though what is there now looks
pretty much final. When it's not so late, I'll look at what is
actually different and whether this is even an issue.

The repository code can have different repository layouts, so if
necessary we can support different ones. Obviously, its preferable to
agree and be consistent.

Eventually it will make sense to cutover to a new layout - but we'll
want to ensure everything is in place first.

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

That's interesting - being involved with a sourceforge project they
prefered to release to a maven repository and not use sourceforge :)

That's a good feature, though probably at the bottom of the list so far.

> 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.

Great.

Cheers,
Brett

Reply via email to