Reorganize plug-ins and build system
vladdu opened this issue · comments
This is a placeholder for notes about plans to clean up the code base and make it easier to build, test and deploy.
Status today:
- the repository contains everything, even the third-party extensions that don't evolve at the same speed
- building and packaging the update site works with scripts on the Jenkins server, with things that are assumed to be pre-installed in a certain way (and the documentation is "in the scripts"...). It is possible to build manually in Eclipse, but again it has undocumented dependencies on one's environment.
- standard build systems are difficult to use because they are targeted at Java code, and we have even Erlang code that has to be packaged in plug-ins. The original idea was that Erlang and Java code for a subsystem should be possible to install/update/uninstall separately, but in practice the evolution was in the other direction.
- unit tests are assuming that Buckminster is used and that the test workspace can be populated automagically. Buckminster has many idiosyncrasies and I'd prefer to have the code independent of the tools used to build.
Things to do:
- separate Erlang engine code in another repository and have it provide a "generic" service; that more or less implies that the engine has to be made working first before the Java code can consume the services
- define engine APIs! Can we make these RESTful? Note that many operations are asynchronous, we'd like to be able to know the operation progress and retrieve partial results (if possible). [Eclipse Che might be a good partner for developing these APIs]
- the core erlide should pack a binary version of the Erlang engine; a plugin wraps that for usage with Eclipse and at runtime loads the beams into the Erlang runtime(s).
- separate third-party code in different repositories (wrangler, cover, tracing). How to handle 3pp with Erlang code? It still needs to get loaded... Maybe the loader should check extension points, much like today.
- I want to be able to build in the same way on all systems, with as standard tools as possible. Requirements on the environment shall be documented and installation scripted.
- test workspace should be populated from the code, removing dependency on the build tools. Hopefully it will be possible to just add code to the BeforeClass methods of the test suites.
Separate code according to usage and lifecycle:
- Erlang kernel engine code in separate repository, with erlang-only projects. The build packs all beams in a versioned zip, to be archived (and maybe published publicly too).
- Kernel wrapper plugin projects form a separate feature, built from the erlang projects whenever these change. Version is read from erlang .app. Result is published on p2 site.
- Runtime plugin also need a separate feature and p2 site. This means that we need common libraries to be separate too (we could use the main xtend libs, though - how does that work for local dev env? check!).
- Erlide includes the kernel and runtime features (also in its own p2 site). Check how maven handles that.
- Drive build process with Jenkins workflow plugin
- In dev env, projects are in workspace or target env, so they are available.
Done:
- use maven to build
- jenkins pipeline to deploy
- separate kernel engine repository
I'm not sure the rest is needed, really. Would be nice though, but at the moment it feels like there are more meaningful tasks. Closing.