brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: [PROPOSAL] Refactor packages to avoid the split package problem
Date Thu, 06 Aug 2015 20:48:58 GMT
Remind me: it doesn't count as split packages if org.apache.brooklyn.entity is in one module
and org.apache.brooklyn.entity.core is in another?

On balance, I'd prefer api module to be the odd one out: not to include .api in the package
names.

I'm a fan of simple interface names. IMO it reads nicer/simpler if you miss out api.

I could be argued round though.

---
This is a big *one-off decision*.

I'm keen to get more people's opinions!

Aled

Sent from my iPhone


> On 6 Aug 2015, at 17:32, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
> 
> I agree. I am not sure what the best structure is, we can refine it while we do the refactoring.
For the api part though (which is my focus now) how do you feel about org.apache.brooklyn.api?
> 
> Cheers,
> Hadrian
> 
> 
>> On 08/06/2015 11:56 AM, Aled Sage wrote:
>> 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
>> 
>> 

Mime
View raw message