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<[email protected]> 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<[email protected]>
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<[email protected]>
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<[email protected]>
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
<[email protected]> 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
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
[email protected]<mailto:[email protected]>
*KnowledgePlaza<http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
*KnowledgePlaza<http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
[email protected]<mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
*KnowledgePlaza <http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
[email protected] <mailto:[email protected]>
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.
