The problem is that repo1.maven.org is used by everyone, and even some things that are not Maven (e.g. ivy, etc)
These clients are expecting a 4.0.0 model, so either we have a 3rd generation repository, with all the migration woes... I don't see that going to happen... or we keep the 4.0.0 model in the maven repositories.... The question then arises, how do we let 4.1 aware clients receive the benefits of the 4.1 model, while letting 4.0 clients continue to work. One option is to only deploy 4.0 poms to the repository... that's fine as long as the changes to the model for 4.1 can be described in 4.0 terms... in which case, why would we bother changing the model. The next option is to deploy 4.0 and 4.1 poms to the repository... that begs the question, who is the master... A third option is to use a repository manager to transform the poms on the fly (e.g. nexus)... might affect build reproducibility The forth option is to extend the existing clients such that they can download newer model parsers and, in a sense, work out the answer on the fly... that can work for the Maven 2.0.x line, but the other clients are outside of our control, and might object if we stop playing nice -Stephen 2008/11/22 Paul Benedict <[EMAIL PROTECTED]> > I don't see anything wrong with POMs not being backwards compatible. > If the model is 4.1, so you should have a 4.1 parser -- upgrade your > Maven if necessary. Is this really any different than trying to import > a Maven 1 dependency in Maven 2? > > Paul > > On Sat, Nov 22, 2008 at 2:05 PM, Stephen Connolly > <[EMAIL PROTECTED]> wrote: > > > > > > On 22 Nov 2008, at 19:52, "nicolas de loof" <[EMAIL PROTECTED]> wrote: > > > >> 1. if my project uses maven 2.x with support for POM 4.x this is just a > >> project requirement, as the JDK version requirement is > >> 2. if the parent has been deployed, it will be converted in 4.0.0 > format, > >> so > >> can be read by any maven version > >> > >> Not sure you understood my idea : let the POM format as a project level > >> tool > >> envolve, but always deploy POM (as artifacts meta-datas) in 4.0.0 > format. > >> > >> This only requires all 4.x improvemement to ba translatable in any way > to > >> 4.0.0. In my example, globalExclusion could be translated (brute force) > to > >> exclusion on ALL <dependency>. > > > > that will only work while you know what the transitives pulled in are. > > > > my point is that if foo depends on anything other than a hard single > version > > eg [2.3] we can never be sure what *all* the dependencies are in order to > > brute-force exclude them > > > > such a brute-force exclude is required, and short of introducing > wildcards > > for exclusions backported to the 2.0.11 line, I don't see how we can > write a > > 4.0 pom that describes the problem > > > > as regards rewriting, I'm actually in favour of doing just that. I have a > > plugin that rewrites pons taking out sections we don't want to make > public > > (build, reporting, test-scoped dependencies, the list of developers, our > > internal distribution management, ...) and locking down some things so > that > > there are no profiles or properties... I'm toying with putting it on mojo > > > > we use it to prepare a pom that can be used from outside, but keeps > internal > > details safe > > > > what I'm saying is let's go farther and make the pom deployed to the repo > a > > more minimal pom... keeping only that which is actually needed > > > > - Stephen > > > >> > >> > >> Nicolas > >> > >> > >> 2008/11/22 Stephen Connolly <[EMAIL PROTECTED]> > >> > >>> 1 if a pom builds with model 4.1, then you can't build with older > >>> versions > >>> of maven > >>> > >>> 2 from 1 we see that if we reference a parent, that parent must be <= > our > >>> model version > >>> > >>> 3. if we are not using the pom as a parent, most of the information in > >>> the > >>> pom is redundant (certainly the build and reporting sections, the > >>> distribution management, dependencyManagement, and possibly the scm > >>> section) > >>> > >>> 4. perhaps classifiers are the way out, deploy a trimmed down pom with > no > >>> classifier and the full pom with a classifier of v4.1 > >>> > >>> that way we look for the v4.1 pom if we are looking up the parent of a > >>> v4.1 > >>> pom, otherwise all we really care about is the license and transitive > >>> dependencies. > >>> > >>> 5. what about exclusions of transitive dependencies? > >>> > >>> if foo depends on bar [1.1,) and excludes > commons-logging:commons-logging > >>> > >>> what happens when bar 2.0 changes dependencies to > >>> org.apache.commons:logging... now the exclusion from transitives > >>> expressed > >>> in the original pom does not work any more! > >>> > >>> foo may not have control over bar, and if foo declares a hard > dependency > >>> on > >>> bar [1.1] to ensure it's exclusion rule is always correct, version > ranges > >>> become useless > >>> > >>> Sent from my iPod > >>> > >>> > >>> On 22 Nov 2008, at 13:12, "nicolas de loof" <[EMAIL PROTECTED]> > wrote: > >>> > >>> Hi, > >>>> > >>>> considering the issue with a new modelVersion, that would not be > >>>> readable > >>>> by > >>>> previous Maven versions, > >>>> What about enhancing the deploy plugin to rewrite the POM that gets > >>>> deployed > >>>> as 4.0.0 ? > >>>> > >>>> example : suppose we create a new <globalExclusion> element in > >>>> modelVerison > >>>> 4.1.0. This could be translated to setting the exclusion to ALL > >>>> dependencies > >>>> in the POM, and writing this one back as 4.0.0. Not very nice, but > who > >>>> cares > >>>> about the beauty of POMs on central ? They are use by maven as > metadata > >>>> sources, not by human beeing. only the POM in project SCM has interest > >>>> for > >>>> humans ! > >>>> > >>>> This requires 4.x modelVersion to be translatable to 4.0.0, but this > >>>> could > >>>> introduce some interesting enhancements to POM that are blocked today. > >>>> > >>>> 2nd Idea (more complex) : could a maven extension post-process the POM > ? > >>>> example : > >>>> My (custom) POM uses a dedicated namespace for some extension feature > : > >>>> > >>>> <project> > >>>> ... > >>>> <ext:globalExclusion xmlns:ext="someURI" > >>>> artifact="commons-logging:commons-logging"> > >>>> ... > >>>> <extension> > >>>> <groupId>org.apache.maven.extensions</> > >>>> <artifactId>globalexclusion</> > >>>> <version>..</> > >>>> <extension> > >>>> </ > >>>> > >>>> Note : I suppose the default parser will ignore this unexpected <ext: > >>>> element. > >>>> > >>>> after parsing this POM, globalexclusion extension, that implements > some > >>>> PostProcessor API could modify the parsed Model object, and in my > >>>> example > >>>> add an exclusion to all declared dependencies. > >>>> > >>>> Just some week-end ideas ;) > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
