Re: Subversive Repository

2004-09-30 Thread Nicola Ken Barozzi
Mark R. Diggory wrote:
Here's a thought that has been propagating through my neurons.
What if the ASF Repository content was maintained in Subversion and 
exported into dist/java-repository for mirror propagation using some 
automation? Given Subversions binary diffing, this would be manageable.
:-)
Are two jars that differ slightly actually not that different?
I had brought this up on this list in "Making releases -> publishing 
jars". Below is a relevant reply.

 Original Message 
Subject: Re: Making releases -> publishing jars
Date: Wed, 17 Mar 2004 15:32:14 +0100
From: Nicola Ken Barozzi <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Noel J. Bergman wrote:
>>1 - people making releases have to log into the release server
>>2 - there is no notification of files being put there
>>3 - we are already experiencing issues with where to put jars
>
>>What if we make instead a SVN repository for releases?
>
Isn't that a bit heavyweight when all you appear to want is WebDAV
with access control and notification?
Point taken.
I just had an interesting chat with Sander about adding features to
our WebDAV support. He seems to think that it would be fairly easy to
add hook and authz support, so that authorizing access to a file
system area would be
the same as we use for SVN. Also, we'd have hooks that could perform 
actions when changes are made.
This would be zuper.
...
>>like for example publish the jars in a parallel
>>structure that is used for the maven repo.
We've really got to work on eliminating the adjective there, and I
applaud Mark's efforts to do so.
I do too.
Sorry, I have not helped much. Where do we stand now? What can I help to do?
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


Re: Subversive Repository

2004-09-29 Thread Brett Porter
Hi Mark,

Interesting idea. Doing this always makes me feel a little uneasy,
though given the reasons you've listed I can't think of any problems
other than a gut feel.

I guess the reason for that is that JARs really shouldn't be changed
once published. The exception is snapshots (not even timestamps, just
the ones file that constantly gets overwritten with latest).

I'm ok with having an SVN artifact handler written for Maven (only to
deploy, not to retrieve though). If we want to continue that path,
then I'd like to bring it up with the other Maven developers though.

But I'd also like to be able to develop a best-practice solution for
handling a file system repository (after all, the Maven project is all
about making best practices easy :)

An idea I've heard in the past that might be worth reviewing is having
separate SNAPSHOT and release repositories. On download, we can
provide a common view using a repository front end or even Apache
rewrites, or have clients specify both.

The release repo might include timestamped builds, though I'd hate to
get stuck with the Jelly situation again where a 1-year old nightly
became the defacto latest release :)

If this separation was the case, the release repository could have
much tighter controls: the original publishing user could have the
only write permission for example.

Cheers,
Brett

On Wed, 29 Sep 2004 12:13:31 -0400, Mark R. Diggory
<[EMAIL PROTECTED]> wrote:
> Here's a thought that has been propagating through my neurons.
> 
> What if the ASF Repository content was maintained in Subversion and
> exported into dist/java-repository for mirror propagation using some
> automation? Given Subversions binary diffing, this would be manageable.
> 
> 1.) This would allow us to control permissions at the same level as the
> cvs/subversion source control. As such:
> 
> Jakarta Commons Jelly
> 
> and
> 
> Jakarta Commons Collections
> 
> would have enough fine grained permissions to control to separate who
> gets the right to add/remove/modify content at that level instead of
> what we have right now, which are only the groups in the shell (ie xml,
> jakarta etc).
> 
> 2.) This would give us a layer (automated update of
> dist/java-repository) to catch issues such as:
> a.) md5 and signature errors.
> b.) dated-build vs full version releases.
> 
> The downfall is that Repository Clients (Like Maven) would need to be
> capable of doing svn commits etc to publish artifacts instead of ssh/scp
> requests.
> 
> -Mark
> 
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>