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: long project names & repositories
Date Mon, 11 Apr 2005 12:49:50 GMT
On Apr 11, 2005 12:51 PM, Brett Porter <brett.porter@gmail.com> wrote:
> (I'm assuming you meant to reply to all by the content - it happens
> frequently with other gmail users - sorry if I'm out of place
> repeating your message)

no, that's gmail for you. 

> At the very least we should continue to swap notes, especially when it
> comes to implementing the security stuff so that we have one,
> consistent solution.


> I'm still thinking over the inclusion of the sha1 in the dependency
> definition. The reasoning seems sound, but something about it just
> gives that gut feeling that it isn't the best way to go - maybe it is
> still just the niggling feeling of too much work for the user.

the smartfrog solution is brute force unforgiving: you must declare
the SHA1 or MD5 value in a download

commons-logging-1.02 extends MavenArtifact {
   project "jakarta.commons";
   artifact "commons-logging";
   version "1.02;
   sha1 "4f......2b";

It means to switch you'd need to update both the version and the sha1
together, but that's ok. You cold declare a sub version

commons-logging-1.4 extends commons-logging-1.02 {
 version "1.4";
 sha1 "45facb...";

Then you'd change your references when you run your app

App extends Java {
 packages [commons-logging1.04,.... ];

the runtime would work it all out. For ant, with its property driven
override, its a lot fiddlier.

The reason for sha1 emphasis is primarily that md5 is doomed: its too
easy to break, 2-5 years left in it before it is as trusted as DES.
Now, when it is finally broken, .rpm is the first juicy target. But
md5 is old; it would be good if maven2 had .sha1 everywhere right from
the outset.

> > I see.
> >
> > One more question regarding m2 names
> >
> > You map a project name of "org.apache.axis" to org/apache/ant. What
> > about artifact names. I've been defaulting to assuming
> >   if (artifact==null) { artifact=project}
> >
> > but if project is now dotted, should I default to the last element of
> > the project name? Or require an artifact name if the project is
> > dotted?
> I don't quite understand this - sorry. We have groupId and artifactId
> which combine to be globally unique (where artifactId is unique within
> a single groupId). Only the groupId is modified - if the artifactId
> had a '.' then the name would remain the same, ie:
> org/apache/ant/ant.optional/1.6.3/ant.optional-1.6.3.jar

OK. And the artifact ID is compulsory. 

> To ease confusion, perhaps we will probably make . and / illegal in
> the artifactId (along with anything else note valid or desired in a
> path name - spaces, for example).

yes. a legal string of valid names would be good, better than an
exclusion list (as there are so many characters in unicode land. For
x-platform support, that means lowercase ascii alphanumeric plus a few
separators for all of the different elements:


The weakness here is that it doesnt address the wants/needs of the
non-ascii world., but since we are constructing HTTP URLs from the
strings, we need to use that subset, not just those chars that are
valid in filenames.

View raw message