ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thorburn <nzi...@gmail.com>
Subject Re: ivy:install task - Comments/Criticisms/Bugs
Date Wed, 21 Apr 2010 02:08:06 GMT
Ok, I've created issues 1182 - 1187, for issues that haven't been
reported yet and that could be reasonably solved by Ivy.

- Andrew

On Wed, Apr 21, 2010 at 9:37 AM, Maarten Coene <maarten_coene@yahoo.com> wrote:
> Wow, thanks for this detailed feedback.
>
> I think the best thing you can do is to create individual JIRA issues for the points
you think that could get addressed by Ivy.
> https://issues.apache.org/jira/browse/IVY
>
> Maarten
>
>
>
> ----- Original Message ----
> From: Andrew Thorburn <nzipsi@gmail.com>
> To: ivy-user@ant.apache.org
> Sent: Thu, April 8, 2010 11:46:29 AM
> Subject: ivy:install task - Comments/Criticisms/Bugs
>
> 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
> applied:
>
> public: bad revision found in
> http://repo1.maven.org/maven2/junit/junit/4.7/junit-4.7.pom:
> expected='4.7 found='4.7.0'
>
>            <rule>
>                <fromsystem>
>                    <src org="org.junit" module="junit" rev="4.7.0" />
>                    <dest org="$m0" module="$m0" rev="4.7" />
>                </fromsystem>
>                <tosystem>
>                    <src org="junit" module="junit" rev="4.7" />
>                    <dest org="org.$o0" module="$m0" rev="4.7.0" />
>                </tosystem>
>            </rule>
>
>
> 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="org.apache.ws" module="xmlrpc"
> revision="3.0"  from="installerChain" to="local" transitive="true"
> overwrite="true" />
>
> Before
>
>        <ivy:install organisation="org.apache.ws" 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 org.apache.ws. 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:
>
>            <rule>
>                <fromsystem>
>                    <src org="org.apache.commons" module="commons-.+" />
>                    <dest org="$m0" module="$m0" />
>                </fromsystem>
>                <tosystem>
>                    <src org="commons-.+" module="commons-.+" />
>                    <dest org="org.apache.commons" module="$m0" />
>                </tosystem>
>            </rule>
>
> 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:
>
>            <rule>
>                <fromsystem>
>                    <src org="org.apache.commons" module="commons-parent"
/>
>                    <dest org="$o0" module="$m0" />
>                </fromsystem>
>                <tosystem>
>                    <src org="org.apache.commons" module="commons-parent"
/>
>                    <dest org="$o0" module="$m0" />
>                </tosystem>
>            </rule>
>
> 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
> this:
>
>            <rule>
>                <fromsystem>
>                    <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" />
>                </fromsystem>
>                <tosystem>
>                    <src org="commons-.+" module="commons-.+" />
>                    <dest org="org.apache.commons" module="$m0" />
>                </tosystem>
>            </rule>
>
> 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:
>
>            <rule>
>                <fromsystem>
>                    <src org="org.apache.xml" module="xml-apis"/>
>                    <dest org="$m0" />
>                </fromsystem>
>                <tosystem>
>                    <src org="xml-apis" module="xml-apis" rev="2.0.2" />
>                    <dest org="org.apache.xml" module="$m0" rev="1.0.b2"
/>
>                </tosystem>
>            </rule>
>
> 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.
>
> Thanks,
>
> - Andrew Thorburn
>
>
>
>
>

Mime
View raw message