On Tue, Mar 04, 2003 at 12:14:01PM +0000, Henning P. Schmiedehausen wrote: > "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> >
Patches welcome. > 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? Stéphane --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
