rickbryant | 20 Feb 21:36 2014

IvyDE latest.integration Unresolved Dependency Issue

Ivy Users,

We just completed integrating Ivy dependency management with our Ant build.
Our Ant build works wonderfully as Ivy successfully downloads all 100+
dependencies from our Artifactory repository, all source is then compiled
properly, and all packages are created properly. However, we just installed
IvyDE for Eclipse and we receive the following error when running
Ivy->Retrieve 'dependencies' from the Package Explorer context menu:
Some projects fail to be resolved
Impossible to resolve dependencies of com.gxs.csr#;working <at> TN-BRYANTR2
unresolved dependency: com.gxs#otx;latest.integration: not found
unresolved dependency: com.gxs.mbbi#DBCore;latest.integration: not found
unresolved dependency: com.gxs.dsm#DSMServiceClient;latest.integration: not
unresolved dependency: com.gxs.tgms.core#tgms-core;latest.integration: not
unresolved dependency: com.gxs#venus;latest.integration: not found
unresolved dependency: com.gxs.mbbi#edi2k;latest.integration: not found

IvyDE resolves ALL OTHER dependencies with no issues except the above 6
dependencies (these are the only ones that we have declared
rev="latest.integration" in the ivy.xml file). Here are the relevant
versions installed:
Eclipse: 4.3.0.I20130605-2000 (Kepler)
Ivy:      2.3.0.final_20130110142753
IvyDE:  2.2.0.final-201311091524-RELEASE

Is there some issue with IvyDE resolving latest.integration and how is this

(Continue reading)

Steve Newman | 13 Feb 00:15 2014

Ivy installation question

