You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michael Mosmann <mi...@mosmann.de> on 2009/11/06 08:39:25 UTC
maven dependency version inprovment
Hi,
i am new to this list, so please excuse any beginner mistakes.
Yesterday i was struggling with what is called maven dependency hell. I
know, that this is not a maven problem.. but maybe maven can solve this
much better.
<project>
…
<groupId>com.somestuff</groupId>
<artifactId>com.somestuff-lib</artifactId>
<version>1.2.3</version>
<baseversion>1.1.0</baseversion>
…
</project>
Where <baseversion> is the version where the api changed last, so maven
can see, if different referenced versions are only bug fixes..
So dependency A with version 1.2.3 and B with version 1.1.9 will be
changed to version 1.2.3. Maven knows, that both Versions have the same
base version.
thank you for any comment.
Michael Mosmann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven dependency version inprovment
Posted by Stephen Connolly <st...@gmail.com>.
Which is exactly equivalent to deploying modelVersion 5.0.0 as
pom-with-classifier and the back-translated-to-4.0.0 as pom without
classifier
2009/11/6 Ralph Goers <ra...@dslextreme.com>:
> You missed an option that Brian Fox and I have been discussing. That is
> having a new pom file with a different extension. mvn deploy would deploy
> the new file and would generate a pom which would also be deployed.
>
> Ralph
>
> On Nov 6, 2009, at 12:57 AM, Stephen Connolly wrote:
>
>> Unfortunately, Maven has an issue. I shall try to explain the issue.
>>
>> There are a lot of older versions of Maven 2.x out there. Changing
>> the XSD schema of pom files will break those older clients from
>> reading the information in the central repository. In addition, a
>> number of other tools (e.g. IVY, POM editors in IDEs
>> [eclipse,intellij,netbeans,etc]) now read the model version 4.0.0 pom
>> XSD, and rely on that information.
>>
>> The Maven developer community have not decided on the best way to
>> solve this problem. Here are some of the possible solutions:
>>
>> * Start a new central repository which has only pom files with the new
>> schema [Given our historic experience migrating from m1 to m2, while
>> there are many who would love if we could do this, it's probably a
>> non-runner]
>>
>> * Use the namespacing feature of build plugins to allow the extra
>> information to be stored in the pom [Looks ugly]
>>
>> * Use classifiers to deploy the new schema pom in addition to a
>> back-translated 4.0.0 model [Might work, but then new clients
>> potentially will have a 33-50% increase in hits to the repository - ie
>> check is the 5.0.0 model there at the classifier, nope, ok let's check
>> is the 4.0.0 model there without the classifier, nope, ok is the jar
>> file there, nope: "cannot find dependency"]
>>
>> * Use an XML processing instruction to provide the extra information
>> [modello does not currently support such, and some of the tools that
>> manipulate pom files may end up removing XML PIs]
>>
>> In theory, modello "should" be able to handle reading a newer format,
>> but it would require a "lot" of testing, and if we find any maven 2.x
>> version that does not handle it, or any 3rd party tool that has
>> issues, well practically, we're back to not being able to change the
>> model version, which means that we are kind of stuck with the model
>> vesion we have.
>>
>> I suspect that the plug-ability being introduced in 3.0 will mean that
>> we are able to provide a hook for m3 to "discover" how to handle newer
>> model versions, so that once m3 is available and widely used, we will
>> be able to consider schema changes.
>>
>> -Stephen
>>
>> P.S. the above is my impressions of why schema changes are not going
>> to happen in 3.0.x... as always Jason may/will correct me where I am
>> wrong
>>
>> 2009/11/6 Michael Mosmann <mi...@mosmann.de>:
>>>
>>> Hi,
>>>
>>> i am new to this list, so please excuse any beginner mistakes.
>>>
>>> Yesterday i was struggling with what is called maven dependency hell. I
>>> know, that this is not a maven problem.. but maybe maven can solve this
>>> much better.
>>>
>>> <project>
>>> …
>>> <groupId>com.somestuff</groupId>
>>> <artifactId>com.somestuff-lib</artifactId>
>>> <version>1.2.3</version>
>>> <baseversion>1.1.0</baseversion>
>>> …
>>> </project>
>>>
>>> Where <baseversion> is the version where the api changed last, so maven
>>> can see, if different referenced versions are only bug fixes..
>>>
>>> So dependency A with version 1.2.3 and B with version 1.1.9 will be
>>> changed to version 1.2.3. Maven knows, that both Versions have the same
>>> base version.
>>>
>>> thank you for any comment.
>>>
>>> Michael Mosmann
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven dependency version inprovment
Posted by Ralph Goers <ra...@dslextreme.com>.
You missed an option that Brian Fox and I have been discussing. That
is having a new pom file with a different extension. mvn deploy would
deploy the new file and would generate a pom which would also be
deployed.
Ralph
On Nov 6, 2009, at 12:57 AM, Stephen Connolly wrote:
> Unfortunately, Maven has an issue. I shall try to explain the issue.
>
> There are a lot of older versions of Maven 2.x out there. Changing
> the XSD schema of pom files will break those older clients from
> reading the information in the central repository. In addition, a
> number of other tools (e.g. IVY, POM editors in IDEs
> [eclipse,intellij,netbeans,etc]) now read the model version 4.0.0 pom
> XSD, and rely on that information.
>
> The Maven developer community have not decided on the best way to
> solve this problem. Here are some of the possible solutions:
>
> * Start a new central repository which has only pom files with the new
> schema [Given our historic experience migrating from m1 to m2, while
> there are many who would love if we could do this, it's probably a
> non-runner]
>
> * Use the namespacing feature of build plugins to allow the extra
> information to be stored in the pom [Looks ugly]
>
> * Use classifiers to deploy the new schema pom in addition to a
> back-translated 4.0.0 model [Might work, but then new clients
> potentially will have a 33-50% increase in hits to the repository - ie
> check is the 5.0.0 model there at the classifier, nope, ok let's check
> is the 4.0.0 model there without the classifier, nope, ok is the jar
> file there, nope: "cannot find dependency"]
>
> * Use an XML processing instruction to provide the extra information
> [modello does not currently support such, and some of the tools that
> manipulate pom files may end up removing XML PIs]
>
> In theory, modello "should" be able to handle reading a newer format,
> but it would require a "lot" of testing, and if we find any maven 2.x
> version that does not handle it, or any 3rd party tool that has
> issues, well practically, we're back to not being able to change the
> model version, which means that we are kind of stuck with the model
> vesion we have.
>
> I suspect that the plug-ability being introduced in 3.0 will mean that
> we are able to provide a hook for m3 to "discover" how to handle newer
> model versions, so that once m3 is available and widely used, we will
> be able to consider schema changes.
>
> -Stephen
>
> P.S. the above is my impressions of why schema changes are not going
> to happen in 3.0.x... as always Jason may/will correct me where I am
> wrong
>
> 2009/11/6 Michael Mosmann <mi...@mosmann.de>:
>> Hi,
>>
>> i am new to this list, so please excuse any beginner mistakes.
>>
>> Yesterday i was struggling with what is called maven dependency
>> hell. I
>> know, that this is not a maven problem.. but maybe maven can solve
>> this
>> much better.
>>
>> <project>
>> …
>> <groupId>com.somestuff</groupId>
>> <artifactId>com.somestuff-lib</artifactId>
>> <version>1.2.3</version>
>> <baseversion>1.1.0</baseversion>
>> …
>> </project>
>>
>> Where <baseversion> is the version where the api changed last, so
>> maven
>> can see, if different referenced versions are only bug fixes..
>>
>> So dependency A with version 1.2.3 and B with version 1.1.9 will be
>> changed to version 1.2.3. Maven knows, that both Versions have the
>> same
>> base version.
>>
>> thank you for any comment.
>>
>> Michael Mosmann
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven dependency version inprovment
Posted by Brian Fox <br...@infinity.nu>.
It's not done yet.
On Sat, Nov 7, 2009 at 5:38 AM, Gilles Scokart <gs...@gmail.com> wrote:
> 2009/11/6 Stephen Connolly <st...@gmail.com>
>
>>
>> I suspect that the plug-ability being introduced in 3.0 will mean that
>> we are able to provide a hook for m3 to "discover" how to handle newer
>> model versions, so that once m3 is available and widely used, we will
>> be able to consider schema changes.
>>
>>
> Is there any page documenting this, or threads discussing that somewhere?
>
> If that becomes a required step to read correctly a maven repository, I
> guess that tools like Apache Ivy or Apache Buildr should be adpated.
>
> Gilles
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven dependency version inprovment
Posted by Gilles Scokart <gs...@gmail.com>.
2009/11/6 Stephen Connolly <st...@gmail.com>
>
> I suspect that the plug-ability being introduced in 3.0 will mean that
> we are able to provide a hook for m3 to "discover" how to handle newer
> model versions, so that once m3 is available and widely used, we will
> be able to consider schema changes.
>
>
Is there any page documenting this, or threads discussing that somewhere?
If that becomes a required step to read correctly a maven repository, I
guess that tools like Apache Ivy or Apache Buildr should be adpated.
Gilles
Re: maven dependency version inprovment
Posted by Stephen Connolly <st...@gmail.com>.
Unfortunately, Maven has an issue. I shall try to explain the issue.
There are a lot of older versions of Maven 2.x out there. Changing
the XSD schema of pom files will break those older clients from
reading the information in the central repository. In addition, a
number of other tools (e.g. IVY, POM editors in IDEs
[eclipse,intellij,netbeans,etc]) now read the model version 4.0.0 pom
XSD, and rely on that information.
The Maven developer community have not decided on the best way to
solve this problem. Here are some of the possible solutions:
* Start a new central repository which has only pom files with the new
schema [Given our historic experience migrating from m1 to m2, while
there are many who would love if we could do this, it's probably a
non-runner]
* Use the namespacing feature of build plugins to allow the extra
information to be stored in the pom [Looks ugly]
* Use classifiers to deploy the new schema pom in addition to a
back-translated 4.0.0 model [Might work, but then new clients
potentially will have a 33-50% increase in hits to the repository - ie
check is the 5.0.0 model there at the classifier, nope, ok let's check
is the 4.0.0 model there without the classifier, nope, ok is the jar
file there, nope: "cannot find dependency"]
* Use an XML processing instruction to provide the extra information
[modello does not currently support such, and some of the tools that
manipulate pom files may end up removing XML PIs]
In theory, modello "should" be able to handle reading a newer format,
but it would require a "lot" of testing, and if we find any maven 2.x
version that does not handle it, or any 3rd party tool that has
issues, well practically, we're back to not being able to change the
model version, which means that we are kind of stuck with the model
vesion we have.
I suspect that the plug-ability being introduced in 3.0 will mean that
we are able to provide a hook for m3 to "discover" how to handle newer
model versions, so that once m3 is available and widely used, we will
be able to consider schema changes.
-Stephen
P.S. the above is my impressions of why schema changes are not going
to happen in 3.0.x... as always Jason may/will correct me where I am
wrong
2009/11/6 Michael Mosmann <mi...@mosmann.de>:
> Hi,
>
> i am new to this list, so please excuse any beginner mistakes.
>
> Yesterday i was struggling with what is called maven dependency hell. I
> know, that this is not a maven problem.. but maybe maven can solve this
> much better.
>
> <project>
> …
> <groupId>com.somestuff</groupId>
> <artifactId>com.somestuff-lib</artifactId>
> <version>1.2.3</version>
> <baseversion>1.1.0</baseversion>
> …
> </project>
>
> Where <baseversion> is the version where the api changed last, so maven
> can see, if different referenced versions are only bug fixes..
>
> So dependency A with version 1.2.3 and B with version 1.1.9 will be
> changed to version 1.2.3. Maven knows, that both Versions have the same
> base version.
>
> thank you for any comment.
>
> Michael Mosmann
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven dependency version inprovment
Posted by Ralph Goers <ra...@dslextreme.com>.
Michael,
Welcome!
What I have suggested in the past is a more general version of what
you are suggesting. The main problem is that adding new elements to
the pom will break versions of Maven and other applications that don't
understand it. The maven team has been discussing ways of moving
forward on this for quite a while but no conclusion has been reached
yet.
Ralph
On Nov 5, 2009, at 11:39 PM, Michael Mosmann wrote:
> Hi,
>
> i am new to this list, so please excuse any beginner mistakes.
>
> Yesterday i was struggling with what is called maven dependency
> hell. I
> know, that this is not a maven problem.. but maybe maven can solve
> this
> much better.
>
> <project>
> …
> <groupId>com.somestuff</groupId>
> <artifactId>com.somestuff-lib</artifactId>
> <version>1.2.3</version>
> <baseversion>1.1.0</baseversion>
> …
> </project>
>
> Where <baseversion> is the version where the api changed last, so
> maven
> can see, if different referenced versions are only bug fixes..
>
> So dependency A with version 1.2.3 and B with version 1.1.9 will be
> changed to version 1.2.3. Maven knows, that both Versions have the
> same
> base version.
>
> thank you for any comment.
>
> Michael Mosmann
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org