Hi Carl, I cannot say I have much experience migrating Ivy to Gradle, but while I have some understaning of Ivy, I have found a couple of issues during my work with Gradle:
- Gradle does not support resolving multiple configurations of an external module at once - in Ivy one can just pass the list of configurations to resolve, while in Gradle you can resolve a single configuration at a time. Workaround for this is to decide what configurations you would need to resolve and configure such 'grouping' configuration of the target module, so that you can reference it. But that works only if the module build is under your control. Other option is to define the module dependency multiple times, but then if the module having a 'changing' revision, some cache issues arise (described in one of my previous posts). - Gradle does not expose management (reading/writing) of extra module/artifact attributes (See GRADLE-940<http://issues.gradle.org/browse/GRADLE-940> ) - Gradle does not support configuring conflict resolution strategy, always using 'newest' (See GRADLE-646 <http://issues.gradle.org/browse/GRADLE-646>, GRADLE-1193 <http://issues.gradle.org/browse/GRADLE-1193>, GRADLE-1303<http://issues.gradle.org/browse/GRADLE-1303> ) Regarding the 'provided' configuration - this seems to be required when building some kind of a distribution of a product - to decide what to include in the final archive. Such an example is the 'war' archive - currently Gradle's war plugin <http://www.gradle.org/war_plugin.html>defines 'providedCompile'and 'providedRuntime' configurations so that one can, for example, specify what not to include in war's lib folder. Other examples are OSGi bundles, Eclipse features, etc. I will be very interested what other challenges you would have while migrating to Gradle. While working on creating a build system based on Gradle in my company, we have decided to extend the base plugins provided by Gradle, thus creating our own analogs. This way we can somehow fill the missing bits and build our own conventions. I'm pretty sure that at some point you will have to move to working directly with Gradle's API and do this from within a custom plugin, not the configuration scripts. I think that there are many users who go in that direction and I hope Gradle would provide some 'hooks' in its API to allow custom configuration of some aspects that are currently hardcoded. Kind Regards, Detelin On Sat, Jul 2, 2011 at 11:10 AM, cquinn <[email protected]> wrote: > I am porting a large Ivy-based build system to Gradle and I am trying to > figure out what to do about configurations. I had pretty much stuck with > the > Ivy defaults for our hundreds of projects and now tens of thousands of > published modules. And now looking at Gradle, and especially the Java > plugin, I see that these are different and I'm not sure whether I should > migrate to Gradle's or extend/modify Gradle to work with mine. > > Here are the ones I question: > > Ivy's 'master' seems to match Gradles 'archives'. Master seems more > general, > but this is a simple one-one name change mapping I guess, so maybe I could > live with it. > > Gradle is missing Ivy's 'provided'. This wouldn't be possible to do > without. > Are there any plans to add this to the standard set for the Java plugin? > How > much trouble will I get myself into if I start poking this in all over. > > Ivy's 'test' has been split up into 'testCompile' and 'testRuntime' in > Gradle. I think this makes more sense, so I'll migrate. I guess anything > that was using test would just map to testCompile and get inherited by > testRuntime? > > Any other Ivy to Gradle migrators? What have you done in this area? > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Ivy-vs-Gradle-configurations-tp4544242p4544242.html > Sent from the gradle-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
