On our way to Gradle 1.0

Status of the 1.0 release

We are working intensely towards the 1.0 release. The remaining work is focused on the new dependency cache, the daemon and performance tuning. We will also continue to fix bugs in various other areas.

The new dependency cache

We are very excited about our new dependency cache. It solves many fundamental issues that current repository based builds have, whether their build system is Ant + Ivy, Gradle, SBT, Buildr, Leiningen or Maven. To learn more about it, see: http://t.co/R4Vt9SSu

We considered it crucial to have these improvements in 1.0. The road to the new cache has been a little bit more bumpy than we expected . Some bugs in the new dependency cache caused severe regressions in our now-rescinded 1.0-M4 release.

Once the major issues with the new cache are fixed, we will release gradle 1.0-m5.

The daemon

The daemon is crucial to make Gradle a highly responsive build system. The startup and initialization time of any of the new major JVM languages is significant. As Gradle is based on Groovy, it is also suffering those delays. The solution to this is the Gradle daemon which provides a long running pre-initialized JVM to avoid the startup time. Having a long running Gradle agent will give us a tool to do many more optimizations in the future (e.g. pre-fetching snapshot dependencies). For now, we need to make it production ready. You can already opt-in to have the daemon enabledvia the –daemon flag at the CLI or in the GRADLE_OPTS environment variable. Several Gradleware team members and I have worked with this option enabled for the last 6 months. But you might run sometimes into issues such as with file-locks under Windows. Then you have to manually kill the daemon process.

Once the remaining daemon issues are fixed we will release gradle 1.0-beta-1

Performance

We are tackling performance issues continuously and there will be still performance optimizations we want to do after 1.0-beta-1 is released. Therefore although 1.0-beta-1 will be feature complete, we don’t want to call it a release candidate as we still have plans to modify code for performance optimizations. Performance is very important to the Gradle team. Gradle has excellent performance in many areas. But there are some areas where we still have a lot of potential for improvement.

Once we are done with the performance improvements, we will release gradle 1.0-rc-1.

nice roadmap!

This type of communication is perfect and a great way to focus people on the forum as well.

Agreed @Ken. It’s always nice to read a clear roadmap for the software we use.

BTW @Hans, is the roadmap for the standard plugins part of the overall gradle roadmap or is is published separately?

Thanks for this informative roadmap. The JIRA issue GRADLE-1768 becomes critical when you work offline regularly: http://issues.gradle.org/browse/GRADLE-1768

Since this isue is also about caching, maybe there is room to resolve the “caching of 'apply from: URL scripts” before 1.0 is out…

While comparing 1.0-milestone-3 with the latest 1.0-milestone-5 nightly, dependency resolution is significantly slower (adds multiple minutes) in our build because we have several different repositories and now we’re downloading lots more .pom files and duplicate JARs.

Is it possible to tie a dependency to a given repository?

I have written up a bunch of details for Tim Berglund and hope that we can come up with some way to keep those build times down while incorporating these new changes

@Etienne, I agree. If we are serious about working offline, we need to cache the scripts. Whether or not this makes it into Gradle 1.0 depends on how far we get with refactoring the wharf cache from an ivy-specific cache into a general purpose artifact cache.

in some situations you don’t want to spawn a deamon for example in gradle IDE support plugins or CI servers. It would be great if gradle would still support embedded scenarios in future by making the background deamon optinal.

I agree in general. There should be always be way to use Gradle fully embedded.

I’m not sure about the IDE scenario though. We can do a lot of optimizations within the daemon that might be very appealing to an IDE. We can also take care about doing health checks if the builds are leaky, etc … Therefore the Gradle plugin for Eclipse and Idea both uses the daemon.

I agree that having a single Gradle VM instance on a node that is running multiple build is definitely advantageous, but don’t feel that it has to be a separate OS process. We could very well design the BuildMaster/Daemon sot that systems like IDEs could instantiate it once and then delegate all builds to it.

That said, I am yet to dive into the gradle source as much as I’d like to and don’t know the way the daemon integrates into the build system.

@mbien: the daemon will only be used where it makes sense. It turns out that long term, IDE integration is one of the areas that will benefit the most but it is early days for this stuff.

@alkemist, agreed!