(Apologies for a very basic question, but I've searched the mailing list
archives and other online resources, and haven't been able to find an

I'm trying to do a build using Ivy, and I can't get past square one; Ant
doesn't seem to recognize Ivy:

> $ ant
> Buildfile: /home/ec2-user/lz4/lz4-java-master/build.xml
> init:
> /home/ec2-user/lz4/lz4-java-master/build.xml:86: Problem: failed to
create task or type antlib:org.apache.ivy.ant:resolve
> Cause: The name is undefined.
> Action: Check the spelling.
> Action: Check that any custom tasks/types have been declared.
> Action: Check that any <presetdef>/<macrodef> declarations have taken
> No types or tasks have been defined in this namespace yet
> This appears to be an antlib declaration.
> Action: Check that the implementing library exists in one of:
>         -/usr/share/ant/lib
>         -/home/ec2-user/.ant/lib
>         -a directory added on the command line with the -lib argument

I've downloaded the Ivy tarball, unpacked it, and put the .jar file and its
dependencies in /usr/share/ant/lib. I'm not sure what to try next. Any
(Continue reading)

rickbryant | 12 Feb 22:52 2014

Artifactory Publish Failure

Ivy Users,

We recently completed integration of Ivy dependency management with our
legacy Ant build and all of our dependency retrieves (Maven formatted) from
our Artifactory repository work without issue. However, we have encountered
an odd issue with Ivy publish.

When publishing two separate artifacts in the same build, the first artifact
and its associated POM are published successfully. Then the second artifact
is published successfully but its associated POM is not published and the
build fails:
[ivy:publish] DEPRECATED: 'ivy.conf.file' is deprecated, use
'ivy.settings.file' instead
[ivy:publish] :: loading settings :: file =
[ivy:publish] :: publishing :: com.gxs.csr#
[ivy:publish]   published ICSServicesClient to
[ivy:publish]   published ICSServicesClient to
[ivy:publish]   published ICSServicesUtilities

c:\Projects\CSR_trunk\Build\build2.xml:87: The following error occurred
while executing this line:
c:\Projects\CSR_trunk\Build\build2.xml:107: impossible to publish artifacts
for com.gxs.csr#;working <at> TN-BRYANTR2: java.io.IOException: PUT operation to
(Continue reading)

KARR, DAVID | 12 Feb 19:35 2014

Still trying to get timestamped snapshots downloading

I've been struggling for a while trying to figure out how to get Ivy to download a snapshot artifact.  I
originally posted a question about this on StackOverflow last week.  I got some good responses, but I'm not
getting any more traction on this.  I wanted to start over with a new post here summarizing what I know so far.

The crux of the problem appears to be that when my Maven build uploads a snapshot artifact, it gets stored in
the Nexus repository with a timestamp in the name.  When Ivy resolves and retrieves this artifact, the
resolve succeeds, but it doesn't retrieve because the file names don't match what is configured in the Ivy
repository definition.  I don't understand how to configure the repository definition so this will work.

I'll describe my configuration verbally, then show the files that specify this.

My app has 9 dependencies, 7 of which I get from Central, 1 of which I get from our thirdparty repo on our local
"MavenCentral" (it's an intranet Nexus Pro instance with a confusing name), and the one dependency I'm
trying to get from the snapshot repo on the same Nexus Pro instance.  The other 8 dependencies, including
the one from the thirdparty repo on the intranet Nexus Pro instance, resolve and retrieve without error.

I define four resolvers in my resolver chain:
* Local Maven repo
* Snapshots repo on Nexus Pro instance
* Thirdparty repo on Nexus Pro instance
* Central

I have one build target that resolves and retrieves all the dependencies.

If I look inside my Nexus Pro instance at the two artifacts I get from there (one thirdparty, and one
snapshot), I see the following off of the root directory specified in the repository definition in my
ivysettings.xml file:


(Continue reading)

gilloull | 12 Feb 15:08 2014

Publishing into Nexus repository - metadata not updated


I have a Maven project which has a dependency on an ANT project (different svn repositories).

I usually package my Ant project, upload it manually into my Nexus repository and update my pom with the new
version number.
This ANT project can have a lot (like 10) releases a day and doing this process manually is a mess.

I try to use Ivy for publishing this artifact into Nexus automatically and it works :)

The only problem is that maven-metadata.xml file in Nexus is not updated by Ivy when publishing my jar, so my
Maven project does not take the lastest release version.

Is there a way for Ivy to trigger an update of the maven-metadata.xml file into Nexus ? Or is my publish
process wrong ?

my publish target  : 

<ivy:publish resolver="nexus-deploy" revision="${artifact.version}" overwrite="false"
artifactspattern="${dist.dir}/[artifact](-[classifier]).[ext]" publishivy="true">

my resolver : 

<url name="nexus-deploy" m2compatible="true" >
<artifact pattern="${url.nexus.releases}/${ivy.pattern}"/>


(Continue reading)

Re: maven classifier on ant install task


I've been deleting my cache prior to running the build.

The only way I can seem to make this work is to have a second resolver which has
the classifier hard-coded, ie:

<chain name="chain" returnFirst="true" dual="true">

  <ibiblio name="central" m2compatible="true" checkconsistency="false"


  <ibiblio name="central2" m2compatible="true" checkconsistency="false"



This seems to work (at least all the jars I expect to find are being downloaded
to my local repo).

Cheers, Andy

> On 04 February 2014 at 06:55 Marc De Boeck <mdeboec@...> wrote:
>  You may have to remove the json-lib entry in your cache. Check also how the
> artifacts were stored in the cache. Could you find the jdk-specific artifacts
> there ?
(Continue reading)

KARR, DAVID | 7 Feb 18:44 2014

Why isn't ivy retrieving an artifact from repo?

I've had a prototype Ivy build working reasonably well.  I just looked at it today and I'm seeing that it's
finding an artifact on my intranet repo but not downloading it to the local cache or retrieving it in my
local build, which causes the build to fail.

The build specifies several other dependencies, most of which are found on mavencentral, and one in
another repo in the same local intranet repo that it's finding (but not downloading) the other artifact.

I've tried a few times to clear out the ivy cache and run this again, but it downloads all of the artifacts
except for this particular one.

First, here is the relevant output from the build, with some minor pieces elided:
:: Apache Ivy 2.3.0 - 20130110142753 :: http://ant.apache.org/ivy/ ::
:: loading settings :: file = <pathtoivysettingsxmlfile>
:: resolving dependencies :: com.att.ecom.poc#coherence_poc;working <at> <hostname> [not transitive]
	confs: [default]
	found com.att.ecom.poc#poc-domain-model;0.0.1-SNAPSHOT in mavenCentralSnapshots
	found org.apache.commons#commons-lang3;3.1 in central
	found org.springframework#spring-aop;4.0.0.RELEASE in central
	found org.springframework#spring-beans;4.0.0.RELEASE in central
	found org.springframework#spring-context;4.0.0.RELEASE in central
	found org.springframework#spring-core;4.0.0.RELEASE in central
	found org.springframework#spring-expression;4.0.0.RELEASE in central
	found org.springframework#spring-web;4.0.0.RELEASE in central
	found com.oracle.coherence#coherence;12.1.2-0-0 in mavenCentralThirdparty
:: resolution report :: resolve 351ms :: artifacts dl 8ms
	|                  |            modules            ||   artifacts   |
	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
(Continue reading)

KARR, DAVID | 29 Jan 23:32 2014

How to publish a directory tree, so it can be retrieved with the same structure?

I'm working on the same set of problems described in my earlier "How to publish additional metadata ..."
note.  I'd appreciate any responses with concrete examples to demonstrate how I should do this.

At the conclusion of the build, I need to publish the entire contents of the "build" directory, along with a
properties file ("env/default.properties") that isn't generated by the build, but which describes
where the build product has to be installed before EAR assembly.  When this "build" directory is
eventually retrieved at some later time, that same structure needs to be installed at the absolute path
described by one of the properties in that "env/default.properties" file.

If it matters, the "build" directory contains four directories, two of which contains jar files used for
different purposes, one of which contains a directory that contains a text file (special manifest file),
and the last contains a directory tree of properties files.

The entire build will have several similarly structured modules.  I'm pretty sure the target that does the
"ivy:publish" can be defined in a "base" build script that all the module build scripts import.

I imagine the "ivy.xml" for each module would have a "publications" element that specifies the two (?)
pieces that are being published, being the "build" directory and the "env/default.properties" file. 
I've never seen an example that publishes a directory, is that possible?  If not, then I would guess that I'd
have to specify more processing and detail in the "ivy:publish" target, such that I would first zip up the
"build" directory and the "env/default.properties" file both into a zip file and publish that as the
single artifact.  Is this more likely?

I've considered the fact that the "env/default.properties" file really only holds one property (ok two,
but I don't care about the other one).  It might make sense to instead define that property value in "extra"
attributes in the "ivy.xml" and drop the "env/default.properties" file entirely.  However, that sort of
combines two concerns, being the description of the artifact and its dependencies, along with where the
artifact gets installed to for EAR assembly.

One minor detail: I didn't see in the "publish" documentation how you specify where the "ivysettings.xml"
(Continue reading)

KARR, DAVID | 29 Jan 22:03 2014

Can Ivy be used to figure out the correct order to build a set of modules, based on the dependency hierarchy?

With Maven, the modules listed in an aggregator POM are not built in the order they appear in the list, they
are built in the "right" order depending on the dependency relationship between the modules. 
Essentially, the "next" module to be built is the one with no afferent dependencies from any other module
in the list (of the ones remaining to be built).

Does Apache Ivy provide anything like this, if only the ability to generate some of the required pieces, to
be assembled somehow?

maven classifier on ant install task


I've been having a go at using the Ivy Install ant task to create a local
repository based on libraries downloaded from maven central.

Having gone along with the tutorial, all seemed to be working :)


