ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Evans (IT)" <>
Subject Re: ivy:install task - Comments/Criticisms/Bugs
Date Thu, 08 Apr 2010 16:02:59 GMT
> 1) The Maven 2 repository has more than a little crap in it. <snip>

That's really a problem with the Maven repository and not Ivy itself.
As much as I would love for the whole Maven integration to work more
smoothly, I can't really justify blame Ivy for not being able to
handle this.

> 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. <snip>

"Don't overwrite and don't fail if present" would be great, I agree.
As for the multiple versions thing... what can Ivy really do?  Those
are a byproduct of sloppy POMs (which are outside the scope of Ivy).
If some module is saying, "I require revision 1.2.2 of Blah", Ivy
can't just assume it would work with revision 1.2.3 of Blah.  The
problem should be fixed by having the module depend on a dynamic
revision of Blah, which is possible in Ivy, but again I don't know
about Maven, which it sounds like you're sourcing everything from.

> 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.

You can definitely exclude specific modules; I have done it.

> 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.

You can always use a dual resolver, with one of the resolvers pointing
to the public URL, and another local filesystem resolver to pick up
the "missing artifacts", which you would manually place there.

Still, if the POM is well-defined (again, a big "if"), I see no reason
why the project you mentioned shouldn't get resolved and installed
correctly by an ibiblio resolver.  I should just point out that you
probably only want one of those jar/source pairs depending on what JDK
you are using (1.3 versus 1.5).

> 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
> applied:
> public: bad revision found in
> expected='4.7 found='4.7.0'

That error is not about Ivy being unable to support 3-part revision
numbers.  It happens because the revision number it was given does not
agree with what was found in the POM.  From my experience this is
almost always because of incorrect rules.

> 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" />
> Before
>                <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.

This again has to do with inconsistent Maven POM data.  Ivy
namespaces/rules are a convenient way to deal with these
inconsistencies, but they are definitely hard to get right.

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

That's the exact behavior I have seen (first applicable matching rule
is the only one used without chainrules="true").  Perhaps there is
something else going on with your settings?  Maybe you should paste
them somewhere.

> 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. <snip>

That's again an unfortunate consequence of bad Maven metadata being
adapted into Ivy.  You can always argue the ibiblio resolver should
handle cases like this more elegantly, but at the end of the day it's
trying to get one system working with another's metadata.  There are
going to be such issues.

> 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.

I agree with the crux of what you're saying.  The Ivy website provides
nice tutorials on building a custom repository, including setting up
some ibiblio resolvers and a starting point for the rules, etc.  But
it doesn't go in to much depth about dealing with those "real world"
issues one encounters when taking such an approach, like the ones
you've run into (bad POMs, inconsistent or too-specific revision
numbers in POMs, dealing with the whole Maven vs Maven2 naming thing,
figuring out the set of rules required to get things working, etc.).
It would be fantastic if someone would provide such a tutorial and
kept it up-to-date for different scenarios.

Even better would be if there was a pure-Ivy way of starting out, that
didn't rely on going to public Maven repositories, then adopting POMs
into Ivy files, to get a custom repository with locally-fetched
artifacts and generated Ivy files started.  This would take care of a
lot of the problems you are running into (and I have been as well).
It would be nice if there was a public Ivy repository that contained
everything (artifacts too, not just Ivy files).  My guess is this
doesn't exist due to a lack of interest/time/resources/ownership,
which is certainly understandable.

View raw message