I definitely see the need for a downloadable and pluggable schema parser. It shouldn't matter what version the POM is. Maven should be able to use a parser like any other dependency, and be able to translate back.
Paul On Sat, Nov 22, 2008 at 6:04 PM, Shane Isbell <[EMAIL PROTECTED]> wrote: > Personally, I think the best technical solution is to have a repository > manager recognize the Maven client version and then deliver the correct > model version based on Maven's capabilities. But as long as repos are web > based, which is our current environment, you have to push this decision off > to the client, which means that older versions of Maven are going to have to > know how to ignore newer sections of the pom. I don't think we can hold back > delivering new versions of poms because of ivy or any other non-maven > client: they will need to add support for more dynamic handling of poms. > > Shane > > On Sat, Nov 22, 2008 at 3:37 PM, Stephen Connolly < > [EMAIL PROTECTED]> wrote: > >> 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] >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
