[GRADLE-197] Allow the usage of ivy.xml and ivysettings.xml with Gradle Created: 29/Aug/08 Updated: 10/Feb/17 Resolved: 10/Feb/17
|import-ivy.gradle ivy.xml ivysettings.xml
It should be rather easy to make this possible. We should also offer to merge declaration from ivy files with dependency declarations in the gradle build file.
|Comment by Helmut Denk [ 29/Aug/08 ]
implementation if 'config by ivysettings.xml' should have priority IMO.
|Comment by Willem Verstraeten [ 02/Jul/09 ]
Is there a target version for this ? Being able to have Ivy files would allow me to reuse the Ivy dependency information in the build process as well as in the IDE's of our developers, which is quite an important requirement for us.
|Comment by Willem Verstraeten [ 02/Jul/09 ]
Alternatively having gradle support in our IDE's (in the sense that the IDE's can get their module configurations from the gradle build scripts) would also be acceptable, but then IntelliJ as well as Eclipse should be supported. I think it's easier if you can parse the ivy.xml files in gradle and let the existing IDE-Ivy plugins (ie. IvyIDEA and IvyDE) handle the IDE configuration.
|Comment by Hans Dockter [ 02/Jul/09 ]
We might do it step-by-step. What would be very easy to implement is an Ivy-plugin that allows you to generate an ivy.xml and ivysetting.xml file from the Gradle dependency information. Gradle does this anyhow internally. The other way round is more difficult but has also a pretty high priority to use. I hope we can ship a first version of the Ivy plugin in 0.8.
|Comment by Uldis Karlovs-Karlovskis [ 23/Oct/09 ]
For me highest priority is to have ivy.xml per module of multi-project build.
|Comment by Barry MacMahon [ 05/Nov/09 ]
This feature would speed up or enable the adoption of gradle by companies who have an ivy based build in and also by allowing integration with IDEs via ivy plugins as mentioned above.
|Comment by Richard Vowles [ 17/Aug/10 ]
What else is critical is to have the option to override the dependencies that are in the Gradle build file from the ivy.xml settings (and hopefully ivysettings.xml as well). This is important for a reproduceability of build reason - you need to know exactly what versions of what artifacts were resolved when the module was built and tagged and released. If you cannot rebuild the exact same release with the exact same versions of your dependencies, you don't have the same build.
I say the ivysettings.xml as well, as some of us have different version range resolvers for compile scope vs run scope. That said, the resolvers themselves won't change in the Gradle build file, so it is less important.
|Comment by Carl Quinn [ 17/Nov/10 ]
For me and my company, I don't think we can adopt Gradle until it can read ivy.xml files for module dependencies, for two reasons:
The ivysettings.xml is less of an issue for us as that is a single file that can be manually maintained in parallel with a Gradle file.
|Comment by Qamar mahmood [ 17/Nov/10 ]
This feature would aid adoption of gradle.
|Comment by Hans Dockter [ 18/Nov/10 ]
@Carl I absolutely see your point. But usually there are reasonable, pretty easy, work arounds. This issue here is for a generic import of ivy.xml's including the corner cases. We plan to solve this as part of a 1.0 milestone when we add further functionality to our dependency DSL. But for most enterprise use cases, where the structure of the ivy.xml is not using every degree of freedom Ivy allows, it is easy to write your own adapter which imports the ivy.xml into Gradle at runtime. We did this for a number of builds and it worked fine. We are talking about something like 30 lines of code. We did this for example as a POC for the Ant build of the spring core framework.
BTW: I'm confident that IntelliJ and Eclipse will soon be able to understand build.gradle files. With the adapter approach, you then have the choice. Another thing we should and will provide is a script that coverts ivy.xml into build.gradle files.
|Comment by Qamar mahmood [ 18/Nov/10 ]
|Comment by Martin Kacer [ 03/Jan/11 ]
I absolutely agree with Carl. We would like to adopt Gradle but need to solve this issue for the same two reasons that Carl described.
Hans, would it be possible to see some example of those "30 lines of code"?
|Comment by Davide Cavestro [ 19/Apr/11 ]
At my company we would migrate our old ant style build scripts (with no deps management) to gradle, but we need real IDE support to reflect dynamically resolved dependencies.
PS: Please beware that the old copy of this issue has more votes than this one. I think it is due to the fact that people can still vote there and don't know about the new issue tracker (or at least I didn't know till some minutes ago and started voting there).
|Comment by Hans Dockter [ 01/May/11 ]
Finally I have attached an import snippet which I used as a proof of concept for the spring-core build.
|Comment by Davide Cavestro [ 02/May/11 ]
Thanks a lot to Hans.
UPDATE 20110519: I noticed that directly calling
looses the changing attribute value, thus missing to get new version for snapshot deps marked as changing=true into ivy.xml, so it should be converted to
|Comment by Martin Kacer [ 10/May/11 ]
|Comment by Hans Dockter [ 10/May/11 ]
@Martin So you did not get any update emails for this issue from issues.gradle.org? Haven you been watching this issue on codehaus? Or just voted?
|Comment by Leonard Brünings [ 19/May/11 ]
@Davide how would you get it to work with the default configuration?
|Comment by Davide Cavestro [ 19/May/11 ]
@Leonard I'm not sure I understand your question: what do you mean with default configuration?
But maybe you would mean something else...
|Comment by Leonard Brünings [ 20/May/11 ]
@Davide Yes I mean something else. In ivy you don't have to define a configuration like 'compile' or 'runtime' and if you don't the dependencies will get added to the 'default' configuration. My question is how can you adapt this script to work with the 'default' configuration.
And could you please post the minimal ivy.xml and ivysettings.xml to get it to work with this script. I keep getting the error
|Comment by Davide Cavestro [ 20/May/11 ]
I've never used ivy default configuration directly from gradle, but I'd try adding to the compiler classpath that configuration as any other of interest with code similar to
PS: You'll notice some variables into xml files: I put them there when I had to duplicate deps between ivy descriptors (for IDE support) and the gradle script (the matter this issue solved). Now I could directly write most of them directly into ivy descriptors instead of reading them from gradle.properties.
|Comment by Carl Quinn [ 15/Jun/11 ]
Just starting to try this out now using snippets from Hans and Davide (thanks guys). I think this is going to force me to learn the inner workings of Gradle on Ivy
First thing I hit is that my resolvers are all instances of: org.apache.ivy.plugins.resolver.URLResolver, ChainResolver, and FileSystemResolver, and after they are added to the resolvers collection, their cache property is null. I think Ivy would then just use the default cache, but Gradle is having trouble with this:
Cause: Unexpected cache manager default-cache for repository nfrepo-everything (nfrepo-everything)
If anyone has some hints that would be great. I'm thinking that I'll need to pass more settings down from the local ivySettings to Gradle.
|Comment by Carl Quinn [ 15/Jun/11 ]
So then the next big question is: how can I configure Gradle's underlying Ivy settings to be exactly like my Ant's Ivy settings?
I don't mind writing DSL or Groovy to mimic what I do in ivysettings.xml, but I am having a hard time finding how to get at the general bits other than the resolvers. And even those seem to be specialized in Gradle and may not match what I have in my Ivy.
|Comment by Szczepan Faber [ 21/Jun/11 ]
>Cause: Unexpected cache manager default-cache for repository nfrepo-everything (nfrepo-everything)
For consistency reasons, gradle requires all remote resolvers to share the same instance of the repository cache manager. Hence this exception. My understanding is that you're initiating resolvers from the ivy xml files? I'd suggest that your script should make sure that the for each remote resolver the repository cache manager is null (that means it will use the 'global' default repository cache manager.
>So then the next big question is: how can I configure Gradle's underlying Ivy settings to be exactly like my Ant's Ivy settings?
It may depend on the complexity of your ivy configuration. At this moment I can think of 2 ivy features not supported by gradle: remote resolvers with separate repository cache managers (see above) and this
Let me know how we can help more!
|Comment by Carl Quinn [ 06/Jul/11 ]
I have gotten past my resolver issues, and mostly using GradleIBiblioResolver. I am not sure what I had wrong before, but creating various resolvers from scratch and then adding them to the repositories containers works fine for me now.
The next question is regarding some of the other settings that are generally used in ivysettings.xml:
|Comment by Leonard Brünings [ 08/Jul/11 ]
I extended the snippet to include transitive, artifacts, and exclude settings.
|Comment by Rodion Moiseev [ 17/Aug/11 ]
Could anyone please describe the exact steps needed to integrate the above script into a simple project (with a single build.gradle, for instance). Preferably for the 1.0-milestone-3 or above.
I have tried using apply from: 'import-ivy.gradle' and copying the contents to ../build.gradle but neither approach works. Well, it half-works: I get appropriate output from dependencies task, but running compileJava or eclipse seems to behave as if no dependencies were resolved (e.g. I get an empty .classpath file).
Is there a certain order in which this script, 'java' plugin and 'eclipse' plugin have to be evaluated?
I have experimented and found the following:
1. Doing project.configurations.myConf.addDependency(new DefaultExternalModuleDependency(...)) does not work
I am guessing DefaultExternalModuleDependency is not being initialised correctly, but not sure what exactly is the problem.
No one else having issues with this??
|Comment by Blaine Simpson [ 18/Nov/11 ]
I just published Ivyxml Plugin, that loads Ivy dependency files. The code snippets here got me started, but it's been much broadened and hardened since.
It does not load ivysettings files, only ivy.xml files.
|Comment by Szczepan Faber [ 20/Nov/11 ]
@Blaine, thanks for the plugin and the reference!
|Comment by Chad Walz [ 08/Dec/11 ]
Thanks for addressing this and placing a plugin out there. After going through the readme here: https://github.com/unsaved/gradle-ivyxml-plugin/blob/master/README.txt, I'm failing to see what a proper ['confName'] will be, so my result is a BUILD FAILED "Cause: Configuration with name 'confName' not found."
|Comment by Blaine Simpson [ 08/Dec/11 ]
Chad: If you have any other issue with the plugin, please register an... Issue for it.
You can use any Gradle Configuration name there, but it would demonstrate something useful regarding Ivy configuration if you entered an Ivy conf name (which will automatically mirror a Gradle Configuration name).
|Comment by Blaine Simpson [ 19/Oct/14 ]
I updated my Ivyxml plugin to support Gradle 2.x and have registered it on the Plugin Portal
|Comment by Benjamin Muschko [ 15/Nov/16 ]
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.