Daemon and updating project upon file change

bjhargrave · August 26, 2015, 3:05pm

The bnd gradle plugin configures the gradle project via information in the bnd.bnd file. This includes things like javac target, compile dependencies, etc. Normally the daemon will see if build.gradle has change to re-configure the project, but in the bnd gradle plugin case, build.gradle has not changed while bnd.bnd has. So the daemon continues to use now out-of-date configuration requiring the user to stop the daemon so that the next gradle invocation will properly configure the project.

How can I configure the project so that he daemon will re-configure the project if a file other than build.gradle has changed? I looked through the API but did not see anything obvious.

sterling · August 27, 2015, 4:58pm

When do the tasks get modified? If the plugin is programmatically modifying the build configuration based on whatever is in the bnd.bnd file, the configuration shouldn’t be out of date since the daemon re-executes the build each time. It doesn’t matter if the build.gradle file isn’t modified.

Are you using -t or --continuous build?

bjhargrave · August 27, 2015, 5:15pm

When the bnd gradle plugin is applied to the project, the bnd gradle plugin will read the bnd.bnd file (via the bnd API used by the bnd gradle plugin) and use the information to configure the gradle project.

While the daemon may reexecute the project each time, it does not seem to reconfigure the projects each time. After the bnd.bnd file is modified, for example, to change the compilation dependencies to fix a compilation problem, running gradle from command line gets the same compilation problem again because the daemon did end up applying the bnd gradle plugin again to reconfigure the project with the updated compilation dependencies.

No -t or --continuous. Just the basic gradle daemon.

sterling · August 27, 2015, 5:37pm

Ah, I think it’s due to some static state from Workspace:

github.com

bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/build/Workspace.java#L48


import java.util.jar.JarEntry;
import java.util.jar.JarInputStream;
import java.util.jar.Manifest;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Stream;


import javax.naming.TimeLimitExceededException;


import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


import aQute.bnd.annotation.plugin.BndPlugin;
import aQute.bnd.connection.settings.ConnectionSettings;
import aQute.bnd.exporter.subsystem.SubsystemExporter;
import aQute.bnd.header.Attrs;
import aQute.bnd.header.OSGiHeader;
import aQute.bnd.header.Parameters;
import aQute.bnd.http.HttpClient;
import aQute.bnd.maven.support.Maven;
import aQute.bnd.osgi.About;

I don’t know the code well enough, but it looks like the bnd.bnd file may be parsed only once and then cached. Since Gradle re-uses classloaders across builds, static state remains. Try clearing this at the end of the build (e.g., buildFinished { Workspace.cache.clear() } as a hack) and see if things work as expected.

bjhargrave · August 27, 2015, 7:12pm

Caching in bndlib was the problem. Thanks for digging in and figuring it out!