Build Improvements plugin seperation proposal

BRJS Multi Project Build Proposal

Problem

We want to move all of the BRJS plugins into seperate projects to seperate their classpaths and prevent the model having any dependencies on plugin code. These changes to the build should acheive the following:

• The classpaths for plugins must be seperate from one another and brjs-core cannot depend on any plugins.
• Allow code automatic refactoring in Eclipse. If plugin interfaces change the plugins will change.
• Contrib plugins should also be automatically refactored.
• Contrib plugins should all be in their own seperate repos
• It should be easy to run the tests for a contrib plugin against the current develop version of BRJS
• Core plugins should be part of the BRJS zip, contrib plugins should not
• BRJS core plugins should be easily discoverable to thirdparty plugin writers can find example plugins
• Thirdparty plugin developers can use the same build as we do for our plugins for their plugins

Other build goals:

• speed up the time it takes to re-run a build when nothing needs for long running tasks
• the jsdoc is slow and currently runs every time

Proposal

• We'll split the core plugins and brjs-core into 2 seperate repos, brjs and brjs-core-plugins.
  • brjs will contain the brjs-core java project and the core libraries
  • brjs-core-plugins will contain all of the brjs plugins each in their own seperate Gradle project
• Contrib plugins will all continue to live in their own seperate repos
• brjs-core-plugins will be checked out in a known location so the brjs build can autoconfigure the child projects so they are part of the main build

The project structure will look something like:

> brjs (brjs repo and root Gradle project)
	brjs-core
	brjs-sdk
	system-servlets
	...
 	> core-plugins
		js-bundler
		css-bundler
		...
	contrib-plugins
		> contrib-plugin1
		> contrib-plugin2
		> ...


'>' denotes the root of a git repository

• There will be a script that checks out all of the correct repos in the right places so it can be used by developers and Travis
• We'll need a step in the build that checks the right commands are available and part of the distribution

Improvements

While this gives us a reasonable workflow for plugin development it will probably need refinement for thirdparty developers. The following probably needs improving:

• there will not be a command for copying jars into the right location to use with a built BRJS
• its not entirely obvious that the BRJS build outputs a vanilla BRJS zip and not a zip with contrib plugins pre-bundled
• it will require developers to checkout the entire BRJS repo to do plugin development

We also have brjs-plugin-bootstrap which is a self contained plugin build which will use a pre-built BRJS to compile against.