ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garner, Shawn" <>
Subject RE: questions on ivy usage/setup
Date Thu, 09 Jun 2011 14:46:00 GMT
I haven't had any response to any of this yet.
Can anyone help me or offer any guidance?


-----Original Message-----
From: Garner, Shawn [] 
Sent: Tuesday, June 07, 2011 11:14 AM
Subject: questions on ivy usage/setup

I am doing a sample evaluation of Ivy and seeing how we can incorporate it into both our continuous
integration build which uses ANT scripts today and also we'll need it to work for developer's
IDE (RAD) on their workstations.
We have some custom ant tasks which do quite a bit of work of dependency and classpath resolution
already but I'm not sure if custom ant tasks are the best thing.
I have a few questions on use of Ivy.

Question 1.
We use Websphere and a lot of our apps either depend on one of the runtimes of 6.1 or 7.0
and/or one of it's JDK's 1.5 or 1.6.
I wrote an ivy file and installed it in my ivy repository (artifactory) which works however:
1) I don't like that it copies the JARs to my provided configuration directory (also the cache)
for each project.
2) I don't want to re-publish it to my repository (artifactory) if we apply patches to the
runtimes or jdks.
I'd like to use the FileSystemResolver and use symbolic links however it doesn't seem like
it's setup to use something that's organized in an Ivy repository layout which Websphere does
not obey whatsoever.
Do I have to write a custom resolver to do this?  If so is there any documentation on how
to do this?

Question 2.
Currently we build EJB, Web Projects, and Utility Jars that depend on Jars in the EAR file.
Sometimes it's just Jars that contain properties files or generated content that is generated
from a temporary project then jar'd up and no formal project is kept.
Is there any way to find (resolve, retrieve) those jars without publishing them?  It seems
kind of silly to publish/resolve/retrieve them to the repository if they are only ever used
in building one ear.

Question 3.
How do others handle modifying the MANIFEST.MF file for Class-Path attribute?
My understanding is unless the EJB, War, or utility jar in the EAR declare it in their manifest
file that Websphere won't load it.
With the dynamic nature of ivy I expected there to be something to help with this but didn't
find it.
Sometimes you need a runtime jar declared in there and sometimes you need a compile or default
config jar in there.
It would be nice if there were a manifest section and you could generate the manifest from
the dependencies somehow.

Question 4.
I have my artifactory repository installed locally I'm sure everything is cached in my local
cache and also in artifactory.
However if I disconnect my laptop from the internet (I know it's weird today) I would like
it to retrieve everything from the cache if it can't connect.
It seemed like my builds would fail if I was disconnected.
Is there a way to do this if there is no internet connectivity?  I wasn't seeing any configurations
to say default to local cache if it's there.
Currently I'm using the URL  resolver pointing to artifactory for local projects (internal
projects) and another ibiblio resolver point to artifactory for remote repositories.

I appreciate any help or advice others have on this.

-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

View raw message