Status of the 1.0 release

Old Forum Archive
1

A month ago we have posted: On our way to Gradle 1.0. We would like to provide an update on that.

We are very happy that we have finally release milestone 5. Believe us, in the foreseeable future will never be release that will take that long. We are switching to a time-boxed release modell from now on. Our plan is to have bi-weekly milestone releases before our beta is released. As said in our previous posting regarding the 1.0 roadmap, the beta is to be considered a feature complete release where we will only do bug-fixes and performance improvements. After that there will be a RC-1 release and then finally the GA release.

The Daemon

We made some good progress to make the daemon more stable. We are at a point where we don’t consider it an experimental feature any more. So in the next release we will remove the warnings for when it is switched on. We will make it also very easy to switch it on permanently via a gradle command line option. We want to gather more feedback before we switch it on by default.

Dependency Management

We are very happy with our new dependency management cache. We added recently some nice features. You can now:

  • In case of a version conflict you can now decide whether the build should fail or the newest version should be used. * You can now specify either a commong timeout policy for all cached dynamic versions or you can hook up your custom dynamic version policy.

The main reason why milestone-5 took so long to be released is that we found out that a lot of stuff we have been using Ivy for needed to be fully rewritten to give it the capabilities we want. This was a huge investment and we were basically paying back a huge technical debt. We paid back most of it. This will also enable us to provide many innovations in the area of dependency management in the future. Here are the things we will improve before we will release 1.0:

  • Our new treatment of dynamic versions described above doesn’t work yet for non-unique Maven snapshots. That leads for example to constant lookups for new Maven snapshots if you use multiple repositories. (to be fixed in a milestone release) * Introduce the concept of dynamic modules. Dynamic modules are modules that don’t change their version numbers and yet they have a limited time to life. Non-unique Maven snapshots are an example for those. Another use case of our users are jars with certificates where the latter becomes invalid and get’s a new one without updating the version number. (to be fixed in a milestone release) * Provide an offline-switch. (to be fixed in a milestone release) * Ivy does a look of network lookups when retrieving a non-cached artifact from a Maven repository or when checking whether a snapshot has changed. We will be able to reduce the lookups by a factor of 10 by rewriting this code. This will make dependency resolution much faster. (to be fixed in a milestone release or beta)

You can expect Gradle dependency resolution to be soon dramatically faster than it has ever been. In particular the IDE tasks will benefit from that.

Miscellaneous

We will also add some bug fixes and new features in other areas to the upcoming releases. But the bulk of the work is happening in the above areas. You might want to watch our commit activity.

2

This is great to hear - thank you for continuing to keep everyone in the know on the roadmap and updated release plan!

3

I mentioned this in another thread, but I hope another focus for dependency management is more efficient memory usage. heap requirements for a deeply nested dependency structure went way up in M5.

4

what does this mean? “You can now specify either a common timeout policy for all cached dynamic versions or you can hook up your custom dynamic version policy.” Is there more information somewhere?

5

Yes. The next nightly build will add a section: 36.3.9. Fine-tuned control over dependency caching

Just realized that we removed the custom policy interface from the public API which is described by the class ResolutionStrategy. The underlying implementation DefaultResolutionStrategy still provides this possibility. I guess we did that because the API of this is not considered stable yet.

6

Thanks for pointing this out. We will definitely have a look at that.

7

Is gradle using aether to deal with maven repos?

8

Will the dependency rework you’ve done be fed back into a future version of Ivy? I’m still fond of the thought of Ivy as the uber dependency management tool that can be used by itself or in other tools.

9

We currently use Ivy’s IbiblioResolver to resolve dependencies, and Maven’s Ant tasks to publish artifacts. The longer term plan is to use aether to both resolve and publish.

10

Probably not. However, the dependency cache implementation is currently available as a standalone project, called wharf, which you can use as a plugin to Ivy, independent of Gradle.

At some point, we’d like to split out the Gradle dependency management implementation as a stand alone library that you can embed in an application.