Resolving identical depedencies

[Marcel Overdijk <ma...@gmail.com>]

When having dynamic properties in ivy.xml I wonder if it's possible to
guarantee that identical dependencies are resolved on different
systems/different builds.

E.g. dependency hibernate 3.6.+

Which version will be resolved now?

Does it check online what tha latest version is in the range, or does it
check if there is an compatible version available in the local Ivy repo?
And what if machine (A) has vesion 3.6.6 in it's local Ivy repo and machine
(B) has version 3.6.7?

A simple solution for this would be just defining a fixed version for the
hibernate dependency.

But..., this goes further if the dependency itself contains transitive
dependencies which has a dynamic version specified. 

If I look in the Ruby world there is Bundler which also support dynamic
depdencies and for the above problem they support the notion of lock files.
Even though the versions of dependecies (including transitive dependencies)
might be dynamic, you can make a kind of snapshot file (a lock) which
contains the exact dependency version. 

Is there something similar possible with Ivy? 


Regards, 
Marcel 
-- 
View this message in context: http://old.nabble.com/Resolving-identical-depedencies-tp34784074p34784074.html
Sent from the ivy-user mailing list archive at Nabble.com.

Re: Resolving identical depedencies

[Marcel Overdijk <ma...@gmail.com>]

Thanks for your detailed answer (even not intending to it ;-)

You explanationwas very clear, expecially mentioning the replacedynamicrev
option which in our case should be enough for now. 

If anybody recalls how to use the equivalent of lock files in Ivy (as you
think it's possible) please let me know.


Thanks again,
Marcel
-- 
View this message in context: http://old.nabble.com/Resolving-identical-depedencies-tp34784074p34787216.html
Sent from the ivy-user mailing list archive at Nabble.com.

Re: Resolving identical depedencies

[Mitch Gitman <mg...@gmail.com>]

If no one else is biting, I'll try to field these questions.

You ask: " Does (Ivy) check online what tha latest version is in the range,
or does it
check if there is an compatible version available in the local Ivy repo?"

First some terminology. When you say local Ivy repo, what you're really
talking about is the Ivy cache. There might be a separate local Ivy
repository to which you publish modules on local builds.

By default, Ivy trusts the cache. So if two months ago, Ivy downloaded
Hibernate 3.6.6, then as long as you don't clear out your cache, that's
what Ivy will use.

Look in the Ivy settings documentation for how to configure Ivy to not
trust the cache. But normally you'll not trust the cache only for modules
under active development:
http://ant.apache.org/ivy/history/latest-milestone/settings.html

OK, that's the objective technical part of your question. We get into the
subjective part when you suggest: "A simple solution for this would be just
defining a fixed version for the hibernate dependency."

Effectively, Ivy does this by default when you go to publish your module,
whether to a local repo or a shared/enterprise repo—when the ivy.xml file
goes from being a source file to a published document/artifact together
with the other artifacts. See the replacedynamicrev attribute on the
ivy:deliver and ivy:publish Ant tasks:
http://ant.apache.org/ivy/history/latest-milestone/use/deliver.html
http://ant.apache.org/ivy/history/latest-milestone/use/publish.html

Note that its default value is true.

And I should say that this is really a best practice—on release builds and
CI builds, and (though there's maybe a less compelling case) on developers'
working builds. I don't want to say there's a consensus around this, but if
someone tells you otherwise, they're probably full of it. Someone could
argue, "Don't you want to specify something like 1.1.+ and automatically
get the latest bug fix when it comes out?" But this is a case where better
isn't necessarily better. What you want—especially with shared modules'
dependencies—are reproducible builds. So if you depend on foo
1.1.0-20121211194201, you'll know that you'll get all the exact-same
versions of foo's dependencies, regardless of whether you build it today or
a year from today. The premium is on having reproducible builds. If you
want to pick up Hibernate 3.6.7, then pick it up in the next version of foo.

I would go one step further and recommend that, when it comes to
third-party libraries or libraries that are coming perhaps from some other
part of your company and you're not actively developing, you should specify
a hard-coded version dependency even in your unpublished, source ivy.xml.
So you explicitly control when you want to get the next version of
Hibernate. You still want replacedynamicrev="true", but for these
dependencies, it's beside the point.

You ask about the risk of version ranges showing up in transitive
dependencies. As I just suggested, this should only show up in modules
whose developers don't respect reproducibility. As I recall, such things
are rare, but not nonexistent, in a public repo like Maven Central. One way
to prevent this is to install third-party dependencies from a public
repository to your own enterprise repository, where you can mandate
hard-coded versions on published modules. I could swear there is a way to
do the equivalent of lock files in Ivy; I just don't recall what that is.
Maybe someone else out there can chime in.

I wasn't intending to go into such detail here, but you asked some involved
questions. I probably won't have time to follow up.

On Tue, Dec 11, 2012 at 7:30 AM, Marcel Overdijk
<ma...@gmail.com>wrote:

>
> When having dynamic properties in ivy.xml I wonder if it's possible to
> guarantee that identical dependencies are resolved on different
> systems/different builds.
>
> E.g. dependency hibernate 3.6.+
>
> Which version will be resolved now?
>
> Does it check online what tha latest version is in the range, or does it
> check if there is an compatible version available in the local Ivy repo?
> And what if machine (A) has vesion 3.6.6 in it's local Ivy repo and machine
> (B) has version 3.6.7?
>
> A simple solution for this would be just defining a fixed version for the
> hibernate dependency.
>
> But..., this goes further if the dependency itself contains transitive
> dependencies which has a dynamic version specified.
>
> If I look in the Ruby world there is Bundler which also support dynamic
> depdencies and for the above problem they support the notion of lock files.
> Even though the versions of dependecies (including transitive dependencies)
> might be dynamic, you can make a kind of snapshot file (a lock) which
> contains the exact dependency version.
>
> Is there something similar possible with Ivy?
>
>
> Regards,
> Marcel
> --
> View this message in context:
> http://old.nabble.com/Resolving-identical-depedencies-tp34784074p34784074.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>