Some thoughts inline... "Vincent Massol" <[EMAIL PROTECTED]> wrote on 20/11/2003 07:58:41 PM:
[snip] > Proposal 1: > > * Add the following to project.xml (this is an example): > > <compatibilities> > <compatibility>1.0-rc1</compatibility> > <compatibility>1.0-rc2</compatibility> > <compatibility>1.0-rc3-SNAPSHOT</compatibility> > </compatibilities> > > Proposal 2: > > * Reuse the dependencies elements of project.xml (this is an example): > > <dependency> > <groupId>maven</groupId> > <artifactId>maven</artifactId> > <version>1.0+</version> > <type>maven</type> > </dependency> > > My analysis: > > * First question to answer: whether we wish to support complex > versioning right now. i.e. the use of "+". I am personally not in favor > of using that now for 2 reasons: Given it's use in JDK1.5, for example, and that we haven't yet designed/coded the feature, let's go for the most user friendly option. Keep things easy for the developer to specify rather than for us to process. > * It is complex to implement and we could easily use a list of > versions as showin in proposal 1 Except that sometimes you want to say you require any version *after or including* a certain release. > * It raises lots of ugly questions. Like: if I say "1.0-rc1+", how can > I know that my plugin will be compatible with 1.1 when it is not even > yet designed nor released? So in practice I cannot say 1.0-rc1+ but I'll > have to say something like "1.0-rc1"-"1.0" >From my perspective these things should be releases. i.e. 1.0+, 1.1+ etc. But if you don't want to specify 1.0-rc1+, we could always allow multiple <version>s. But this isn't my preferred method. > * I like the dependency reuse but for the following points: > * We will need to really tackle the <type> element properly and > provide Resolvers for each type. We'll also need to provide better APIs > for plugin developers as I believe some plugins are currently iterating > over any dependency. Something like project.getDependencies(type) maybe. I'm pretty sure we fixed most of the plugins doing that earlier. But we may have missed a few when we converted to using dependency.artifacts. A better api, or better still a tag would be better. > * How do we specify multiple versions? Using a comma-separated list > seem to have been rejected by everyone (see previous posts on > compatibility in archives). Go the multiple <version> tags. > * Although we could reuse the dependency stuff, Maven core is something > special and unlike other dependencies. Why? Because other dependencies > can be downloaded whereas Maven core is installed and cannot be changed > automatically. Also Maven is not an artifact. It is not composed only of Maven core is like the JDK. It's a runtime requirement, not a build time one. We really should also start thinking of how to specify that the project can only be built on JDK 1.2, 1.3 etc. > a JAR. It is a complete system. That means there's no relationship > between the Maven system installed on your machine and the remote > repository. It happens there is a maven jar but this not the > compatibility we are stating. We are stating a compatibility with the > full installed Maven, not an API compatibility with the maven jar. Dependencies are just dependencies. One type of dependency is a build time requirement for a jar file. Another is a runtime JDK rather than a JRE and of a certain set of versions. Another is a runtime maven installation. Another maybe environment variables.... > * Are we going to also specify what version of the POM a plugin > supports? Now that plugins are extracted from the core and could be > provided by third parties, it may become necessary. One solution would > be to link Maven versions with POM versions but I don't know if it > provides enough flexibility. Don't the plugins do this already by specifying <pomVersion> in their own project.xml? Thanks, -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
