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 <[email protected]> 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 <[email protected]> > To: [email protected] > 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 > > > > >
