On 18 Jan 2014, at 2:03 pm, Xavier Ducrohet <x...@google.com> wrote:
> > On Fri, Jan 17, 2014 at 4:15 PM, Adam Murdoch <adam.murd...@gradleware.com> > wrote: > > On 17 Jan 2014, at 2:40 pm, Xavier Ducrohet <x...@google.com> wrote: > >> Hello, >> >> It seems that subsequent builds done with the daemon are using brand new >> instances of custom classes instead of reusing the ones loaded on the first >> build? Is that correct? > > It’s unspecified at the moment. Right now it happens to recreate the > ClassLoaders on each build, but we do plan to change this soon, as having the > plugin and build script classes warmed gives a nice improvement to build > execution time and allows plugins to do things like in-memory caching. It > also slows down permgen leaks too. > > > What happens if I do 2 builds at the same time that use the daemon. Would > both build share the same classloaders? This means static class fields would > be shared between the 2 builds? You get a new daemon. Each daemon runs a single build at a time and if there are no idle daemons available the client starts a new one. > >> >> I'm trying to dynamically load a jar file only once during the build so that >> it's reused by all the tasks for all the modules, and it seems that repeat >> build will trigger a new load. > > Why do you need to do this? Are you loading stuff out of the SDK that the > task implementations use? > > > Yes, we have a Java based tool that's used during the build, sometimes many > time during the same project builds. I'd like to load it instead of calling > it through the shell script which would spawn a new VM for it. The question > is when do I unload it. Though I guess it'll get unloaded when the rest of > the custom plugin classes gets unloaded, so it's not too much of a problem. > I'm not planning to keep too many things around anyway. It’s a pretty common problem for plugin authors where you have some Java tool that needs to be visible to (usually) the task classes but which needs some plugin-specific configuration (say, checkstyle version or sdk install directory or whatever) to be done before exactly what to make visible is known. At some point I’d like to add a general purpose solution to this that plugins authors can use. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
