On 26.10.16 9:44 , Alexander Klimetschek wrote:
FWIW, I would prefer oak to have better modularization.
It also overlaps with Michael Marth's other recent thread "On adding new APIs"
- the exported APIs in Oak are all ad hoc because of it's monolithic design (i.e. all in
oak-core) and no clear API packages designed upfront. Someone had to figure out what
packages need to exported after the fact, and a lot of things are exported that should
really not be, and because of that, you have to update a lot more oak code when something
changes in these, because it inadvertently depends on these exported classes, although it
doesn't use them.
Building a patch for Oak to try something out as an outside is very difficult,
as things aren't well modularized. I was recently involved with
oak-auth-external, and you can only really work on it if you always rebuild and
redeploy the whole of oak. It's pretty painful… builds are also slow, as
because of the snapshot dependencies you have to build everything which takes a
lot of time with all the tests. With released dependencies between the modules,
one could work on a higher level module without worrying about the lower layer,
as it stays in the same released version. I would argue you might get more
contributions if things were easier on this front.
Releasing modularized stuff can be easier: if there is only a change in one
module, you only have to release one, instead of all of them. Faster
turnaround. A
+1.
It would also help re. backporting, continuous integration, releasing,
testing, longevity, code reuse, maintainability, reducing technical
debt, deploying, stability, etc, etc...
Michael
Just my 2 cents,
Alex
