On Apr 11, 2005 12:51 PM, Brett Porter <[EMAIL PROTECTED]> 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.
yes.
>
> 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:
[a-z0-9.-+_]
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.
