CODEWITHSUNDEEP
gradleivy
user967710
user967710

Reputation: 2007

migration from ivy to gradle issues

I am moving from Ivy to grade.

In ivy I was able to have a property file that contained all my dependencies' versions.

Also when publishing I updated this file.

This is sort of central control of versions. Very comfortable. For example:

Versions.properties:

  log4j.ver=1.14
  commons-lang.ver=1.1

And ivy.xml:

  <dependencies>
    <dependency org="log4j" module="log4j" ver="log4j.ver"/>
  </dependencies>

I can to the same in gradle but properties are said to be deprecated soon. Any equivalent concept in gradle?

Another issue is the ability to resolve dependencies in workspace. I know that there is the 

  dependencies{
   compile project(':shared')
  }

Syntax, but I want the dependency to be flexible. If the project is in the workspace, resolve it. Otherwise, download it from archives.

How to achieve this behavior?

Thanks

Upvotes: 0

Views: 138

Answers (1)

Peter Niederwieser
Peter Niederwieser

Reputation: 123910

This should have been two separate questions. Anyway:

ad 1) All that was deprecated is dynamic properties, i.e. introducing new properties with foo = "bar". Instead, it's now def foo = "bar", or, if the property needs to be accessible from other build scripts, ext.foo = "bar". (This change will allow Gradle 2.x to fail if a property is misspelled; Gradle 1.x will at least give a deprecation warning.)

Note that nothing changes on the consumer side, i.e. the property can still be accessed via its simple name (e.g. println foo). Note that it should not be accessed via ext.foo, even though this will work in some cases.

ad 2) This isn't currently a first-class feature, but can be achieved with some effort. (See https://github.com/pniederw/elastic-deps for a proof-of-concept, and https://github.com/prezi/pride for an early version of a more serious implementation). I expect this to become a first-class feature in the 2.x timeframe.

Upvotes: 1

Related Questions