Thanks,

We'd have to do some consulting with the Ibiblio folks, they have a 
policy of not allowing rsyncing with deletions, they prefer to maintain 
archival copies of everything.

We also need to consider how we will approach snapshots vs version 
releases.  The current strategy I'm proposing is the following:

A.) Version Releases

/www/www.apache.org/dist/java-repository

/www/www.apache.org/dist/ is only for versioned releases (because its 
mirrored). This repository likewise should only be for versioned releases.

b.) Daily Builds

/www/cvs.apache.org/builds/java-repository

because /www/cvs.apache.org/builds/ is reserved for developer builds. 
This repository will be for daily snapshot builds. I'm proposing we look 
into using gump and ant/maven to automate this.

c.) Archives

/www/archives.apache.org/dist

when Versioned release are retired from /www/www.apache.org/dist they 
end up here, this is automatic, this is basically a non-delete mirror of 
"dist".

---

The idea behind this layout is the following. Apache Developers are far 
more dependent on keeping up with other Apache projects in their daily 
build strategy. By supplying an automated daily build repository, Apache 
Developers can always be sure their testing against the latest snapshot 
of another Apache project.

However, those in management of the mirrors are concerned about 
populating the mirrors with snapshot build contents. For (1) it places a 
heavy load our servers and those mirroring us, and (2) Its been a policy 
at Apache that only full versioned release get mirrored.

My opinion as well is that Non-Apache projects would probably be less 
interested in being on this bleeding edge of development, having their 
efforts always be subject to the interim fluctuations in daily build 
snapshots. On top of this, I would suspect that Apache projects probably 
do not want external projects dependent on such bleeding edge builds 
because of their lack of stability at that point.

Because only /www/www.apache.org/dist/java-repository is mirrored to 
ibiblio, only versioned releases get exposed through the default maven 
repository settings. Apache developers who wish to be testing against 
the "bleeding edge" only need to add this repository location to their 
maven configuration

maven.repo.remote = 
http://cvs.apache.org/builds/java-repository/,http://www.ibiblio.org/maven/

So, with this strategy in mind, it is actually possible that the daily 
build snapshots would never end up at ibiblio, but still be totally 
available to Apache Developers for testing against.

what you think?
-Mark

__matthewHawthorne wrote:
> Mark R. Diggory wrote:
> 
>> rsync is now active between apache and www.ibiblio.org/maven every 4 
>> hours.
>>
>> minotaur.apache.org:/www/www.apache.org/dist/java-repository
>>
>> contents are now rsynced directly to
>>
>> www.ibibilio/maven.
>>
>> by ibibilio.
>>
>> This means anything you place into java-repository will be available 
>> through maven within 4 hours.
> 
> 
> 
> First off, this is great.  Thanks Mark, Jason for getting this going.
> 
> Secondly, does ibiblio do anything to handle "cleaning" old snapshots? I 
> don't think that Maven can do this.  Would it make sense for the rsync 
> to delete things from ibiblio that aren't in the Apache repo?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe <at> jakarta.apache.org
> For additional commands, e-mail: commons-dev-help <at> jakarta.apache.org
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu