FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 02-10-2011, 12:49 PM
Thomas Koch
 
Default Dependence on specific versions

Hi Stefane,

in another thread you write:

> > and that it is possible for projects to accumulate
> > technical debt by depending on strict version numbers.
>
> OTOH, this is a HUGE source of instability and hard to debug bugs (as we've
found to our expense) to depend on loose version numbers.

I totaly disagree with this. One day or another you need to update to newer
versions of your dependencies. If you're specifying strict version numbers
then you're just procrasinating the update.

Instead, you (as in all java projects) should include the expected behaviour
of the dependencies in your test cases. How should you update them otherwise?

If your test cases work with any versions of the dependencies provided, then
your product should work.

You may say that "business realities" are different. But then you tell me that
business software just means: Software that happens to work today, but who
knows about tomorrow?

Or am I totally wrong?

Best regards,

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102101449.15516.thomas@koch.ro">http://lists.debian.org/201102101449.15516.thomas@koch.ro
 
Old 02-10-2011, 01:25 PM
Stefane Fermigier
 
Default Dependence on specific versions

On Feb 10, 2011, at 2:49 PM, Thomas Koch wrote:

> Hi Stefane,
>
> in another thread you write:
>
>>> and that it is possible for projects to accumulate
>>> technical debt by depending on strict version numbers.
>>
>> OTOH, this is a HUGE source of instability and hard to debug bugs (as we've
> found to our expense) to depend on loose version numbers.
>
> I totaly disagree with this. One day or another you need to update to newer
> versions of your dependencies. If you're specifying strict version numbers
> then you're just procrasinating the update.
>
> Instead, you (as in all java projects) should include the expected behaviour
> of the dependencies in your test cases. How should you update them otherwise?
>
> If your test cases work with any versions of the dependencies provided, then
> your product should work.
>
> You may say that "business realities" are different. But then you tell me that
> business software just means: Software that happens to work today, but who
> knows about tomorrow?
>
> Or am I totally wrong?

Definitevely.

Only by fixing version numbers of third-party libraries can you be sure that the same build that works today will still work next week, if you redo the build on the exact same version of the sources (and Maven, and Java, of course), any operating system.

Yes, we do upgrade third-party lib versions from time to time, but only when there is a good reason to ("if it ain't broke, don't fix it").

BTW: I used to think like you 3-4 years ago when I discovered Maven, but had to change my mind due to the reality.

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 946AEA93-55E3-406A-9F78-A1B493B1EFDF@nuxeo.com">http://lists.debian.org/946AEA93-55E3-406A-9F78-A1B493B1EFDF@nuxeo.com
 
Old 02-10-2011, 05:50 PM
Russ Allbery
 
Default Dependence on specific versions

Stefane Fermigier <sf@nuxeo.com> writes:

> Only by fixing version numbers of third-party libraries can you be sure
> that the same build that works today will still work next week, if you
> redo the build on the exact same version of the sources (and Maven, and
> Java, of course), any operating system.

> Yes, we do upgrade third-party lib versions from time to time, but only
> when there is a good reason to ("if it ain't broke, don't fix it").

> BTW: I used to think like you 3-4 years ago when I discovered Maven, but
> had to change my mind due to the reality.

For those of us who have been doing this sort of thing for a while, this
argument sounds very familiar. I've heard this argument applied to C
libraries, Perl modules, Python modules, and most recently Ruby modules.
It always sounds persuasive when presented from a stability perspective.
It has always proven to be completely wrong in the long run.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877hd7lo5w.fsf@windlord.stanford.edu">http://lists.debian.org/877hd7lo5w.fsf@windlord.stanford.edu
 
Old 02-10-2011, 07:29 PM
Stefane Fermigier
 
Default Dependence on specific versions

On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:

> Stefane Fermigier <sf@nuxeo.com> writes:
>
>> Only by fixing version numbers of third-party libraries can you be sure
>> that the same build that works today will still work next week, if you
>> redo the build on the exact same version of the sources (and Maven, and
>> Java, of course), any operating system.
>
>> Yes, we do upgrade third-party lib versions from time to time, but only
>> when there is a good reason to ("if it ain't broke, don't fix it").
>
>> BTW: I used to think like you 3-4 years ago when I discovered Maven, but
>> had to change my mind due to the reality.
>
> For those of us who have been doing this sort of thing for a while, this
> argument sounds very familiar. I've heard this argument applied to C
> libraries, Perl modules, Python modules, and most recently Ruby modules.
> It always sounds persuasive when presented from a stability perspective.
> It has always proven to be completely wrong in the long run.

Please develop, unless you want me to believe you only based on your reputation, which I won't since I don't know you.

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 623FE8AB-BCDC-4856-9E5F-863FB20FE584@nuxeo.com">http://lists.debian.org/623FE8AB-BCDC-4856-9E5F-863FB20FE584@nuxeo.com
 
Old 02-10-2011, 07:38 PM
Torsten Werner
 
