2008/11/22 Stephen Connolly <[EMAIL PROTECTED]> > 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. >
Oh, and if we only deploy the 4.0 poms to the repository, how will I inherit the 4.1 features that cannot be described in 4.0 terms from the 4.1 parent that has been deployed and downgraded to a 4.0 pom on deploy > 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] >> >> >
