(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)
> I'd probably retain my own in the Ant codebase, but SmartFrog could
> take wagon -as long as our signing it doesnt break it (smartfrog runs
> a secure classloader for in-JVM code); whoever deploys to an
> infrastructure has to sign every jar with a key they have told every
> running daemon to trust; no central CA. At the very least, I could use
> httpclient rather than the stuff in java.net, stuff that is maintained
> by someone who has clearly never read the HTTP spec.
we're over at wagon-dev@maven.apache.org if you need anything. If Ant
isn't going to use it, I probably won't put as much time into making a
public face for it just yet unless anyone else is interested in
helping out. It works fine, but needs doco, mainly.
> The reason for keeping ant self-contained is
>
> -all the Http download code is already there in the Get task
>
> -If we do it without any dependent libraries, then we can include in
> the core tasks and so be 100% sure all ant installations have it built
> in. We can then use it for bootstrapping
>
> -Although the repository stuff is designed with extra plug in
> repositories, if maven2 was built in, I could make it the default
> layout.
You're welcome to checkout the source code (or just import the
classes) and add it to ant.jar if that'll help. We don't have any
additional dependencies.
However, it's fine if you are happy to continue as is too - we'll most
likely release ant tasks to wrap around maven-artifact to give Ant
users transitive dependencies, snapshot handling, etc. outside of
Maven.
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.
> 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
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).
Cheers,
Brett
