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:
> Per
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 th
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'
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 i
The very real problem is projects that may be aggressive in adopting
new versions of Maven and/or the model and only deploying newer
versions of POM. Users with older versions of Maven will not be able
to consume those POMs.
The next couple version of 2.0.x need to be taught an adaptive way
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
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
This is the direction that Maven 3.0 is moving toward, with the new project
builder. You can create custom ModelTransformers that could do things like
take the global exclusion and apply it to all dependencies. This could allow
you to create extensions to the local pom but have it deployed as model
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 pro
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
I think that the maven-project-builder would be a good location for the
super pom, as this component is used both by maven-mercury and
maven-project.
Shane
On Sat, Nov 22, 2008 at 8:52 AM, Benjamin Bentmann <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> Author: sisbell
>> Date: Thu Nov 20 20:50:50 2008
Hervé BOUTEMY wrote:
I just found a problem when trying to generate 2.0.10-RC site: this is a xsd
generation problem introduced when fixing MNG-1999
As a side question: Should we extend the CI jobs to also run the site
phase after the regular install/deploy/whatever to make sure we notice
su
Hi,
Author: sisbell
Date: Thu Nov 20 20:50:50 2008
New Revision: 719473
URL: http://svn.apache.org/viewvc?rev=719473&view=rev
Log:
Import of maven mercury project.
Added:
[...]
maven/components/trunk/maven-mercury/src/main/resources/org/apache/maven/project/pom-4.0.0.xml
This file d
Hi Shane,
Author: sisbell
Date: Fri Nov 21 13:50:31 2008
New Revision: 719724
URL: http://svn.apache.org/viewvc?rev=719724&view=rev
Log:
Moved out specialized methods from PomClassicTransformer to ProjectBuilder. Did
this refactoring to make it easier to merge PomTransformer and
PomClassicTra
Hi,
I just found a problem when trying to generate 2.0.10-RC site: this is a xsd
generation problem introduced when fixing MNG-1999 (comments added in this
issue, with corresponding MODELLO-121 issue).
This has no impact on Maven distribution: the code works fine. But site
generation can't be
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 element in modelVerison
4.1.0. This could be translated to setting t
16 matches
Mail list logo