One of the dependencies in my project is json-lib.

It seems that the json-lib project uses a maven classifier to discriminate
between jars suitable for different versions of the jvm.

If I were just declaring a dependency I think I could do this:


However, I'm using install tasks that look like:

<ivy:install organisation="log4j" module="log4j" revision="1.2.17" from="chain"
to="fs1" transitive="true" overwrite="true"/>

How should I declare the "classifier" on an "install" task?

(Continue reading)

KARR, DAVID | 28 Jan 01:20 2014

How to publish additional metadata with an artifact that is needed at retrieve time

I'm trying to envision how I can use Ivy for ATG Dynamo module dependencies.

For background, retrieving a dependent ATG module requires getting the lib, config, and manifest pieces
and copying them into a directory in your local ATG tree with a directory name dependent on the artifact
you're retrieving.  The directory name to use is available in a properties file that is available when the
module is built.

I'm ok with the separate "lib, config, and manifest" pieces, because all of those are packaged in a single
"build" directory when building the module.

However, when retrieving this artifact, I'm unsure how to deal with knowing what directory in the ATG tree
to unzip (not to mention knowing to unzip, not just to copy) the artifact to.  This information is available
when building the module, so it can be available when publishing.

I suppose I could publish an additional file in the zip file which is the properties file used in the build of
the module.  My task which retrieves the artifact could first retrieve the zip, unpack it into a temp
directory, read the properties file that I unpacked, and then copy in everything but the properties file
into the target directory.

I know that most of you won't be familiar with ATG Dynamo, but does any of this make sense?