Hi,
I've started to implement a feature a number of people have been requesting - individual module (contribution) reloading.
Currently, F3 supports the ability to edit webapp assets such as HTML and Javascript in an IDE and have them appear in the browser without having to do anything other than refresh the browser (e.g. no need to build). A big missing feature has been the ability to edit Java class files and other metadata such as service wiring, bindings, etc. in a similar fashion. For example, many people have said it would be useful if you could edit a Java class, add bindings, re-wire services, etc. in-place in an IDE without having to restart the server, run a build, or update parts of an application that are not affected.
There are some nice commercial products like JRebel that perform class reloading. However, these only handle changes to Java classes and don't help much with things such as re-wiring services or other "higher-level" application configuration changes. I've also looked at Play! and it has the nice ability to reload applications including this higher-level configuration data. I thought having a similar feature for F3 would significantly improve the developer experience by eliminating the wait time between builds. The one thing I didn't like about Play!'s reloading feature was that it ties you to sbt as a build tool (at least that is my understanding). For F3, it is important not to force developers to use a particular build tool.
So, I've just checked in support for incremental reloading into trunk that meets these requirements. I'd appreciate if people could test and provide feedback and ideas for improving it. Here's how it works:
1. Create a Fabric3 runtime image using the Maven/Gradle plugin or download it manually.
2. Instead of deploying contribution archives to the image, deploy a "symbolic link" *.contribution file. This is a text file of the form [contribution name].contribution and contains a list of directories that point back to source and resource directories for the contribution. Here's an example:
${my_project_dir}/services-core/build/classes/main
${my_project_dir}/services-core/src/main/resources
The above contribution file has two directories that point to a local Gradle project layout (this can be modified to work for any layout). As you can see, environment variables (e.g. my_project_dir) are supported so these files can be checked into source control and configured to point to local workspaces. The first line points to compiled Java classes in the project output directory. The second line points to the source directory for resource files instead of the build directory. This allows you to edit files in your IDE such as *.composite and sca-contribution.xml without having to compile or copy the files.
3. After you have performed an initial build, booted your runtime, and copied the contribution files, your application should start normally. I typically add an option in build processes to assembly a local F3 image and copy over the *.contribution files for initial setup.
4. Now modify a Java class and perform an incremental build in the IDE (no need to run a full build). After the class has been compiled, touch the corresponding *.contribution file. This will trigger the F3 server to reload the contribution and apply the change. This process should typically take under a second assuming you have reasonable sized contributions.
I'm also going to implement support for reloading dependent contributions. For example, if contributions B and C depend on A and A is modified, the server will automatically detect this and reload all three.
If anyone is interested in testing this feature or getting started with it, feel free to ping me or send a note to the list and I will be happy to provide additional pointers.
Jim