Default Dependence on specific versions

Hi Stefane,


On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier <sf@nuxeo.com> wrote:
> Only by fixing version numbers of third-party libraries can you be sure that the same build that works today will still work next week, if you redo the build on the exact same version of the sources (and Maven, and Java, of course), any operating system.

that sounds good but at least Maven does not really support fixed
dependencies. Example:

a.jar (0.1) depends on b.jar (0.1)
c.jar (0.3) depends on b.jar (0.2)
d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)

What version of b.jar will be chosen by Maven? 0.1 or 0.2? You cannot
predict that. Neither a.jar nor c.jar can rely on getting the version
they want.

That is why the concept of fixed version dependencies is fully broken, sorry.


Cheers,
Torsten


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikH_XnvsAF4SzBnD-wLioeo-g=LRE6V_qwtWeg6@mail.gmail.com">http://lists.debian.org/AANLkTikH_XnvsAF4SzBnD-wLioeo-g=LRE6V_qwtWeg6@mail.gmail.com
 
Old 02-10-2011, 07:47 PM
Stefane Fermigier
 
Default Dependence on specific versions

On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:

> Hi Stefane,
>
>
> On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier <sf@nuxeo.com> wrote:
>> Only by fixing version numbers of third-party libraries can you be sure that the same build that works today will still work next week, if you redo the build on the exact same version of the sources (and Maven, and Java, of course), any operating system.
>
> that sounds good but at least Maven does not really support fixed
> dependencies. Example:
>
> a.jar (0.1) depends on b.jar (0.1)
> c.jar (0.3) depends on b.jar (0.2)
> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)
>
> What version of b.jar will be chosen by Maven? 0.1 or 0.2? You cannot
> predict that. Neither a.jar nor c.jar can rely on getting the version
> they want.
>
> That is why the concept of fixed version dependencies is fully broken, sorry.

A lot of things are wrong in Maven, but it this case, you just ask maven to use a fixed version of the dependency in the dependencyManagement section of your POM, and voila.

See our master POM for examples: http://hg.nuxeo.org/nuxeo/file/20953aeee544/pom.xml

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 7A03B93F-5B8A-4F36-9498-763D8B323E45@nuxeo.com">http://lists.debian.org/7A03B93F-5B8A-4F36-9498-763D8B323E45@nuxeo.com
 
Old 02-10-2011, 08:02 PM
Torsten Werner
 
Default Dependence on specific versions

On Thu, Feb 10, 2011 at 9:47 PM, Stefane Fermigier <sf@nuxeo.com> wrote:
> On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
>> a.jar (0.1) depends on b.jar (0.1)
>> c.jar (0.3) depends on b.jar (0.2)
>> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)
>
> A lot of things are wrong in Maven, but it this case, you just ask maven to use a fixed version of the dependency in the dependencyManagement section of your POM, and voila.

No, if you choose b.jar (0.1) then c.jar (0.3) does not git its
preferred version. If you choose b.jar (0.2) then a.jar (0.1) does not
get its preferred version. That means either a.jar or c.jar will get a
non preferred version. What is the point of specifying fixed versions
if you cannot rely on getting them?

Torsten


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinWCvAHD2iNQX2xJr6EG=1Uy-=Qzr2AL0L9gS9w@mail.gmail.com">http://lists.debian.org/AANLkTinWCvAHD2iNQX2xJr6EG=1Uy-=Qzr2AL0L9gS9w@mail.gmail.com
 
Old 02-10-2011, 08:10 PM
Stefane Fermigier
 
Default Dependence on specific versions

On Feb 10, 2011, at 10:02 PM, Torsten Werner wrote:

> On Thu, Feb 10, 2011 at 9:47 PM, Stefane Fermigier <sf@nuxeo.com> wrote:
>> On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:
>>> a.jar (0.1) depends on b.jar (0.1)
>>> c.jar (0.3) depends on b.jar (0.2)
>>> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)
>>
>> A lot of things are wrong in Maven, but it this case, you just ask maven to use a fixed version of the dependency in the dependencyManagement section of your POM, and voila.
>
> No, if you choose b.jar (0.1) then c.jar (0.3) does not git its
> preferred version. If you choose b.jar (0.2) then a.jar (0.1) does not
> get its preferred version. That means either a.jar or c.jar will get a
> non preferred version. What is the point of specifying fixed versions
> if you cannot rely on getting them?

As the developer of d.jar, I get to choose which version of a.jar, b.jar and c.jar I will assemble in my application.

When a situation such as the one you describe occurs, I have to make a choice, even if it's not the one advertised by the dependencies authors.

Then it's my responsibility to test the hell out of the application and make sure that it's working.

Do not confuse application development and library development, BTW.

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: B9FA1892-21D0-4EE0-A66D-6DAA1C35C9AB@nuxeo.com">http://lists.debian.org/B9FA1892-21D0-4EE0-A66D-6DAA1C35C9AB@nuxeo.com
 
