www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <steve.lough...@gmail.com>
Subject Re: Maven and repository@apache.org
Date Thu, 06 Jan 2005 14:27:25 GMT
On Wed, 5 Jan 2005 17:21:03 +0800, Niclas Hedhman <niclas@hedhman.org> wrote:
> On Wednesday 05 January 2005 16:39, Nicola Ken Barozzi wrote:
> > The Depot project SVN
> > is still there, ready to be used if/when needed by the Maven project.
> 
> From the Magic project we have spun off what we call Transit, which provides a
> simple, flexible and powerful solution to artifact management and handling.
> 
> One of the most simple APIs one can imaging :o)
> By putting the transit jar in system classpath, the most rudimentary use is;
> 
>   URL url = new URL( "artifact:jar:junit/junit#3.8.1" );
> 
> which will return a cached artifact, downloaded from configured resource hosts
> out there.
> The resource hosts can be of different types (i.e. not only the maven
> organization), and the cache manager is also pluggable.
> Downloads over https is supported, as well as server authorization, but we
> still have not implemented certificate management and trust establishment,
> but is in the pipeline.

I think for the base repository, simplicity is good. I'd like to see
what simple improvements we can do to the existing maven system,
performance and security being the ones that matter to me. I even
worry about XML manifests at the top of the tree, as the nice thing
about the maven layout today is that a downloaded repository exactly
matches the remote one; its easy to create a local mirror site.

That said, Transit appeals to me as a way of adding URLs to the
UrlClassloader and suddenly giving us access to those versions of
those files that are served by nearby machines. Which lets you provide
a declaration in your favourite deployment language of what JARs you
need, and then *wherever* you deploy, you get the stuff you want.

This interests me in my day job, which is deployment of complex
applications onto grid fabrics, working on the (LGPL) SmartFrog
project (http://smartfrog.org). We use the URL classloader with
security turned on to effect some of the dynamic code download stuff
in that system, stuff RMI needs (for code download it needs both ends
of the system to be downloading stuff from the same URL). Transit
could make a difference there for fault tolerant deployment,
distributed JUnit and other fun things I try to do.

If there was some work going on in this area, I could perhaps get
involved with daytime engineering hours. Plus with access to
PlanetLab, we have a good test harness.

-Steve

Mime
View raw message