On Tue, 2003-03-04 at 07:14, 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.
It's not flawed, you don't understand it. Then remove snapshot dependencies. They are merely a convenience but your project can decide as a policy not to use them. That is up to your project. You are not _forced_ to use them. > - Make builds completely offline by default. If a jar is missing, die. I don't see any upside to this except inconvenience. And again you can decide this as a policy for your projects. I am working with Vassily to make a group mode workable so there will be a global properties file where you can set the offline mode. But for now you can certainly do this in your project files. > - 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. Again you are not _forced_ to use snapshots. > 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. As a general feature to fetch things from the repository this would be useful. But not for dependencies in general. But there's no downside to allowing any artifact to be fetched. > - 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" Sorry, I don't understand this statement. But there is a marked difference between most recent release and snapshot. There is the ability to convert the snapshots to their most current timestamped version if you wish. > - 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. Most of this is already in place but again your descriptions are vague. > - 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> For historic purposes I haven't gone through the repository and deleted things that don't fit but in short there exists: artifact-<version> artifact-SNAPSHOT artifact-yyyymmdd.hhmmss The first is a release; the second is a pointer to the most current timestamped version; The third is simply a timestamped version used when resolving snapshots or can be used by projects to avoid the snapshot dilemma you speak of which is only the case when you use snapshots across releases. The -dev moniker I've told people not to use forever. This is generally a turbine problem. > 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. I really don't think you get most of these concepts Henning, I really don't. > 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... :-) Say what you like Henning but in conjunction with the many people here who are actually contributing useful feedback most problem will get worked out. The majority of your problems stem from your fundamental lack of understanding and your generally obnoxious behaviour doesn't really lend itself to anyone wanting to clarify any issues for you. Don't wonder why many of us don't answer your questions or generally ignore you. It basically boils down to you being 1) abrasive, 2) obnoxious and 3) highly misinformed. > Regards > Henning > > Jason: BTW: Do you have any traffic numbers from the ibiblio repo? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