Old 02-10-2011, 08:23 PM
Thomas Zeeman
 
Default Dependence on specific versions

On Feb 10, 2011, at 9:38 PM, Torsten Werner wrote:

> Hi Stefane,
>
>
> On Thu, Feb 10, 2011 at 3:25 PM, Stefane Fermigier <sf@nuxeo.com> wrote:
>> Only by fixing version numbers of third-party libraries can you be sure that the same build that works today will still work next week, if you redo the build on the exact same version of the sources (and Maven, and Java, of course), any operating system.
>
> that sounds good but at least Maven does not really support fixed
> dependencies. Example:
>
> a.jar (0.1) depends on b.jar (0.1)
> c.jar (0.3) depends on b.jar (0.2)
> d.jar (0.4) depends on a.jar (0.1) and c.jar (0.3)
>
> What version of b.jar will be chosen by Maven? 0.1 or 0.2? You cannot
> predict that. Neither a.jar nor c.jar can rely on getting the version
> they want.
>

Actually, you can predict it. Given the above order and no outside influences like a dependencyManagement block in your (parent) pom, it would be 0.1. See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html for a more detailed explanation on why this is and what surprising results the dependency mediation can have.

If a and c depend on the same part of the API of b and it has changed from .1 to .2 you will be in for either some spectacular failure at run time or some very subtle and hard to notice error in your application behaviour.

Kind regards,
Thomas



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: FF3AEA4E-7D14-4E3A-A111-977A11F99AAD@xs4all.nl">http://lists.debian.org/FF3AEA4E-7D14-4E3A-A111-977A11F99AAD@xs4all.nl
 
Old 02-10-2011, 08:40 PM
"Jesús M. Navarro"
 
Default Dependence on specific versions

Hi, Stefane:

On Thursday 10 February 2011 21:29:34 Stefane Fermigier wrote:
> On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
> > Stefane Fermigier <sf@nuxeo.com> writes:
> >> Only by fixing version numbers of third-party libraries can you be sure
> >> that the same build that works today will still work next week, if you
> >> redo the build on the exact same version of the sources (and Maven, and
> >> Java, of course), any operating system.
> >>
> >> Yes, we do upgrade third-party lib versions from time to time, but only
> >> when there is a good reason to ("if it ain't broke, don't fix it").
> >>
> >> BTW: I used to think like you 3-4 years ago when I discovered Maven, but
> >> had to change my mind due to the reality.
> >
> > For those of us who have been doing this sort of thing for a while, this
> > argument sounds very familiar. I've heard this argument applied to C
> > libraries, Perl modules, Python modules, and most recently Ruby modules.
> > It always sounds persuasive when presented from a stability perspective.
> > It has always proven to be completely wrong in the long run.
>
> Please develop, unless you want me to believe you only based on your
> reputation, which I won't since I don't know you.

I'll give my opinion here: both Russ and you are right.

Yes, you are right: in order to distribute a product you must have to be able
to reproduce it unambiguosly from your sources. This implies all your
dependencies must be hardcoded.

But in the case of Java (and Ruby, and Python), making this on development is
nothing but a dirty hack to cover the malpractices of the developers.

Your development environment should rely at most on minor versions of its
dependencies and let the extraversion float as the upstream developer see fit
because said upstream developer will have the acumen not to break backwards
compatibility between extraversions and, in fact, will use extraversions only
for bug fixing (and those you definetly want as soon as they are published).
Your developers, on the other hand, will need to defend their position if
your app is happening to be using two different versions of the same
component and, no, telling "that's what X-tool pushed into my environment",
or "that's the uberbleeding edge version from the upstream developer out of
his nightly builds" is not a proper answer.

So, if your app depends on, say, foo_1.2.3, your dependency checking will look
for foo_1.2 or even "just" for foo_1. This will allow your continous
building environment to fail early if it happens that foo_1.2.(x+1) or foo_1.
(x+1) are not backwards compatible, analyze why and act accordingly. Of
course, once the shinny new version of your app is ready, you will freeze
your building environment for that version to whatever happens to be the
exact versions of dependant libs at the moment.

If you don't do that already is because you know that your app will fail
day-in day-out because foo developer (and bar, and zoot...) is not sensible
enough not to break backwards compatibility between foo_1.2.3 and foo_1.2.4.
Russ is right in that when things go that way, things are completly wrong in
the long run in so many manners it's not even funny. The fact this behaviour
is "business as usual" on Java development it's only a measure of its average
quality.

Oh! and another hint: "if ain't broken don't fix it" is not such a valuable
knowledge with regards to open source if only because of the outer testing
base and the work it takes to jump over more than a few releases
(exponential, not linear, to the distance).

Cheers.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102102240.15157.jesus.navarro@undominio.net">ht tp://lists.debian.org/201102102240.15157.jesus.navarro@undominio.net
 

Thread Tools




All times are GMT. The time now is 01:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org