ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <anto...@gmx.de>
Subject Re: Best Practice for declaring jdk/large jars as a dependency
Date Fri, 17 Apr 2009 07:49:46 GMT
Stephen Nesbitt wrote:
> All:
>
> I've poked around google and the email archive and  haven't been able to find a 
> discussion. So here's the question:
>
> How are peopling handling the declaration of a jdk or a large jar as a 
> dependency? Are you specifying them in the ivy.xml? What about retrieval? Are 
> you retrieving these large jars/jdk or is there some way to avoid the overhead 
> of retrieving/copying large artifacts?
>
> Thanks in advance
>
> -steve
>
> Stephen Nesbitt
>   
Hello Stephen,

I am not sure about the best practice. On build machines, I am not
declaring the JDK as a dependency in my build environment, I install it.
If your builds need to be aware of the location of several JDKs and
these paths are going to be different from one machine to another, you
may tackle that by creating a special property file, for instance in a
special custom subdirectory of the user 's home directory, such as
${user.home}/.build/jdk_location.properties.

There is one use case where I have uploaded one large dependency as a
zip file to ivy. I have uploaded the toplink workbench to the project
repository where I work. This one get's downloaded by the developers
from RAD using a custom launch configuration which runs an ant script
which does an ivy download. The ant script does a rough check to see
whether the workbench is already installed or not (maybe by looking at
the presence of the installation directory, or by looking up a special
class) and then goes on to do the ivy-resolve and ivy-retrieve only when
the rough check indicates that the workbench is not there. This is then
followed by unzipping the workbench. This has loopholes (if we want the
developers to use a new version of the workbench, then we would need to
instruct them to delete it) but this is very fast.

We have also uploaded to ivy a second JDK that our developers are using
in RAD for a task which does not work with the JDK supplied by RAD. What
we did was zipping the complete JDK from a Windows install, and
uploading the zip file to the project ivy repository. We have a script
to create the RAD workspace which downloads the JDK from the internal
ivy repository when it is detected missing (quick directory check), and
unzips it at a custom location.

Regards,

Antoine

Mime
View raw message