2008/11/26 Gilles Scokart <[EMAIL PROTECTED]>
> One of the problem with build tool is that an upgrade is often not
> possible.
>
> You have a project developped 2 years ago and you want to make a small
> fix on it... You certainly don't want to migrate to a new build tool
> just because you want
One of the problem with build tool is that an upgrade is often not possible.
You have a project developped 2 years ago and you want to make a small
fix on it... You certainly don't want to migrate to a new build tool
just because you want to take a newer version of a dependency.
Conclusion : The
it's nor so simple when you add repo1 into the mix. you would need to
separate repositories by model version (again) or using repo1 would
become a crapshoot (oh look spring have a new version, my version
range will pick that up... but now it won't build because of a pom
parse error. this bu
Or they'll against burn maven ...
Arnaud
On Wed, Nov 26, 2008 at 12:08 AM, Paul Benedict <[EMAIL PROTECTED]>wrote:
> Arnaud, that is why I said let the free market decide. Why should we
> care if someone only wants to adopt a 4.0+ format? If their adoption
> doesn't happen because not enough use
Arnaud, that is why I said let the free market decide. Why should we
care if someone only wants to adopt a 4.0+ format? If their adoption
doesn't happen because not enough users have it, it's incentive for
them to make a better decision.
Paul
On Tue, Nov 25, 2008 at 4:59 PM, Arnaud HERITIER <[EMA
Thus when spring, hibernate, whatever will decide to publish their poms in a
4.0.0+ format projects which will want to use those new version will have to
upgrade maven too. I think that in many corporate environment their managers
will just say ... no (too risky, expensive, ..). And those framework
I just don't see the big deal with forcing users to upgrade Maven if
they want to use a newer POM version. It will be up to the publishers
to decide whether they want 4.0, 4.1, or both formats in the
repository. Let the free market decide what should be supported.
Paul
---
No. I wouldn't see any model or deployment changes occurring in 2.0.x.
However, since the deploy plugin delegates to Maven's artifact
mechanism in 2.1.0, it can do the extra adjustments itself if there
were a new model version introduced.
- Brett
On 25/11/2008, at 6:51 PM, nicolas de loof
Does this mean maven 2.0.10+ will require a new plugin attached to
(pre)deploy phase to generate a 4.0.0 compatible POM ?
2008/11/25 Brett Porter <[EMAIL PROTECTED]>
> I'm not sure even rolling in changes to support this in 2.0.11+ answers the
> question. We're still having trouble getting people
I'm not sure even rolling in changes to support this in 2.0.11+
answers the question. We're still having trouble getting people up
from 2.0.6 type versions, and we're still supporting Maven 1 clients.
A forced upgrade, even over time, seems impractical at this point.
A lot of good suggestio
On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>
> A big +1. Changing the published poms format is very impacting. Not
> only for the maven client, but for all tools that are using the
> repository as a server (ivy, buildr, maven proxies & repository
> managers, etc.
2008/11/23 Brian E. Fox <[EMAIL PROTECTED]>
>
> >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
>
> This can only be done for poms that are not poms, that is
> for things that are not inherited. Otherwi
2008/11/23 Stephen Connolly <[EMAIL PROTECTED]>:
> 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)
>>
A big +1. Changing the published poms format is very impacting. Not
only
Hi folks,
Maybe i missed some discussions about new pom versions.
But, when this new pom version is to be used in maven ?
The hidden question is about the archetype plugin. Currently
the plugin make some changes in the poms for the projects,
like adding/changing parents or modules.
I do imagine
>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
This can only be done for poms that are not poms, that is
for things that are not inherited. Otherwise you still need to have the
new pom version deploye
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
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
26 matches
Mail list logo
