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 repository policies
Date Sun, 31 Jul 2005 19:04:46 GMT
On 7/31/05, robert burrell donkin <rdonkin@apache.org> wrote:
> On Fri, 2005-07-29 at 12:34 +1000, Brett Porter wrote:
> > On 7/27/05, Phil Steitz <phil@steitz.com> wrote:
> 
> <snip>
> 
> > > > 6) all files in the /dist/ repository must have a .asc signature. We
> > > > will need to get this automated by the final release of Maven 2.
> >
> > > What about KEYS?
> >
> > Yes, standard distribution rules. I'm not sure if we need that in the
> > repo or just a URL from /dist/ at large - will see what comes of
> > commons-openpgp.
> 
> just FYI there was a feeling at apachecon from the infrastructure movers
> and shakers that KEYS files were an transitional expediency and that
> they would be removed at some point in the future.
> 
> BTW one of the neatest ideas i heard was to use the md5 sum to find the
> right release.
> 

yeah, I've looked at doing that...its effectively what .NET does with
the Global Assembly Cache and its 'strong names'. When you compile
something in .net it records the sha1 checksum of the lib you built
against, and that is what it tries to load later, by default looking
in the local path first (unlike JNI on windows, which uses
::LoadLibrary and not ::LoadLibraryEx for DLL lookup with a modified
path)

the GAC is an attempt to offer shared libraries without the
brittleness of the past, because you would always get the version you
built against; it is impossible to contaminate the GAC with a
conflicting version,


However, after spending some time with .net developers recently, I am
aware of two consequences of this design.

First, strong names suck during development. If you have a many
library project, you need to rebuild all apps when you change a
library if the app is using the strong name to match it. Its just too
strict.

Second, the GAC itself is having fun moving into the longhorn
timeframe. I cannot confirm this as I still have 1h29 of my 22hour
longhorn download to go, but believe they had to bend the rules a bit.
The apparent problem is that the net 1.x binaries needed changing to
integrate with .NET2.0 and longhorn, which means the base .net
binaries you get are not the ones you ask for by presenting their SHA1
key to the GAC. So i guess they have added redirects to the GAC , thus
breaking the whole "you get the library you ask for by its checksum"
rule, because that rule no longer held.

In Java, we have two other problems

1. adding this stuff on as an afterthought is hard. You will end up
asking for checksums over the phone; its a lot easier to tell if
log4j-1.2.8 is newer than log4j-1.2.9.

2. the checksum of a JAR changes after it is signed. If you adopt
checksum-only binding, you need to sign before binding. Yet things
like webstart expect everything signed, usually a late-binding
operation just before you ship.

-steve

Mime
View raw message