Hi Hadrian,
+1; makes sense to fix the split-package problem for the 0.8.0 release.
These should be different PRs from the org.apache.brooklyn, so that they
can be reviewed accordingly.
I'll need to look again at the packages to give a definite opinion on
naming. It's probably not as simple as org.apache.brooklyn.core.* in ./core:
* There are utility classes in core named brooklyn.util.*, which
should be compared with the brooklyn-util-common
(main difference is that many utils in core have dependencies on
other things in core, rather than being truly independent utils).
* I'd like us to extract the core tasks framework
(brooklyn.util.tasks) to its own module.
---
We should also review what is public (i.e. what packages should be
exported). For example, is core's brooklyn.internal.* definitely not
used by any other projects?
---
An alternative approach (definitely less appealing for me long term)
would be to use OSGi fragments. I think something like that was done in
the early days of OSGi'ifying jclouds, but don't recall the details off
hand. There's an e-mail thread [1] and a blog post about it [2].
Aled
[1] https://groups.google.com/forum/#!topic/jclouds-dev/FdsbfELc1o0
[2] http://iocanel.blogspot.co.uk/2012/06/osgification-good-bad-purist.html
On 06/08/2015 15:50, Hadrian Zbarcea wrote:
Hi,
I opened a new jira [1] for this. While doing my refactoring in ./api
I discovered quite a bunch of places where we have split packages
among api, utils, core, etc.
I would recommend using something like:
org.apache.brooklyn.api.* in ./api
org.apache.brooklyn.core.* in ./core
and so forth. There are also a bunch of circular dependencies and
other smaller issues that we should correct.
WDYT?
Hadrian
