Wayne Fay wrote: > > On 4/21/07, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: >> So if I say <quality>BETA</quality> then no alpha bundle (a bundle >> containing alpha software) will be selected. > > Who exactly decides what the quality is for a given release? Outside > of a handful (literally) of major apps/projects (Linux kernel and > Apache webserver come to mind), very few seem to have a good sense for > this, and I'm not even positive I'd totally trust myself with that > decision for code I'm working on at times. We already have enough > trouble getting projects to provide us with very basic poms, much less > providing full poms with these kinds of details. So right off the bat, > this sounds like a losing proposition for 95% of the projects in the > wild. > > Also, what happens when I specify <quality>BETA</quality> and depend > on artifact xyz which brings in xyz-1.0.2-BETA which has a dependency > on artifact abc-2.0.1-ALPHA? Will you expect Maven to pick xyz-1.0.1 > (final) which depended on abc-2.0.0 (final) since it can't satisfy all > transitive requirements with BETA quality code? This just doesn't seem > manageable for anyone... > >
You bring very good points indeed, my first answer is that we should start simple ;-) So let me explain my evolving thoughts... Notice I mentioned "bundles" and not "artefacts". To me a bundle is for example all the plugins build by the maven core project itself. As part of the release on maven 2.x.y you guys should release maven 2.x.y plugin bundle, which should specify a quality level of lets say "RELEASED". Maven 2.x.y should by default require a maven-plugin-bundle with version "[2.x.y,)" and quality "RELEASED" or maybe "BETA" (if you think users should try being more adventurous). Now you ask, what is a bundle? A bundle is a collection of plugins that have passed some testing process and are found to work well together. And its quality should indicate how stable the artefacts on the bundle are considered to be. The idea of the bundle is that when maven decides to upgrade you to a newer level it will do it not based on one artefact at the time but based on a collection of artefacts that were certified to work well together. The versions of artefacts specified in the bundle will be used, unless the artefact dependency declaration specifies an specific version. Other big projects (reputable) projects or corporate entities may define their own bundles and define what they think is "ALPHA", "BETA", "RELEASED" or whatever level names you decide to use. What happens if more than one bundle mention the same artefact at a different version, I have no clue. But you already deal with this issue in the case of transitive dependencies causing a conflict. I guess the rules should be similar. Now, you still can use an artefact that does not belong to a bundle, but in such a case I would suggest that best practice should be for the user to specify at least a version range so he/she is not taken by surprise. For example allow only minor releases "[1.5, 1.6)". Maven should probably give a warning if I try using an artefact without version which it is not part of bundle. Now, about transitive dependencies, if my release code depends on something alpha, should I really call my code stable? This is where good practice comes along. Shall I provide my own version (like people do for snapshots)? Maven will need to provide a tool that allows listing the transitive closure of dependencies of a bundle so that someone can check that no sneaky alpha code is getting pull in. But at the end of the day someone needs to take responsibility, just like you do when declaring a new Maven release to be of RELEASED status. Hope this makes some sense... Jose Alberto -- View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10138426 Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
