ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thorburn <>
Subject ivy:install task - Comments/Criticisms/Bugs
Date Thu, 08 Apr 2010 09:46:29 GMT
I've been spending a fair amount of time with the Ivy install task
recently, attempting to set up a repository for work. I had one
previously, but I had managed that by hand. That worked fine, except
that the ivy files I produced were incompatible with the ones produced
by the ivy:install task...

Part of the reason for using the ivy:install task in the first place
is that I needed to include Axis 2 + Rampart in a project, and I sure
as hell didn't want to manually process all those JARs, so I've spent
a while trying to get this working, both for Axis, and for the other
JARs the project uses. As such, I've made the following observations:

1) The Maven 2 repository has more than a little crap in it. I don't
mean this in the sense of inconsistent organisation/module names
(which can generally be fixed with namespaces), but more that there
are several projects out there that make use of other repositories,
and I'm not entirely sure why (opensaml is the main offender here, in
my eyes, though Jasper Reports has also done it), which just makes it
a pain to copy a project with lots of dependencies, like Jasper
(funny, that). I'm not sure what Ivy can do about that, except,
perhaps, automatically adding repositories defined in a POM as a
source for all non-transitive dependencies (except those dependencies
which are actually *on* that repository, of course).

The install task is really limiting. Really, really limiting. Here's a
quick list of things I would like to be able to do:

2) Ability to specify multiple modules at once, and to say 'don't
overwrite and don't fail if present', which achieves a few things.
First, I'm installing more than one module here (roughly 20), and I'm
not super-happy about the fact that I have to specify one install task
for each, as that typically results in multiple versions of projects
being installed (Apaches commons is especially prone to that). Now,
this might someones be a good thing, but I know that all the modules
I'm installing are going to be used by a single project, and it's just
annoying to have more than one installed. The other problem is that
each install task will install another copy of a library that already
exists with the same version (e.g. commons-logging 1.1.1), and while
that's not a problem while developing the repository, I'm not sure I'd
like that to happen when installing to the company repository. It also
means unnecessary downloads of artifacts.

3) Ability to exclude/ignore dependencies. Log4J, for example, depends
on various Sun libraries that aren't included on any repository, so to
get it to install without error, I have to set transitive="false" and
add the other dependencies as yet more install tasks. There are also
other cases where I might not want to try and install a dependency.
I'm not sure if I would want them to be excluded from the Ivy file, or
simply not downloaded, but still included in the Ivy file.

4) Ability to manually specify publications. Case in point:
net.sf.json-lib#json-lib;2.3 - that does not have the standard
artifacts (1 jar, 1 source, 1 javadoc), rather it has two 'binary'
(JARs with class files) artifacts (json-lib-2.3-jdk15.jar, and
json-lib-2.3-jdk13.jar), each with their own sources and javadocs. At
this stage, I'm not sure how I'd go about installing them with the
install task. In fact, I'm quite sure I can't, and that I will have to
install it manually. Bugger.

5) Ability to revise revisions. At present, if I want all projects to
have at least, say, a 3 digit revision number (e.g. 1.2.3), that's not
possible as I get the following error when the following rule is

public: bad revision found in
expected='4.7 found='4.7.0'

					<src org="org.junit" module="junit" rev="4.7.0" />
					<dest org="$m0" module="$m0" rev="4.7" />
					<src org="junit" module="junit" rev="4.7" />
					<dest org="org.$o0" module="$m0" rev="4.7.0" />

I'm fairly sure that's a bug, but I'm not certain.

6) Not having to specify parent projects first. e.g. I have to do the following:

		<ivy:install organisation="" module="xmlrpc"
revision="3.0"  from="installerChain" to="local" transitive="true"
overwrite="true" />


		<ivy:install organisation="" module="xmlrpc-common"
revision="3.0"  from="installerChain" to="local" transitive="true"
overwrite="true" />

Otherwise it fails with an error similar to 5, provided I'm using a
rule to change something about the project. In this case, changing the
organisation from org.apache.xmlrpc to Again, fairly
sure that's a bug, but not certain.

7) This is almost certainly an Ant problem, but I mention it here
because it drove me up the wall: My work proxy (squid) caches things,
like Ivy files. I made a change to an ivy.xml file for a particular
project (before I decided to Nuke the whole repository and start
again), and it wouldn't pick it up. Took me ages to work out that it
was being cached by squid. In the end, I didn't see a way to make ant
send the correct headers, so I had to do a 'wget --no-cache
http://path/to/file.xml' to get Ivy to pick it up... Very, very
frustrating... Need a way to tell Ant that it should include the
No-Caching headers or something...

8) If chainrules is false, then the first matching rule that applies
should be the only one used. This matters in the following case:

					<src org="org.apache.commons" module="commons-.+" />
					<dest org="$m0" module="$m0" />
					<src org="commons-.+" module="commons-.+" />
					<dest org="org.apache.commons" module="$m0" />

