You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Tom <tb...@tbee.org> on 2011/04/13 08:41:58 UTC
breaking backwards compatibility
Maven resolves dependencies under the (rightful) assumption that a higher version is 100% backwards compatible to an earlier release, and therefor picks the highest requires version of a dependency. But once every so often a library should be purged, things cannot be @depricated forever.
Is it possible to tell Maven a library is not backwards compatible anymore?
I usually use a major version increment for such steps (e.g. 1.x becomes 2.x). But even specifying ranges "[1.0,1.999]" combined with "[2.0,2.999]" do not cause an error of some kind, but simply resolve to 2.x.
Kind regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Jörg Schaible <jo...@scalaris.com>.
Tom Eugelink wrote:
>
>> What means "not compatible" for a single artifact? If my application only
>> uses a constant defined in some class, the dependency is only
>> incompatible if this constant is no longer available, has a different
>> type or a value that causes a failure situation in my own app.
>>
>> You can define real incompatibility only from the consumer side. So what
>> could Maven actually report by default?
>
> It is a real world scenario that at some time a library is purged; that
> @deprecated methods are actually deleted, that API's are refactored. Such
> a version is no longer backwards compatible.
If my app did not use the methods that have been removed, it is - at least
for my application.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
> What means "not compatible" for a single artifact? If my application only
> uses a constant defined in some class, the dependency is only incompatible
> if this constant is no longer available, has a different type or a value
> that causes a failure situation in my own app.
>
> You can define real incompatibility only from the consumer side. So what
> could Maven actually report by default?
It is a real world scenario that at some time a library is purged; that @deprecated methods are actually deleted, that API's are refactored. Such a version is no longer backwards compatible.
Tom
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
I do not agree on the similarity; the infinite loop is my responsibility, the version resolving logic Maven's. Maven does not need to analyze any code, I'm more than willing to tell Maven that a certain version breaks compatibility.
I gather from the response that this is not possible.
Tom
On 13-4-2011 16:17, Adam Gibbons wrote:
> if you wrote an infinate loop that crashed your code, would it be maven's
> job to pick that up too? that's essentually what you're looking for. in an
> ideal world you should know which 3rd party libs work together and which
> don't.
> you now do know that, and once you've done something about it there will be
> no issues with maven. there isn't anyway for the build tool to work out what
> libs work with which others unless it exercieses all of their code in all
> ways possible. surly you can see how this is outside the scope of a build
> tool?
>
> maybe a plugin could be developed where people build up a library of
> incompatabilities and a sanity check could be done by maven to ensure you
> didn't have any of these incompatabilities (transient or otherwise) in your
> code?
>
>
>
>
> On 13 April 2011 14:22, Tom Eugelink<T....@knowledgeplaza.nl> wrote:
>
>> I'd agree if the tool would only do building, but it is IMHO the
>> responsibility of any version resolving.
>>
>> Tom
>>
>>
>>
>> On 13-4-2011 15:15, Adam Gibbons wrote:
>>
>>> It's not possible to know that at build time though. The incompatabilities
>>> might be created programatically at runtime. This responsability falls
>>> with
>>> the developer to do proper testing before integrating new technologies
>>> into
>>> your code. Sure it would be nice if Maven told you where you'd gone wrong,
>>> but that isn't the job of a build tool.
>>>
>>>
>>>
>>>
>>> On 13 April 2011 13:50, Tom Eugelink<T....@knowledgeplaza.nl>
>>> wrote:
>>>
>>> Correct, what I am looking for is Maven to tell me there is a version
>>>> conflict.
>>>>
>>>>
>>>>
>>>> On 13-4-2011 14:22, Benson Margulies wrote:
>>>>
>>>> Adam, it might not be *his code*. He writes something that uses the
>>>>> newest, spiffiest, version of component X. Then he adds a dependency
>>>>> on component Y. And, buried in the transitive dependency graph of Y is
>>>>> an ancient version of X.
>>>>>
>>>>> Yes, of course, we could tell him to use OSGi and all buy shares in
>>>>> companies selling perm gen space.
>>>>>
>>>>> The point here is not to try to make these cases *work*, it is to
>>>>> diagnose, since in the worst case the failure modes are complex and
>>>>> confusing.
>>>>>
>>>>> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<ad...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> crazy idea, but why don't you just refactor the code that only works
>>>>>> with
>>>>>> v1.0 to work with v2.0? it might be better anyway...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 April 2011 13:15, Benson Margulies<bi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Jörg,
>>>>>>
>>>>>>> The question is, "Are there interesting cases in which the author of
>>>>>>> the package knows that 2.0 is absolutely not compatible with the
>>>>>>> previous reasons?" Or, at least, knows that it's very rarely going to
>>>>>>> be compatible?
>>>>>>>
>>>>>>> Imagine that, as part of deploy, the author could attach a bit of
>>>>>>> metadata that had these semantics.
>>>>>>>
>>>>>>> Just in case, those semantics could be read by the enforcer instead of
>>>>>>> by the maven core.
>>>>>>>
>>>>>>> As it is, the OP needs a pretty good crystal ball to come up with a
>>>>>>> comprehensive enforcer config of all the possible ancient versions in
>>>>>>> transient dependencies (or there other way around) that could cause
>>>>>>> havoc.
>>>>>>>
>>>>>>> --benson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>>>>>>> <jo...@scalaris.com> wrote:
>>>>>>>
>>>>>>> Benson Margulies wrote:
>>>>>>>> The OP wishes that maven had some, ahem, declarative mechanism for
>>>>>>>>
>>>>>>>>> raising a flag in this case. No guessing. Some way to attach
>>>>>>>>> metadata
>>>>>>>>> to 2.0 that says, 'you can't use this as a compatible replacement
>>>>>>>>> for
>>>>>>>>> 1.0. Yell instead.'
>>>>>>>>>
>>>>>>>>> Yeah, I know, but in my case, I don't want a yell, simply because I
>>>>>>>> can
>>>>>>>>
>>>>>>>> use
>>>>>>> 2.0 as compatible version. Therefore, if this "compatibility"
>>>>>>>> declaration
>>>>>>>>
>>>>>>>> is
>>>>>>> delivered by x:y:2.0, it does not make sense. If I should be able to
>>>>>>>> declare
>>>>>>> it for my app, I could already use the enforcer instead.
>>>>>>>> - Jörg
>>>>>>>>
>>>>>>>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>>>>>>>>
>>>>>>>>> <jo...@scalaris.com> wrote:
>>>>>>>>>
>>>>>>>>> Benson Margulies wrote:
>>>>>>>>>> There is perhaps a communications problem here. I don't think this
>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>>> about ranges. I suspect that it is about:
>>>>>>>>>>>
>>>>>>>>>>> - project g:A version 1 depends on x:y:2.0
>>>>>>>>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>>>>>>>>
>>>>>>>>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>>>>>>>>>
>>>>>>>>>>> So what? Should or can Maven now somehow detect that g:B uses
>>>>>>>>>> stuff
>>>>>>>>>> of
>>>>>>>>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it
>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>> not
>>>>>>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>>>>>>>
>>>>>>>>> only.
>>>>>>>>>> - Jörg
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> *Tom Eugelink*
>>>> Senior software engineer
>>>> +31 (0)6 - 47 93 85 92
>>>> t.eugelink@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>>>> *KnowledgePlaza<http://www.knowledgeplaza.nl>*
>>>> Sutton 15
>>>> 7327 AB Apeldoorn
>>>> Tel: +31 (0)55 - 526 3887
>>>> Fax: +31 (0)55 - 526 3950
>>>> info@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>>>> Disclaimer: The information contained in this message is for the intended
>>>> addressee only and may contain confidential and/or privileged
>>>> information.
>>>> If you are not the intended addressee, please delete this message and
>>>> notify
>>>> the sender; do not copy or distribute this message or disclose its
>>>> contents
>>>> to anyone.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>>
>> *Tom Eugelink*
>> Senior software engineer
>> +31 (0)6 - 47 93 85 92
>> t.eugelink@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> *KnowledgePlaza<http://www.knowledgeplaza.nl>*
>> Sutton 15
>> 7327 AB Apeldoorn
>> Tel: +31 (0)55 - 526 3887
>> Fax: +31 (0)55 - 526 3950
>> info@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> Disclaimer: The information contained in this message is for the intended
>> addressee only and may contain confidential and/or privileged information.
>> If you are not the intended addressee, please delete this message and notify
>> the sender; do not copy or distribute this message or disclose its contents
>> to anyone.
>>
>>
>>
>>
>>
>>
>>
>>
>>
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
Disclaimer: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone.
Re: breaking backwards compatibility
Posted by Jörg Schaible <jo...@gmx.de>.
Adam Gibbons wrote:
> if you wrote an infinate loop that crashed your code, would it be maven's
> job to pick that up too? that's essentually what you're looking for. in an
> ideal world you should know which 3rd party libs work together and which
> don't.
> you now do know that, and once you've done something about it there will
> be no issues with maven. there isn't anyway for the build tool to work out
> what libs work with which others unless it exercieses all of their code in
> all ways possible. surly you can see how this is outside the scope of a
> build tool?
>
> maybe a plugin could be developed where people build up a library of
> incompatabilities and a sanity check could be done by maven to ensure you
> didn't have any of these incompatabilities (transient or otherwise) in
> your code?
Funny enough, theres already the animal sniffer plugin
(http://mojo.codehaus.org/animal-sniffer-maven-plugin/) that can be used to
create something like this. It's currently used mainly for the Java runtime
library, but it's by no way limited to it.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Adam Gibbons <ad...@gmail.com>.
if you wrote an infinate loop that crashed your code, would it be maven's
job to pick that up too? that's essentually what you're looking for. in an
ideal world you should know which 3rd party libs work together and which
don't.
you now do know that, and once you've done something about it there will be
no issues with maven. there isn't anyway for the build tool to work out what
libs work with which others unless it exercieses all of their code in all
ways possible. surly you can see how this is outside the scope of a build
tool?
maybe a plugin could be developed where people build up a library of
incompatabilities and a sanity check could be done by maven to ensure you
didn't have any of these incompatabilities (transient or otherwise) in your
code?
On 13 April 2011 14:22, Tom Eugelink <T....@knowledgeplaza.nl> wrote:
> I'd agree if the tool would only do building, but it is IMHO the
> responsibility of any version resolving.
>
> Tom
>
>
>
> On 13-4-2011 15:15, Adam Gibbons wrote:
>
>> It's not possible to know that at build time though. The incompatabilities
>> might be created programatically at runtime. This responsability falls
>> with
>> the developer to do proper testing before integrating new technologies
>> into
>> your code. Sure it would be nice if Maven told you where you'd gone wrong,
>> but that isn't the job of a build tool.
>>
>>
>>
>>
>> On 13 April 2011 13:50, Tom Eugelink<T....@knowledgeplaza.nl>
>> wrote:
>>
>> Correct, what I am looking for is Maven to tell me there is a version
>>> conflict.
>>>
>>>
>>>
>>> On 13-4-2011 14:22, Benson Margulies wrote:
>>>
>>> Adam, it might not be *his code*. He writes something that uses the
>>>> newest, spiffiest, version of component X. Then he adds a dependency
>>>> on component Y. And, buried in the transitive dependency graph of Y is
>>>> an ancient version of X.
>>>>
>>>> Yes, of course, we could tell him to use OSGi and all buy shares in
>>>> companies selling perm gen space.
>>>>
>>>> The point here is not to try to make these cases *work*, it is to
>>>> diagnose, since in the worst case the failure modes are complex and
>>>> confusing.
>>>>
>>>> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<ad...@gmail.com>
>>>> wrote:
>>>>
>>>> crazy idea, but why don't you just refactor the code that only works
>>>>> with
>>>>> v1.0 to work with v2.0? it might be better anyway...
>>>>>
>>>>>
>>>>>
>>>>> On 13 April 2011 13:15, Benson Margulies<bi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Jörg,
>>>>>
>>>>>> The question is, "Are there interesting cases in which the author of
>>>>>> the package knows that 2.0 is absolutely not compatible with the
>>>>>> previous reasons?" Or, at least, knows that it's very rarely going to
>>>>>> be compatible?
>>>>>>
>>>>>> Imagine that, as part of deploy, the author could attach a bit of
>>>>>> metadata that had these semantics.
>>>>>>
>>>>>> Just in case, those semantics could be read by the enforcer instead of
>>>>>> by the maven core.
>>>>>>
>>>>>> As it is, the OP needs a pretty good crystal ball to come up with a
>>>>>> comprehensive enforcer config of all the possible ancient versions in
>>>>>> transient dependencies (or there other way around) that could cause
>>>>>> havoc.
>>>>>>
>>>>>> --benson
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>>>>>> <jo...@scalaris.com> wrote:
>>>>>>
>>>>>> Benson Margulies wrote:
>>>>>>>
>>>>>>> The OP wishes that maven had some, ahem, declarative mechanism for
>>>>>>>
>>>>>>>> raising a flag in this case. No guessing. Some way to attach
>>>>>>>> metadata
>>>>>>>> to 2.0 that says, 'you can't use this as a compatible replacement
>>>>>>>> for
>>>>>>>> 1.0. Yell instead.'
>>>>>>>>
>>>>>>>> Yeah, I know, but in my case, I don't want a yell, simply because I
>>>>>>> can
>>>>>>>
>>>>>>> use
>>>>>>
>>>>>> 2.0 as compatible version. Therefore, if this "compatibility"
>>>>>>> declaration
>>>>>>>
>>>>>>> is
>>>>>>
>>>>>> delivered by x:y:2.0, it does not make sense. If I should be able to
>>>>>>>
>>>>>>> declare
>>>>>>
>>>>>> it for my app, I could already use the enforcer instead.
>>>>>>>
>>>>>>> - Jörg
>>>>>>>
>>>>>>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>>>>>>>
>>>>>>>> <jo...@scalaris.com> wrote:
>>>>>>>>
>>>>>>>> Benson Margulies wrote:
>>>>>>>>>
>>>>>>>>> There is perhaps a communications problem here. I don't think this
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>>> about ranges. I suspect that it is about:
>>>>>>>>>>
>>>>>>>>>> - project g:A version 1 depends on x:y:2.0
>>>>>>>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>>>>>>>
>>>>>>>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>>>>>>>>
>>>>>>>>>> So what? Should or can Maven now somehow detect that g:B uses
>>>>>>>>> stuff
>>>>>>>>> of
>>>>>>>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> not
>>>>>>>>
>>>>>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>>>>>>
>>>>>>>> only.
>>>>>>>>>
>>>>>>>>> - Jörg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> --
>>>
>>> *Tom Eugelink*
>>> Senior software engineer
>>> +31 (0)6 - 47 93 85 92
>>> t.eugelink@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>>> *KnowledgePlaza<http://www.knowledgeplaza.nl>*
>>> Sutton 15
>>> 7327 AB Apeldoorn
>>> Tel: +31 (0)55 - 526 3887
>>> Fax: +31 (0)55 - 526 3950
>>> info@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>>> Disclaimer: The information contained in this message is for the intended
>>> addressee only and may contain confidential and/or privileged
>>> information.
>>> If you are not the intended addressee, please delete this message and
>>> notify
>>> the sender; do not copy or distribute this message or disclose its
>>> contents
>>> to anyone.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
> --
>
> *Tom Eugelink*
> Senior software engineer
> +31 (0)6 - 47 93 85 92
> t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> *KnowledgePlaza <http://www.knowledgeplaza.nl>*
> Sutton 15
> 7327 AB Apeldoorn
> Tel: +31 (0)55 - 526 3887
> Fax: +31 (0)55 - 526 3950
> info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> Disclaimer: The information contained in this message is for the intended
> addressee only and may contain confidential and/or privileged information.
> If you are not the intended addressee, please delete this message and notify
> the sender; do not copy or distribute this message or disclose its contents
> to anyone.
>
>
>
>
>
>
>
>
>
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
I'd agree if the tool would only do building, but it is IMHO the responsibility of any version resolving.
Tom
On 13-4-2011 15:15, Adam Gibbons wrote:
> It's not possible to know that at build time though. The incompatabilities
> might be created programatically at runtime. This responsability falls with
> the developer to do proper testing before integrating new technologies into
> your code. Sure it would be nice if Maven told you where you'd gone wrong,
> but that isn't the job of a build tool.
>
>
>
>
> On 13 April 2011 13:50, Tom Eugelink<T....@knowledgeplaza.nl> wrote:
>
>> Correct, what I am looking for is Maven to tell me there is a version
>> conflict.
>>
>>
>>
>> On 13-4-2011 14:22, Benson Margulies wrote:
>>
>>> Adam, it might not be *his code*. He writes something that uses the
>>> newest, spiffiest, version of component X. Then he adds a dependency
>>> on component Y. And, buried in the transitive dependency graph of Y is
>>> an ancient version of X.
>>>
>>> Yes, of course, we could tell him to use OSGi and all buy shares in
>>> companies selling perm gen space.
>>>
>>> The point here is not to try to make these cases *work*, it is to
>>> diagnose, since in the worst case the failure modes are complex and
>>> confusing.
>>>
>>> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<ad...@gmail.com>
>>> wrote:
>>>
>>>> crazy idea, but why don't you just refactor the code that only works with
>>>> v1.0 to work with v2.0? it might be better anyway...
>>>>
>>>>
>>>>
>>>> On 13 April 2011 13:15, Benson Margulies<bi...@gmail.com> wrote:
>>>>
>>>> Jörg,
>>>>> The question is, "Are there interesting cases in which the author of
>>>>> the package knows that 2.0 is absolutely not compatible with the
>>>>> previous reasons?" Or, at least, knows that it's very rarely going to
>>>>> be compatible?
>>>>>
>>>>> Imagine that, as part of deploy, the author could attach a bit of
>>>>> metadata that had these semantics.
>>>>>
>>>>> Just in case, those semantics could be read by the enforcer instead of
>>>>> by the maven core.
>>>>>
>>>>> As it is, the OP needs a pretty good crystal ball to come up with a
>>>>> comprehensive enforcer config of all the possible ancient versions in
>>>>> transient dependencies (or there other way around) that could cause
>>>>> havoc.
>>>>>
>>>>> --benson
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>>>>> <jo...@scalaris.com> wrote:
>>>>>
>>>>>> Benson Margulies wrote:
>>>>>>
>>>>>> The OP wishes that maven had some, ahem, declarative mechanism for
>>>>>>> raising a flag in this case. No guessing. Some way to attach metadata
>>>>>>> to 2.0 that says, 'you can't use this as a compatible replacement for
>>>>>>> 1.0. Yell instead.'
>>>>>>>
>>>>>> Yeah, I know, but in my case, I don't want a yell, simply because I can
>>>>>>
>>>>> use
>>>>>
>>>>>> 2.0 as compatible version. Therefore, if this "compatibility"
>>>>>> declaration
>>>>>>
>>>>> is
>>>>>
>>>>>> delivered by x:y:2.0, it does not make sense. If I should be able to
>>>>>>
>>>>> declare
>>>>>
>>>>>> it for my app, I could already use the enforcer instead.
>>>>>>
>>>>>> - Jörg
>>>>>>
>>>>>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>>>>>>> <jo...@scalaris.com> wrote:
>>>>>>>
>>>>>>>> Benson Margulies wrote:
>>>>>>>>
>>>>>>>> There is perhaps a communications problem here. I don't think this is
>>>>>>>>> about ranges. I suspect that it is about:
>>>>>>>>>
>>>>>>>>> - project g:A version 1 depends on x:y:2.0
>>>>>>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>>>>>>
>>>>>>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>>>>>>>
>>>>>>>> So what? Should or can Maven now somehow detect that g:B uses stuff
>>>>>>>> of
>>>>>>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is
>>>>>>>>
>>>>>>> not
>>>>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>>>>>>> only.
>>>>>>>>
>>>>>>>> - Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> --
>>
>> *Tom Eugelink*
>> Senior software engineer
>> +31 (0)6 - 47 93 85 92
>> t.eugelink@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> *KnowledgePlaza<http://www.knowledgeplaza.nl>*
>> Sutton 15
>> 7327 AB Apeldoorn
>> Tel: +31 (0)55 - 526 3887
>> Fax: +31 (0)55 - 526 3950
>> info@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> Disclaimer: The information contained in this message is for the intended
>> addressee only and may contain confidential and/or privileged information.
>> If you are not the intended addressee, please delete this message and notify
>> the sender; do not copy or distribute this message or disclose its contents
>> to anyone.
>>
>>
>>
>>
>>
>>
>>
>>
>>
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
Disclaimer: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone.
Re: breaking backwards compatibility
Posted by Adam Gibbons <ad...@gmail.com>.
It's not possible to know that at build time though. The incompatabilities
might be created programatically at runtime. This responsability falls with
the developer to do proper testing before integrating new technologies into
your code. Sure it would be nice if Maven told you where you'd gone wrong,
but that isn't the job of a build tool.
On 13 April 2011 13:50, Tom Eugelink <T....@knowledgeplaza.nl> wrote:
> Correct, what I am looking for is Maven to tell me there is a version
> conflict.
>
>
>
> On 13-4-2011 14:22, Benson Margulies wrote:
>
>> Adam, it might not be *his code*. He writes something that uses the
>> newest, spiffiest, version of component X. Then he adds a dependency
>> on component Y. And, buried in the transitive dependency graph of Y is
>> an ancient version of X.
>>
>> Yes, of course, we could tell him to use OSGi and all buy shares in
>> companies selling perm gen space.
>>
>> The point here is not to try to make these cases *work*, it is to
>> diagnose, since in the worst case the failure modes are complex and
>> confusing.
>>
>> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<ad...@gmail.com>
>> wrote:
>>
>>> crazy idea, but why don't you just refactor the code that only works with
>>> v1.0 to work with v2.0? it might be better anyway...
>>>
>>>
>>>
>>> On 13 April 2011 13:15, Benson Margulies<bi...@gmail.com> wrote:
>>>
>>> Jörg,
>>>>
>>>> The question is, "Are there interesting cases in which the author of
>>>> the package knows that 2.0 is absolutely not compatible with the
>>>> previous reasons?" Or, at least, knows that it's very rarely going to
>>>> be compatible?
>>>>
>>>> Imagine that, as part of deploy, the author could attach a bit of
>>>> metadata that had these semantics.
>>>>
>>>> Just in case, those semantics could be read by the enforcer instead of
>>>> by the maven core.
>>>>
>>>> As it is, the OP needs a pretty good crystal ball to come up with a
>>>> comprehensive enforcer config of all the possible ancient versions in
>>>> transient dependencies (or there other way around) that could cause
>>>> havoc.
>>>>
>>>> --benson
>>>>
>>>>
>>>>
>>>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>>>> <jo...@scalaris.com> wrote:
>>>>
>>>>> Benson Margulies wrote:
>>>>>
>>>>> The OP wishes that maven had some, ahem, declarative mechanism for
>>>>>> raising a flag in this case. No guessing. Some way to attach metadata
>>>>>> to 2.0 that says, 'you can't use this as a compatible replacement for
>>>>>> 1.0. Yell instead.'
>>>>>>
>>>>> Yeah, I know, but in my case, I don't want a yell, simply because I can
>>>>>
>>>> use
>>>>
>>>>> 2.0 as compatible version. Therefore, if this "compatibility"
>>>>> declaration
>>>>>
>>>> is
>>>>
>>>>> delivered by x:y:2.0, it does not make sense. If I should be able to
>>>>>
>>>> declare
>>>>
>>>>> it for my app, I could already use the enforcer instead.
>>>>>
>>>>> - Jörg
>>>>>
>>>>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>>>>>> <jo...@scalaris.com> wrote:
>>>>>>
>>>>>>> Benson Margulies wrote:
>>>>>>>
>>>>>>> There is perhaps a communications problem here. I don't think this is
>>>>>>>> about ranges. I suspect that it is about:
>>>>>>>>
>>>>>>>> - project g:A version 1 depends on x:y:2.0
>>>>>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>>>>>
>>>>>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>>>>>>
>>>>>>> So what? Should or can Maven now somehow detect that g:B uses stuff
>>>>>>> of
>>>>>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is
>>>>>>>
>>>>>> not
>>>>
>>>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>>>>>> only.
>>>>>>>
>>>>>>> - Jörg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
>
> *Tom Eugelink*
> Senior software engineer
> +31 (0)6 - 47 93 85 92
> t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> *KnowledgePlaza <http://www.knowledgeplaza.nl>*
> Sutton 15
> 7327 AB Apeldoorn
> Tel: +31 (0)55 - 526 3887
> Fax: +31 (0)55 - 526 3950
> info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> Disclaimer: The information contained in this message is for the intended
> addressee only and may contain confidential and/or privileged information.
> If you are not the intended addressee, please delete this message and notify
> the sender; do not copy or distribute this message or disclose its contents
> to anyone.
>
>
>
>
>
>
>
>
>
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
Correct, what I am looking for is Maven to tell me there is a version conflict.
On 13-4-2011 14:22, Benson Margulies wrote:
> Adam, it might not be *his code*. He writes something that uses the
> newest, spiffiest, version of component X. Then he adds a dependency
> on component Y. And, buried in the transitive dependency graph of Y is
> an ancient version of X.
>
> Yes, of course, we could tell him to use OSGi and all buy shares in
> companies selling perm gen space.
>
> The point here is not to try to make these cases *work*, it is to
> diagnose, since in the worst case the failure modes are complex and
> confusing.
>
> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<ad...@gmail.com> wrote:
>> crazy idea, but why don't you just refactor the code that only works with
>> v1.0 to work with v2.0? it might be better anyway...
>>
>>
>>
>> On 13 April 2011 13:15, Benson Margulies<bi...@gmail.com> wrote:
>>
>>> Jörg,
>>>
>>> The question is, "Are there interesting cases in which the author of
>>> the package knows that 2.0 is absolutely not compatible with the
>>> previous reasons?" Or, at least, knows that it's very rarely going to
>>> be compatible?
>>>
>>> Imagine that, as part of deploy, the author could attach a bit of
>>> metadata that had these semantics.
>>>
>>> Just in case, those semantics could be read by the enforcer instead of
>>> by the maven core.
>>>
>>> As it is, the OP needs a pretty good crystal ball to come up with a
>>> comprehensive enforcer config of all the possible ancient versions in
>>> transient dependencies (or there other way around) that could cause
>>> havoc.
>>>
>>> --benson
>>>
>>>
>>>
>>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>>> <jo...@scalaris.com> wrote:
>>>> Benson Margulies wrote:
>>>>
>>>>> The OP wishes that maven had some, ahem, declarative mechanism for
>>>>> raising a flag in this case. No guessing. Some way to attach metadata
>>>>> to 2.0 that says, 'you can't use this as a compatible replacement for
>>>>> 1.0. Yell instead.'
>>>> Yeah, I know, but in my case, I don't want a yell, simply because I can
>>> use
>>>> 2.0 as compatible version. Therefore, if this "compatibility" declaration
>>> is
>>>> delivered by x:y:2.0, it does not make sense. If I should be able to
>>> declare
>>>> it for my app, I could already use the enforcer instead.
>>>>
>>>> - Jörg
>>>>
>>>>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>>>>> <jo...@scalaris.com> wrote:
>>>>>> Benson Margulies wrote:
>>>>>>
>>>>>>> There is perhaps a communications problem here. I don't think this is
>>>>>>> about ranges. I suspect that it is about:
>>>>>>>
>>>>>>> - project g:A version 1 depends on x:y:2.0
>>>>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>>>>
>>>>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>>>> So what? Should or can Maven now somehow detect that g:B uses stuff of
>>>>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is
>>> not
>>>>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>>>>> only.
>>>>>>
>>>>>> - Jörg
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
Disclaimer: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone.
Re: breaking backwards compatibility
Posted by Benson Margulies <bi...@gmail.com>.
Adam, it might not be *his code*. He writes something that uses the
newest, spiffiest, version of component X. Then he adds a dependency
on component Y. And, buried in the transitive dependency graph of Y is
an ancient version of X.
Yes, of course, we could tell him to use OSGi and all buy shares in
companies selling perm gen space.
The point here is not to try to make these cases *work*, it is to
diagnose, since in the worst case the failure modes are complex and
confusing.
On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons <ad...@gmail.com> wrote:
> crazy idea, but why don't you just refactor the code that only works with
> v1.0 to work with v2.0? it might be better anyway...
>
>
>
> On 13 April 2011 13:15, Benson Margulies <bi...@gmail.com> wrote:
>
>> Jörg,
>>
>> The question is, "Are there interesting cases in which the author of
>> the package knows that 2.0 is absolutely not compatible with the
>> previous reasons?" Or, at least, knows that it's very rarely going to
>> be compatible?
>>
>> Imagine that, as part of deploy, the author could attach a bit of
>> metadata that had these semantics.
>>
>> Just in case, those semantics could be read by the enforcer instead of
>> by the maven core.
>>
>> As it is, the OP needs a pretty good crystal ball to come up with a
>> comprehensive enforcer config of all the possible ancient versions in
>> transient dependencies (or there other way around) that could cause
>> havoc.
>>
>> --benson
>>
>>
>>
>> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
>> <jo...@scalaris.com> wrote:
>> > Benson Margulies wrote:
>> >
>> >> The OP wishes that maven had some, ahem, declarative mechanism for
>> >> raising a flag in this case. No guessing. Some way to attach metadata
>> >> to 2.0 that says, 'you can't use this as a compatible replacement for
>> >> 1.0. Yell instead.'
>> >
>> > Yeah, I know, but in my case, I don't want a yell, simply because I can
>> use
>> > 2.0 as compatible version. Therefore, if this "compatibility" declaration
>> is
>> > delivered by x:y:2.0, it does not make sense. If I should be able to
>> declare
>> > it for my app, I could already use the enforcer instead.
>> >
>> > - Jörg
>> >
>> >>
>> >> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>> >> <jo...@scalaris.com> wrote:
>> >>> Benson Margulies wrote:
>> >>>
>> >>>> There is perhaps a communications problem here. I don't think this is
>> >>>> about ranges. I suspect that it is about:
>> >>>>
>> >>>> - project g:A version 1 depends on x:y:2.0
>> >>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>> >>>>
>> >>>> What ends up in the classpath of B? x:y:2.0, I think.
>> >>>
>> >>> So what? Should or can Maven now somehow detect that g:B uses stuff of
>> >>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is
>> not
>> >>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>> >>> only.
>> >>>
>> >>> - Jörg
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: users-help@maven.apache.org
>> >>>
>> >>>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Adam Gibbons <ad...@gmail.com>.
crazy idea, but why don't you just refactor the code that only works with
v1.0 to work with v2.0? it might be better anyway...
On 13 April 2011 13:15, Benson Margulies <bi...@gmail.com> wrote:
> Jörg,
>
> The question is, "Are there interesting cases in which the author of
> the package knows that 2.0 is absolutely not compatible with the
> previous reasons?" Or, at least, knows that it's very rarely going to
> be compatible?
>
> Imagine that, as part of deploy, the author could attach a bit of
> metadata that had these semantics.
>
> Just in case, those semantics could be read by the enforcer instead of
> by the maven core.
>
> As it is, the OP needs a pretty good crystal ball to come up with a
> comprehensive enforcer config of all the possible ancient versions in
> transient dependencies (or there other way around) that could cause
> havoc.
>
> --benson
>
>
>
> On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
> <jo...@scalaris.com> wrote:
> > Benson Margulies wrote:
> >
> >> The OP wishes that maven had some, ahem, declarative mechanism for
> >> raising a flag in this case. No guessing. Some way to attach metadata
> >> to 2.0 that says, 'you can't use this as a compatible replacement for
> >> 1.0. Yell instead.'
> >
> > Yeah, I know, but in my case, I don't want a yell, simply because I can
> use
> > 2.0 as compatible version. Therefore, if this "compatibility" declaration
> is
> > delivered by x:y:2.0, it does not make sense. If I should be able to
> declare
> > it for my app, I could already use the enforcer instead.
> >
> > - Jörg
> >
> >>
> >> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
> >> <jo...@scalaris.com> wrote:
> >>> Benson Margulies wrote:
> >>>
> >>>> There is perhaps a communications problem here. I don't think this is
> >>>> about ranges. I suspect that it is about:
> >>>>
> >>>> - project g:A version 1 depends on x:y:2.0
> >>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
> >>>>
> >>>> What ends up in the classpath of B? x:y:2.0, I think.
> >>>
> >>> So what? Should or can Maven now somehow detect that g:B uses stuff of
> >>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is
> not
> >>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
> >>> only.
> >>>
> >>> - Jörg
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: breaking backwards compatibility
Posted by Benson Margulies <bi...@gmail.com>.
Jörg,
The question is, "Are there interesting cases in which the author of
the package knows that 2.0 is absolutely not compatible with the
previous reasons?" Or, at least, knows that it's very rarely going to
be compatible?
Imagine that, as part of deploy, the author could attach a bit of
metadata that had these semantics.
Just in case, those semantics could be read by the enforcer instead of
by the maven core.
As it is, the OP needs a pretty good crystal ball to come up with a
comprehensive enforcer config of all the possible ancient versions in
transient dependencies (or there other way around) that could cause
havoc.
--benson
On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible
<jo...@scalaris.com> wrote:
> Benson Margulies wrote:
>
>> The OP wishes that maven had some, ahem, declarative mechanism for
>> raising a flag in this case. No guessing. Some way to attach metadata
>> to 2.0 that says, 'you can't use this as a compatible replacement for
>> 1.0. Yell instead.'
>
> Yeah, I know, but in my case, I don't want a yell, simply because I can use
> 2.0 as compatible version. Therefore, if this "compatibility" declaration is
> delivered by x:y:2.0, it does not make sense. If I should be able to declare
> it for my app, I could already use the enforcer instead.
>
> - Jörg
>
>>
>> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
>> <jo...@scalaris.com> wrote:
>>> Benson Margulies wrote:
>>>
>>>> There is perhaps a communications problem here. I don't think this is
>>>> about ranges. I suspect that it is about:
>>>>
>>>> - project g:A version 1 depends on x:y:2.0
>>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>>
>>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>
>>> So what? Should or can Maven now somehow detect that g:B uses stuff of
>>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is not
>>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>>> only.
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Jörg Schaible <jo...@scalaris.com>.
Benson Margulies wrote:
> The OP wishes that maven had some, ahem, declarative mechanism for
> raising a flag in this case. No guessing. Some way to attach metadata
> to 2.0 that says, 'you can't use this as a compatible replacement for
> 1.0. Yell instead.'
Yeah, I know, but in my case, I don't want a yell, simply because I can use
2.0 as compatible version. Therefore, if this "compatibility" declaration is
delivered by x:y:2.0, it does not make sense. If I should be able to declare
it for my app, I could already use the enforcer instead.
- Jörg
>
> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
> <jo...@scalaris.com> wrote:
>> Benson Margulies wrote:
>>
>>> There is perhaps a communications problem here. I don't think this is
>>> about ranges. I suspect that it is about:
>>>
>>> - project g:A version 1 depends on x:y:2.0
>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>
>>> What ends up in the classpath of B? x:y:2.0, I think.
>>
>> So what? Should or can Maven now somehow detect that g:B uses stuff of
>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is not
>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0
>> only.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Benson Margulies <bi...@gmail.com>.
The OP wishes that maven had some, ahem, declarative mechanism for
raising a flag in this case. No guessing. Some way to attach metadata
to 2.0 that says, 'you can't use this as a compatible replacement for
1.0. Yell instead.'
On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible
<jo...@scalaris.com> wrote:
> Benson Margulies wrote:
>
>> There is perhaps a communications problem here. I don't think this is
>> about ranges. I suspect that it is about:
>>
>> - project g:A version 1 depends on x:y:2.0
>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>
>> What ends up in the classpath of B? x:y:2.0, I think.
>
> So what? Should or can Maven now somehow detect that g:B uses stuff of
> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is not
> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0 only.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Jörg Schaible <jo...@scalaris.com>.
Benson Margulies wrote:
> There is perhaps a communications problem here. I don't think this is
> about ranges. I suspect that it is about:
>
> - project g:A version 1 depends on x:y:2.0
> - project g:B version 1 depends on g:A:1 and x:y:1.0
>
> What ends up in the classpath of B? x:y:2.0, I think.
So what? Should or can Maven now somehow detect that g:B uses stuff of
x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is not
helpful at all, if some mechanism ensures that g:B runs with x:y:1.0 only.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Ron Wheeler <rw...@artifact-software.com>.
This is why version ranges are not a good idea if you have production
software that you need to maintain and do quick bug fixes that have a
constrained risk and require minimal testing.
If your build is not repeatable because you have not specified the
version of third party libraries, you have a big job to test even the
smallest change to a single class.
Nothing is more disruptive that a bug fix that causes a whole lot of
errors in parts of the code that was known to work, not changed but now
exhibits changed behaviour.
We do not allow version ranges and furthermore have central control over
the version of third party libraries so that it is a conscious decision
to upgrade a library.
Maven helps detect version conflicts with the dependency graph or tree.
We remove these in our library projects by "exclusion" so that unwanted
libraries are not dragged in.
Early in the development process for a new release, we settle on the
versions that will be used for all of the 70-100 3rd party libraries
that we will use either explicitly or through transitive dependency.
This is no longer a big job since we have the POMs already set up. It
took a few days to set up the 50+ (now 70+) application modules and the
10+ library modules but now it is a piece of cake to keep them current
as each new version of the application is developed.
If a new version of a third party library is required to support new
development or fix a bug, we make the change explicitly and do an impact
analysis to ensure that the testing is appropriate and deals with the
possibility that the new version of the library may have consequences
outside the actual code that we are changing.
We merely have to look at the modules with exclusions on this library to
identify where it is used through transitive dependency.
Ron
On 13/04/2011 8:17 AM, Julien HENRY wrote:
> Hi,
>
>
> This problem is not specific to Maven, but this is a Java issue.
>
> Running javac on P with -classpath=A.jar, B.jar, X-2.0.jar, X-1.0.jar will not
> work nor -classpath=A.jar, B.jar, X-1.0.jar, X-2.0.jar
>
> If you want to be able to use two versions of the same class side by side... you
> have to rename package/or class name (eg: com.acme.x1.TheClass and
> com.acme.x2.TheClass).
>
> Translated to Maven it means you will have different artifacts: com.acme:X:1.0
> and com.acme:X2:1.0.
>
> P -> A -> X2 1.0
> -> B -> X 1.0
>
> This is how it works in Linux distributions with packages management. As long as
> a package is a replacement for another you can simply change version. But if you
> want to keep ability to use two artifacts at the same time => change artifactId.
>
> Here is an example from my distrib:
>
> S | Name | Type | Version | Arch | Repo
> --+----------------------+--------+--------------+--------+------------------
> | libdb_java-4_5 | paquet | 4.5.20-108.2 | x86_64 | openSUSE-11.4-Oss
> | libdb_java-4_8 | paquet | 4.8.30-2.2 | x86_64 | openSUSE-11.4-Oss
>
> My advice is to avoid this situation as it leads to a big mess. In some
> situation you may want to use maven-shade-plugin as a workaround [1].
>
> Regards,
>
> Julien
>
> [1]
> http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
>
>
>
> ----- Message d'origine ----
>> De : Tom Eugelink<T....@knowledgeplaza.nl>
>> À : Maven Users List<us...@maven.apache.org>
>> Envoyé le : Mer 13 avril 2011, 13h 56min 06s
>> Objet : Re: breaking backwards compatibility
>>
>> It is hard to make it clearer; suppose a version 2.0 of some library X got
>> all @deprecated methods from 1.0 removed. A clean up. The project could have
>> two dependencies that both refer to this library:
>>
>> P -> A -> X 2.0
>> -> B -> X 1.0
>>
>> If this is resolved, then indeed X 2.0 is included, however B expects the 1.0
>> version and may be using a @deprecated method that is no longer present. The
>> end project will crash.
>>
>> Is it possible to tell Maven that 2.0 is not a substitute for 1.0?
>>
>>
>>
>> On 13-4-2011 13:42, Benson Margulies wrote:
>>> There is perhaps a communications problem here. I don't think this is
>>> about ranges. I suspect that it is about:
>>>
>>> - project g:A version 1 depends on x:y:2.0
>>> - project g:B version 1 depends on g:A:1 and x:y:1.0
>>>
>>> What ends up in the classpath of B? x:y:2.0, I think.
>>>
>>>
>>> On Wed, Apr 13, 2011 at 7:17 AM, Schrecker, Wolfgang
>>> <Wo...@atosorigin.com> wrote:
>>>> Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
>>>> could help.
>>>>
>>>> Wolfgang
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Jörg Schaible [mailto:joerg.schaible@scalaris.com]
>>>> Gesendet: Mittwoch, 13. April 2011 11:55
>>>> An: users@maven.apache.org
>>>> Betreff: Re: breaking backwards compatibility
>>>>
>>>> Hi Tom,
>>>>
>>>> Tom Eugelink wrote:
>>>>
>>>>> I know Maven version management can be, ah, challenging, so I stick to
>>>>> Maven compatible versioning. Maybe not to the deepest level
>> (1.0.0-b01),
>>>>> but surely in a very common accepted style (1.0). I am not having any
>>>>> problems with Maven using the wrong versions.
>>>>>
>>>>> My question is with how to tell Maven two releases are no longer
>>>>> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
>>>>> is "declared" not backwards compatible to 1.x, then Maven should either:
>>>>> 1. report a build error on a version conflict 2. or include both versions
>>>>> of the artifact.
>>>> What means "not compatible" for a single artifact? If my application only
>>>> uses a constant defined in some class, the dependency is only
> incompatible
>>>> if this constant is no longer available, has a different type or a value
>>>> that causes a failure situation in my own app.
>>>>
>>>> You can define real incompatibility only from the consumer side. So what
>>>> could Maven actually report by default?
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------
>>>>
>>>> Atos Worldline GmbH
>>>> Hahnstraße 25
>>>> 60528 Frankfurt/Main
>>>> Germany
>>>> Phone: +49 69/6657-1176
>>>> Fax:
>>>> Mobile:
>>>> mailto: Wolfgang.Schrecker@atosorigin.com
>>>> http://www.atosworldline.com
>>>>
>>>> Geschäftsführer: Wolf Kunisch
>>>> Aufsichtsratsvorsitzender: Didier Dhennin
>>>> Sitz der Gesellschaft: Frankfurt/Main
>>>> Handelsregister: Frankfurt/Main HRB 40 417
>>>>
>>>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>>>> This e-mail and the documents attached are confidential and intended solely
>> for the addressee; it may also be privileged. If you receive this e-mail by
>> error, please notify the sender immediately and destroy it. As its integrity
>> cannot be secured on the internet, the Atos Origin group liability cannot be
>> triggered for the message content. Although the sender endeavours to maintain a
>> computer virus-free network, the sender does not warrant that this transmission
>> is virus-free and shall not be liable for any damages resulting from any virus
>> transmitted.
>>>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> --
>>
>> *Tom Eugelink*
>> Senior software engineer
>> +31 (0)6 - 47 93 85 92
>> t.eugelink@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> *KnowledgePlaza<http://www.knowledgeplaza.nl>*
>> Sutton 15
>> 7327 AB Apeldoorn
>> Tel: +31 (0)55 - 526 3887
>> Fax: +31 (0)55 - 526 3950
>> info@knowledgeplaza.nl<ma...@knowledgeplaza.nl>
>> Disclaimer: The information contained in this message is for the intended
>> addressee only and may contain confidential and/or privileged information. If
>> you are not the intended addressee, please delete this message and notify the
>> sender; do not copy or distribute this message or disclose its contents to
>> anyone.
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Julien HENRY <he...@yahoo.fr>.
Hi,
This problem is not specific to Maven, but this is a Java issue.
Running javac on P with -classpath=A.jar, B.jar, X-2.0.jar, X-1.0.jar will not
work nor -classpath=A.jar, B.jar, X-1.0.jar, X-2.0.jar
If you want to be able to use two versions of the same class side by side... you
have to rename package/or class name (eg: com.acme.x1.TheClass and
com.acme.x2.TheClass).
Translated to Maven it means you will have different artifacts: com.acme:X:1.0
and com.acme:X2:1.0.
P -> A -> X2 1.0
-> B -> X 1.0
This is how it works in Linux distributions with packages management. As long as
a package is a replacement for another you can simply change version. But if you
want to keep ability to use two artifacts at the same time => change artifactId.
Here is an example from my distrib:
S | Name | Type | Version | Arch | Repo
--+----------------------+--------+--------------+--------+------------------
| libdb_java-4_5 | paquet | 4.5.20-108.2 | x86_64 | openSUSE-11.4-Oss
| libdb_java-4_8 | paquet | 4.8.30-2.2 | x86_64 | openSUSE-11.4-Oss
My advice is to avoid this situation as it leads to a big mess. In some
situation you may want to use maven-shade-plugin as a workaround [1].
Regards,
Julien
[1]
http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
----- Message d'origine ----
> De : Tom Eugelink <T....@knowledgeplaza.nl>
> À : Maven Users List <us...@maven.apache.org>
> Envoyé le : Mer 13 avril 2011, 13h 56min 06s
> Objet : Re: breaking backwards compatibility
>
> It is hard to make it clearer; suppose a version 2.0 of some library X got
>all @deprecated methods from 1.0 removed. A clean up. The project could have
>two dependencies that both refer to this library:
>
> P -> A -> X 2.0
> -> B -> X 1.0
>
> If this is resolved, then indeed X 2.0 is included, however B expects the 1.0
>version and may be using a @deprecated method that is no longer present. The
>end project will crash.
>
> Is it possible to tell Maven that 2.0 is not a substitute for 1.0?
>
>
>
> On 13-4-2011 13:42, Benson Margulies wrote:
> > There is perhaps a communications problem here. I don't think this is
> > about ranges. I suspect that it is about:
> >
> > - project g:A version 1 depends on x:y:2.0
> > - project g:B version 1 depends on g:A:1 and x:y:1.0
> >
> > What ends up in the classpath of B? x:y:2.0, I think.
> >
> >
> > On Wed, Apr 13, 2011 at 7:17 AM, Schrecker, Wolfgang
> > <Wo...@atosorigin.com> wrote:
> >> Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
> >> could help.
> >>
> >> Wolfgang
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Jörg Schaible [mailto:joerg.schaible@scalaris.com]
> >> Gesendet: Mittwoch, 13. April 2011 11:55
> >> An: users@maven.apache.org
> >> Betreff: Re: breaking backwards compatibility
> >>
> >> Hi Tom,
> >>
> >> Tom Eugelink wrote:
> >>
> >>> I know Maven version management can be, ah, challenging, so I stick to
> >>> Maven compatible versioning. Maybe not to the deepest level
>(1.0.0-b01),
> >>> but surely in a very common accepted style (1.0). I am not having any
> >>> problems with Maven using the wrong versions.
> >>>
> >>> My question is with how to tell Maven two releases are no longer
> >>> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
> >>> is "declared" not backwards compatible to 1.x, then Maven should either:
> >>> 1. report a build error on a version conflict 2. or include both versions
> >>> of the artifact.
> >> What means "not compatible" for a single artifact? If my application only
> >> uses a constant defined in some class, the dependency is only
incompatible
> >> if this constant is no longer available, has a different type or a value
> >> that causes a failure situation in my own app.
> >>
> >> You can define real incompatibility only from the consumer side. So what
> >> could Maven actually report by default?
> >>
> >> - Jörg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >>
> >>
> >> --------------------------------------------------
> >>
> >> Atos Worldline GmbH
> >> Hahnstraße 25
> >> 60528 Frankfurt/Main
> >> Germany
> >> Phone: +49 69/6657-1176
> >> Fax:
> >> Mobile:
> >> mailto: Wolfgang.Schrecker@atosorigin.com
> >> http://www.atosworldline.com
> >>
> >> Geschäftsführer: Wolf Kunisch
> >> Aufsichtsratsvorsitzender: Didier Dhennin
> >> Sitz der Gesellschaft: Frankfurt/Main
> >> Handelsregister: Frankfurt/Main HRB 40 417
> >>
> >> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
> >> This e-mail and the documents attached are confidential and intended solely
>for the addressee; it may also be privileged. If you receive this e-mail by
>error, please notify the sender immediately and destroy it. As its integrity
>cannot be secured on the internet, the Atos Origin group liability cannot be
>triggered for the message content. Although the sender endeavours to maintain a
>computer virus-free network, the sender does not warrant that this transmission
>is virus-free and shall not be liable for any damages resulting from any virus
>transmitted.
> >> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
>
> *Tom Eugelink*
> Senior software engineer
> +31 (0)6 - 47 93 85 92
> t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> *KnowledgePlaza <http://www.knowledgeplaza.nl>*
> Sutton 15
> 7327 AB Apeldoorn
> Tel: +31 (0)55 - 526 3887
> Fax: +31 (0)55 - 526 3950
> info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
> Disclaimer: The information contained in this message is for the intended
>addressee only and may contain confidential and/or privileged information. If
>you are not the intended addressee, please delete this message and notify the
>sender; do not copy or distribute this message or disclose its contents to
>anyone.
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
It is hard to make it clearer; suppose a version 2.0 of some library X got all @deprecated methods from 1.0 removed. A clean up. The project could have two dependencies that both refer to this library:
P -> A -> X 2.0
-> B -> X 1.0
If this is resolved, then indeed X 2.0 is included, however B expects the 1.0 version and may be using a @deprecated method that is no longer present. The end project will crash.
Is it possible to tell Maven that 2.0 is not a substitute for 1.0?
On 13-4-2011 13:42, Benson Margulies wrote:
> There is perhaps a communications problem here. I don't think this is
> about ranges. I suspect that it is about:
>
> - project g:A version 1 depends on x:y:2.0
> - project g:B version 1 depends on g:A:1 and x:y:1.0
>
> What ends up in the classpath of B? x:y:2.0, I think.
>
>
> On Wed, Apr 13, 2011 at 7:17 AM, Schrecker, Wolfgang
> <Wo...@atosorigin.com> wrote:
>> Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
>> could help.
>>
>> Wolfgang
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jörg Schaible [mailto:joerg.schaible@scalaris.com]
>> Gesendet: Mittwoch, 13. April 2011 11:55
>> An: users@maven.apache.org
>> Betreff: Re: breaking backwards compatibility
>>
>> Hi Tom,
>>
>> Tom Eugelink wrote:
>>
>>> I know Maven version management can be, ah, challenging, so I stick to
>>> Maven compatible versioning. Maybe not to the deepest level (1.0.0-b01),
>>> but surely in a very common accepted style (1.0). I am not having any
>>> problems with Maven using the wrong versions.
>>>
>>> My question is with how to tell Maven two releases are no longer
>>> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
>>> is "declared" not backwards compatible to 1.x, then Maven should either:
>>> 1. report a build error on a version conflict 2. or include both versions
>>> of the artifact.
>> What means "not compatible" for a single artifact? If my application only
>> uses a constant defined in some class, the dependency is only incompatible
>> if this constant is no longer available, has a different type or a value
>> that causes a failure situation in my own app.
>>
>> You can define real incompatibility only from the consumer side. So what
>> could Maven actually report by default?
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>>
>> --------------------------------------------------
>>
>> Atos Worldline GmbH
>> Hahnstraße 25
>> 60528 Frankfurt/Main
>> Germany
>> Phone: +49 69/6657-1176
>> Fax:
>> Mobile:
>> mailto: Wolfgang.Schrecker@atosorigin.com
>> http://www.atosworldline.com
>>
>> Geschäftsführer: Wolf Kunisch
>> Aufsichtsratsvorsitzender: Didier Dhennin
>> Sitz der Gesellschaft: Frankfurt/Main
>> Handelsregister: Frankfurt/Main HRB 40 417
>>
>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail by error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and shall not be liable for any damages resulting from any virus transmitted.
>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
Disclaimer: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone.
Re: breaking backwards compatibility
Posted by Benson Margulies <bi...@gmail.com>.
There is perhaps a communications problem here. I don't think this is
about ranges. I suspect that it is about:
- project g:A version 1 depends on x:y:2.0
- project g:B version 1 depends on g:A:1 and x:y:1.0
What ends up in the classpath of B? x:y:2.0, I think.
On Wed, Apr 13, 2011 at 7:17 AM, Schrecker, Wolfgang
<Wo...@atosorigin.com> wrote:
> Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
> could help.
>
> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: Jörg Schaible [mailto:joerg.schaible@scalaris.com]
> Gesendet: Mittwoch, 13. April 2011 11:55
> An: users@maven.apache.org
> Betreff: Re: breaking backwards compatibility
>
> Hi Tom,
>
> Tom Eugelink wrote:
>
>> I know Maven version management can be, ah, challenging, so I stick to
>> Maven compatible versioning. Maybe not to the deepest level (1.0.0-b01),
>> but surely in a very common accepted style (1.0). I am not having any
>> problems with Maven using the wrong versions.
>>
>> My question is with how to tell Maven two releases are no longer
>> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
>> is "declared" not backwards compatible to 1.x, then Maven should either:
>> 1. report a build error on a version conflict 2. or include both versions
>> of the artifact.
>
> What means "not compatible" for a single artifact? If my application only
> uses a constant defined in some class, the dependency is only incompatible
> if this constant is no longer available, has a different type or a value
> that causes a failure situation in my own app.
>
> You can define real incompatibility only from the consumer side. So what
> could Maven actually report by default?
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
> --------------------------------------------------
>
> Atos Worldline GmbH
> Hahnstraße 25
> 60528 Frankfurt/Main
> Germany
> Phone: +49 69/6657-1176
> Fax:
> Mobile:
> mailto: Wolfgang.Schrecker@atosorigin.com
> http://www.atosworldline.com
>
> Geschäftsführer: Wolf Kunisch
> Aufsichtsratsvorsitzender: Didier Dhennin
> Sitz der Gesellschaft: Frankfurt/Main
> Handelsregister: Frankfurt/Main HRB 40 417
>
> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail by error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and shall not be liable for any damages resulting from any virus transmitted.
> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: breaking backwards compatibility
Posted by "Schrecker, Wolfgang" <Wo...@atosorigin.com>.
Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
could help.
Wolfgang
-----Ursprüngliche Nachricht-----
Von: Jörg Schaible [mailto:joerg.schaible@scalaris.com]
Gesendet: Mittwoch, 13. April 2011 11:55
An: users@maven.apache.org
Betreff: Re: breaking backwards compatibility
Hi Tom,
Tom Eugelink wrote:
> I know Maven version management can be, ah, challenging, so I stick to
> Maven compatible versioning. Maybe not to the deepest level (1.0.0-b01),
> but surely in a very common accepted style (1.0). I am not having any
> problems with Maven using the wrong versions.
>
> My question is with how to tell Maven two releases are no longer
> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
> is "declared" not backwards compatible to 1.x, then Maven should either:
> 1. report a build error on a version conflict 2. or include both versions
> of the artifact.
What means "not compatible" for a single artifact? If my application only
uses a constant defined in some class, the dependency is only incompatible
if this constant is no longer available, has a different type or a value
that causes a failure situation in my own app.
You can define real incompatibility only from the consumer side. So what
could Maven actually report by default?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
--------------------------------------------------
Atos Worldline GmbH
Hahnstraße 25
60528 Frankfurt/Main
Germany
Phone: +49 69/6657-1176
Fax:
Mobile:
mailto: Wolfgang.Schrecker@atosorigin.com
http://www.atosworldline.com
Geschäftsführer: Wolf Kunisch
Aufsichtsratsvorsitzender: Didier Dhennin
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister: Frankfurt/Main HRB 40 417
* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail by error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and shall not be liable for any damages resulting from any virus transmitted.
* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
Re: breaking backwards compatibility
Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Tom,
Tom Eugelink wrote:
> I know Maven version management can be, ah, challenging, so I stick to
> Maven compatible versioning. Maybe not to the deepest level (1.0.0-b01),
> but surely in a very common accepted style (1.0). I am not having any
> problems with Maven using the wrong versions.
>
> My question is with how to tell Maven two releases are no longer
> compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
> is "declared" not backwards compatible to 1.x, then Maven should either:
> 1. report a build error on a version conflict 2. or include both versions
> of the artifact.
What means "not compatible" for a single artifact? If my application only
uses a constant defined in some class, the dependency is only incompatible
if this constant is no longer available, has a different type or a value
that causes a failure situation in my own app.
You can define real incompatibility only from the consumer side. So what
could Maven actually report by default?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: breaking backwards compatibility
Posted by Tom Eugelink <T....@knowledgeplaza.nl>.
I know Maven version management can be, ah, challenging, so I stick to Maven compatible versioning. Maybe not to the deepest level (1.0.0-b01), but surely in a very common accepted style (1.0). I am not having any problems with Maven using the wrong versions.
My question is with how to tell Maven two releases are no longer compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x is "declared" not backwards compatible to 1.x, then Maven should either:
1. report a build error on a version conflict
2. or include both versions of the artifact.
Tom
On 13-4-2011 10:56, Stephen Connolly wrote:
> Maven resolves version ranges in ways you might find strange...
>
> IF AND ONLY IF you have followed the Maven Version Number format
>
> [Major].[Minor].[Update]-[Build/Classifier]
>
> THEN version ranges will resolve somewhat sensibly.
>
> If you have a version number that is not in the magic format, then
> version comparison falls back to
> v1.toString().compareTo(v2.toString())
>
> So
>
> 5.0.0.0< 1.0< 1.0.1< 1.0.1-1< 2< 3.0< 4.5.7-6< 5.0.0
>
> Fun eh!
>
> So if you stick to Maven's format, then
>
> [1.0.0,2.0.0-SNAPSHOT)
>
> will resolve any 1.x version... there is some trickery about whether
> to include the -SNAPSHOT or not to do with ensuring that the snapshot
> does not get pulled in, e.g.
> 2.0.0-SNAPSHOT< 2.0.0
> But then IIRC if you include a SNAPSHOT in the range in some versions
> of Maven, then the range allows resolving -SNAPSHOTs
>
> Most people don't use Ranges.... which is why they have not felt the love.
>
> The current preference is to use locked down versions in your pom and
> have e.g. the versions-maven-plugin do the updating....
>
> Though I have to give the versions-maven-plugin some love once I get
> some other tasks off my plate
>
> -Stephen
>
> On 13 April 2011 07:41, Tom<tb...@tbee.org> wrote:
>> Maven resolves dependencies under the (rightful) assumption that a higher
>> version is 100% backwards compatible to an earlier release, and therefor
>> picks the highest requires version of a dependency. But once every so often
>> a library should be purged, things cannot be @depricated forever.
>>
>> Is it possible to tell Maven a library is not backwards compatible anymore?
>>
>> I usually use a major version increment for such steps (e.g. 1.x becomes
>> 2.x). But even specifying ranges "[1.0,1.999]" combined with "[2.0,2.999]"
>> do not cause an error of some kind, but simply resolve to 2.x.
>>
>> Kind regards,
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugelink@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
info@knowledgeplaza.nl <ma...@knowledgeplaza.nl>
Disclaimer: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone.
Re: breaking backwards compatibility
Posted by Stephen Connolly <st...@gmail.com>.
Maven resolves version ranges in ways you might find strange...
IF AND ONLY IF you have followed the Maven Version Number format
[Major].[Minor].[Update]-[Build/Classifier]
THEN version ranges will resolve somewhat sensibly.
If you have a version number that is not in the magic format, then
version comparison falls back to
v1.toString().compareTo(v2.toString())
So
5.0.0.0 < 1.0 < 1.0.1 < 1.0.1-1 < 2 < 3.0 < 4.5.7-6 < 5.0.0
Fun eh!
So if you stick to Maven's format, then
[1.0.0,2.0.0-SNAPSHOT)
will resolve any 1.x version... there is some trickery about whether
to include the -SNAPSHOT or not to do with ensuring that the snapshot
does not get pulled in, e.g.
2.0.0-SNAPSHOT < 2.0.0
But then IIRC if you include a SNAPSHOT in the range in some versions
of Maven, then the range allows resolving -SNAPSHOTs
Most people don't use Ranges.... which is why they have not felt the love.
The current preference is to use locked down versions in your pom and
have e.g. the versions-maven-plugin do the updating....
Though I have to give the versions-maven-plugin some love once I get
some other tasks off my plate
-Stephen
On 13 April 2011 07:41, Tom <tb...@tbee.org> wrote:
> Maven resolves dependencies under the (rightful) assumption that a higher
> version is 100% backwards compatible to an earlier release, and therefor
> picks the highest requires version of a dependency. But once every so often
> a library should be purged, things cannot be @depricated forever.
>
> Is it possible to tell Maven a library is not backwards compatible anymore?
>
> I usually use a major version increment for such steps (e.g. 1.x becomes
> 2.x). But even specifying ranges "[1.0,1.999]" combined with "[2.0,2.999]"
> do not cause an error of some kind, but simply resolve to 2.x.
>
> Kind regards,
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org