maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Eugelink <T.Eugel...@knowledgeplaza.nl>
Subject Re: breaking backwards compatibility
Date Wed, 13 Apr 2011 14:47:19 GMT
  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.Eugelink@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.Eugelink@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<adam.s.gibbons@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<bimargulies@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
>>>>>>> <joerg.schaible@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
>>>>>>>>
>>>>>>>>> <joerg.schaible@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<mailto:t.eugelink@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<mailto:info@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<mailto:t.eugelink@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<mailto:info@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 <mailto:t.eugelink@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 <mailto:info@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.









Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message