"Stanley,Michael P." <[EMAIL PROTECTED]> writes:
>decisions that were made, are explainable). I *DO* care about the
>future roadmap! I'm not throwing mud, I'm trying to help.
>Maybe Jason didn't see this before, maybe he sees it better now, maybe
>it was articulated poorly before, maybe it still needs to be explained
>better, whatever the case lets just keep the discussion technical. If
>someone doesn't agree, convince them. If you can't, don't whine, keep
>trying, or fork off ;-)
What I'd like to see
- getting rid of the "SNAPSHOT" concept. This is fundamentally flawed.
Lets check at every build process whether "there is a newer jar in the
repository" is bad.
- Make builds completely offline by default. If a jar is missing, die.
- Have a switch doing a "closure" which does explicit download of all
missing jars at that point. Then you have a set of jars in your local
repository, which can be used to build. You have a reliable set of
jars to be able to test a local change. If the build breaks, it was your
change and not some developer uploading a newer "snapshot" version while
you were not looking.
If something needs a "newer" jar, either run this closure switch again or,
even better, maybe have
% maven --update <artifact-id>, e.g. maven --update commons-collections
which then pulls the most current release from the repository.
- get rid of the "symlink" concept on ibiblio. If you need a newer
version of the jar, you're willing to wait. Let maven check all existing
versions of an artifact and "get the newest"
- add a "manifest" file to each jar directory. This is managed at upload
time and can be downloaded by maven to get md5 sums, current versions
available and other meta information. Get an upload application / tool.
- finally do a _clear_ definition of the semantics of
artifactid-a.b
artifactid-a.b-yyyymmdd-hhmmss
artifactid-a.b-dev
artifactid-SNAPSHOT
look e.g. at the commons-collections directory. There is
commons-collections-2.0.20020914.015953
commons-collections-2.0.20020914.020746
commons-collections-2.0.20020914.020858
commons-collections-2.1-dev.jar
which one should commons-collections-SNAPSHOT map to? IMHO
it maps to the wrong version. 2.1-dev is newer than 2.0.<something>
After you get _these_ things nailed down, you can even start to think
about replicating or clustering maven repositories. I'm really scared,
thinking about a _really_ popular project which is used by thousands
of developers starting to use maven. Think Tomcat.
Jason often talks about how he does not like "half-assed"
approaches. I let it to your imagination what my opinion about the
current maven repository structure is... :-)
Regards
Henning
Jason: BTW: Do you have any traffic numbers from the ibiblio repo?
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
