Actually I gave it another try (let it sit there while doing something else) and it did finally finish building the model. So it wasn't really hung, just looked like it. So maybe this issue isn't critical.

Would still be good to get more progress reporting and/or figure out why it takes so long for building the model for this project, given that it should already have its dependencies on disk, I'd not expect it to take more than 10 minutes.

The reason the model generation is slow lies in the dynamic versions (e.g. 1.3.+) used by the spring-data-mapping project. What happens is there're extra remote calls each time the dependencies are resolved (regardless if you have them in cache or not). The dependencies are resolved when you build full model, when you run 'gradle eclipse' or when you compile, etc. so the impact is fairly big.

Ivy allows setting a TTL for dynamic revisions. However this setting is not yet provided by Gradle DSL. See conversation: http://gradle.1045684.n5.nabble.com/long-pause-related-to-Ivy-td3352381.html

At the moment, to reduce the prolonged checks on version ranges you can tweak the ivy cache manager via the system property: -Divy.cache.ttl.default=eternal

More about ivy ttl: http://ant.apache.org/ivy/history/latest-milestone/settings/caches/ttl.html

Related tickets: GRADLE-320, GRADLE-1333

I've implemented something to cache the classpath container contents in STS:
https://issuetracker.springsource.com/browse/STS-1757

At least that way we don't have to pay the price everytime you start the IDE. Waiting for 10+ minutes for the IDE to become responsive after startup is not acceptable.

This will take the sting out of the +10 minutes wait a little. But unfortunately we will still be freezing up the IDEs build/task queue for +10 minutes the first time we build the model... or any time the user asks to refresh the dependencies.

Ok, I see. The dsl for managing the dynamic versions ttl in gradle script should also help a lot. I'll talk with Adam on prioritizing it.

This may help... but it means that users will be responsible to use those ttl declarations.

I don't like that.

It doesn't seem good to me that IDE functionality becomes unusable unless the user writes their script in a certain way.

In practice, those dependencies resolved with "+" would probably not change that often. Could we not find some way to exploit that? (And I mean in a way that doesn't put the onus on the user to write their build script in a certain way).

Maybe there need to be two kinds of "refresh" where the "normal" refresh uses the "infinite" limit but there's some way to ensure the very expensive remote refresh is done in a way that is totally non-invasive to the rest of the process. (I.e. bringing the cache up to date is something that could be done in background... while the rest of it, which is called upon directly from the IDE or the user, just used the best available data from that cache even if isn't necessarily the most-up-to-date.

And for the rare circumstances where you know that an external dependency really needs to be refreshed right now, we might provide some special functionality (e.g. like a "clear/refresh cache" button)... or allowing user to explicitly refresh a specific dependency.

BTW, this may also help adressing the "offline usage" that people where asking for in that other issue.

I realize there will always be situations where there's no avoiding the wait (if the cache is totally empty for example). But trying to minimize those cases is important.

Just to clarify. I'm not saying that its a bad idea to support ttl declarations. I'm only saying I don't think it is a good idea to depend on user's writing them to avoid making the IDE unusable.

Even if they chose not to write them, they should still be able to use the IDE comfortably.

Thanks Kris, this is very good feedback.

I agree the setting should not decide whether ide support is responsive or not

@kris, I agree with your comments.

What I'd like to do is change the default behaviour for dynamic revisions (and snapshots) in ivy and maven, so that the cache is used more aggressively for those repositories where a lookup is potentially slow. This way, the user does not have to do anything special in their script in order to get reasonable performance from both the command-line and the IDE.

The downside is that we lose the liveness of the dynamic revisions. There are a few things we can do to address this:

• Allow the user to opt-in to more frequent checking. Ideally with something more useful than a 'time-to-live' parameter. And perhaps give the IDE a way to override this through the tooling API.
• Use the daemon to periodically check for and download new revisions in the background, so that next time the model is built or a build executed, the cache is up-to-date.
• Building on the above, add change notifications to the tooling API, so that the daemon can initially return whatever is in the cache, and then notify Eclipse later once it has done the actual remote check.
• Introduce push notifications for certain types of repositories, so that the daemon can subscribe to changes.

As far as caching the model goes, this is something we want to add behind the tooling API, as we will use this for other tools (eg command-line completion). What would happen is something like this: the tooling API would return the cached model, if present, immediately. Then, it would build the actual model, and notify Eclipse when the real model is available (given that it has changed).

I agree with @kris. I ran into this today working completely by chance on the same example with spring- gemfire hellow-world example. Not knowing to wait 10 minutes I've "force quit" my STS 3x. I'm waiting for the magic 10 minutes now hoping it will get off the 1% progress report. It happened to be the first time I've used gradle from STS so wasn't impressed. The problem is that when you first hit this you can't use the workaround (https://issuetracker.springsource.com/browse/STS-1757) until it completes (and I'm still waiting).

@Kris, is this still a problem? From m5 onwards, we've added a lot more caching that should make this a lot faster once everything is downloaded.

It's ok to close this. Things are much better. There are still some lengthy operations on first model builds from a 'clean' cache but...
We should probably just raise new issues when experiencing these with more recent versions of Gradle.