Now, that rule is fairly innocuous, and would work as expected if
there were not commons-parent projects in the org.apache.commons
organisation in the Maven Repo (see #1 about the repo being crap). So
this rule applies the fromsystem rule for the parent projects,
resulting in commons-parent#commons-parent;7 - oops.

I figured I could fix that by using the following rule:

					<src org="org.apache.commons" module="commons-parent" />
					<dest org="$o0" module="$m0" />
					<src org="org.apache.commons" module="commons-parent" />
					<dest org="$o0" module="$m0" />

But that doesn't work - it seems to apply both rules, regardless of
which way around they are (I think), which means I'm forced to use

					<src org="org.apache.commons" module="(commons-attributes).*" />
					<src org="org.apache.commons" module="(commons-beanutils).*" />
					<src org="org.apache.commons" module="(commons-betwixt)" />
					<src org="org.apache.commons" module="(commons-chain)" />
					<src org="org.apache.commons" module="(commons-cli)" />
					<src org="org.apache.commons" module="(commons-codec)" />
					<src org="org.apache.commons" module="(commons-collections)" />
					<src org="org.apache.commons" module="(commons-compress)" />
					<src org="org.apache.commons" module="(commons-configuration)" />
					<src org="org.apache.commons" module="(commons-daemon)" />
					<src org="org.apache.commons" module="(commons-dbcp)" />
					<src org="org.apache.commons" module="(commons-dbutils)" />
					<src org="org.apache.commons" module="(commons-digester)" />
					<src org="org.apache.commons" module="(commons-discovery)" />
					<src org="org.apache.commons" module="(commons-el)" />
					<src org="org.apache.commons" module="(commons-email)" />
					<src org="org.apache.commons" module="(commons-exec)" />
					<src org="org.apache.commons" module="(commons-fileupload)" />
					<src org="org.apache.commons" module="(commons-httpclient)" />
					<src org="org.apache.commons" module="(commons-io)" />
					<src org="org.apache.commons" module="(commons-jci)" />
					<src org="org.apache.commons" module="(commons-jelly)" />
					<src org="org.apache.commons" module="(commons-jexl)" />
					<src org="org.apache.commons" module="(commons-jxpath)" />
					<src org="org.apache.commons" module="(commons-lang)" />
					<src org="org.apache.commons" module="(commons-launcher)" />
					<src org="org.apache.commons" module="(commons-logging)" />
					<src org="org.apache.commons" module="(commons-math)" />
					<src org="org.apache.commons" module="(commons-modeler)" />
					<src org="org.apache.commons" module="(commons-net)" />
					<src org="org.apache.commons" module="(commons-pool)" />
					<src org="org.apache.commons" module="(commons-primitives)" />
					<src org="org.apache.commons" module="(commons-proxy)" />
					<src org="org.apache.commons" module="(commons-sanselan)" />
					<src org="org.apache.commons" module="(commons-scxml)" />
					<src org="org.apache.commons" module="(commons-transaction)" />
					<src org="org.apache.commons" module="(commons-validator)" />
					<src org="org.apache.commons" module="(commons-vfs)" />
					<dest org="$m1" module="$m0" />
					<src org="commons-.+" module="commons-.+" />
					<dest org="org.apache.commons" module="$m0" />

Which is a little ugly.

9) Support relocations or the ability to override versions. e.g.
xml-apis#xml-apis;2.0.2 has been relocated to
xml-apis#xml-apis;1.0.b2, but Ivy fails, telling me to depend directly
on the new version. Well, if I could, that would be awesome, but I
can't because I have no choice about what revision a transitive
dependency uses. So, I have to use the following rule instead:

					<src org="org.apache.xml" module="xml-apis"/>
					<dest org="$m0" />
					<src org="xml-apis" module="xml-apis" rev="2.0.2" />
					<dest org="org.apache.xml" module="$m0" rev="1.0.b2" />

Which works, despite #6 above not working.

10) Support installing source and javadoc artifacts transitively. I
know that it installs them for the artifact I've declared in the
install task, which is nice, but I really, really wish it would
install them for all artifacts. As it is, it's now a 3-step process
instead of a one-step process (1: Ivy install task of top-level
dependency to get all transitive dependencies, 2: run script to get
org/module/revision for all installed modules and generate an ant file
just for them, 3: run the new ant file to install all dependencies,
this time with source/javadoc artifacts but transitive set to false).

So creating an ivy repository from the maven repository works, but
it's not a simple process. There are things that I will have to
install manually (some of which aren't on any public repository, some
of Ivy just doesn't like), and there are way too many repositories
around for my liking - I have to have 6 to get everything I want
installed. And installing source/javadoc artifacts is a pain.

I still like Ivy, and I think it's more flexible than Maven, but it
seems like it still has a long way to go before setting up a
repository is actually a simple operation.

If you would like to raise a Jira ticket for anything here, let me
know. I think some of them may already have Jira tickets, but I'm not
certain about that.


- Andrew Thorburn

View raw message