You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2015/08/06 16:50:18 UTC
[PROPOSAL] Refactor packages to avoid the split package problem
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
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Aled Sage <al...@gmail.com>.
Thanks all.
Let's go with oab.api.*, and oab.core.* etc - that's the general consensus.
---
For backwards compatibility of persisted state, we'll need a file that
describes the package/class renames.
Users can then use the transformer tool (which uses xslt) to update
their persisted state accordingly.
---
I (and others please!) can also take the opportunity before the next GA
release to move other classes or rename other packages that with
hindsight are in the wrong place.
But that's for a separate e-mail thread!
Aled
On 12/08/2015 09:29, Andrea Turli wrote:
> 1. No strong feelings, lean towards oab.api.*
> 2. +1 for oab.core.*
>
> Andrea
>
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Andrea Turli <an...@cloudsoftcorp.com>.
1. No strong feelings, lean towards oab.api.*
2. +1 for oab.core.*
Andrea
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
1. Same as Hadrian - mostly neutral, slight preference to oab.api.*
2. +1 for oab.core.* Adding core to the duplicated package names only will be inconsistent.
>>>> 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?
It is used across modules. When OSGi-fying we had to include it explicitly in the list of exported packages (internal packages are ignored by default).
Svet.
> On 7.08.2015 г., at 1:49, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
> Agree on all counts. Especially on getting more opinions on this topic.
>
> Your memory serves you well :). The situation you described is not a split package.
>
> I'd suggest staying on this thread, but identify issues separately, discuss them separately and decide later how to deal with contentions, because hopefully there won't be the case. So I will start with capturing:
>
> 1. How to deal with ./api? In general I have a slight preference towards making things explicit. In this case I am mostly neutral. I would be fine with either aob.* or oab.api.*. There is a bit of a grey area, I think for packages like oab.entity.*, say .trait. A user would not know immediately what bundle implements that, especially if we'd have stuff in oab.entity.core (or whatever other convention we come up with).
>
> 2. What is the convention for implementations in multiple bundles? Should it be for example: oab.entity.core.* or oab.core.entity.* or something else? My preference would be oab.core.entity.*. The motivation is that a human user would be able to quickly guess that the package is implemented in brooklyn-core. Computers and tools don't care much.
>
> Cheers,
> Hadrian
>
>
>
> On 08/06/2015 04:48 PM, Aled Sage wrote:
>> 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 <hz...@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
>>>>
>>>>
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Agree on all counts. Especially on getting more opinions on this topic.
Your memory serves you well :). The situation you described is not a
split package.
I'd suggest staying on this thread, but identify issues separately,
discuss them separately and decide later how to deal with contentions,
because hopefully there won't be the case. So I will start with capturing:
1. How to deal with ./api? In general I have a slight preference towards
making things explicit. In this case I am mostly neutral. I would be
fine with either aob.* or oab.api.*. There is a bit of a grey area, I
think for packages like oab.entity.*, say .trait. A user would not know
immediately what bundle implements that, especially if we'd have stuff
in oab.entity.core (or whatever other convention we come up with).
2. What is the convention for implementations in multiple bundles?
Should it be for example: oab.entity.core.* or oab.core.entity.* or
something else? My preference would be oab.core.entity.*. The motivation
is that a human user would be able to quickly guess that the package is
implemented in brooklyn-core. Computers and tools don't care much.
Cheers,
Hadrian
On 08/06/2015 04:48 PM, Aled Sage wrote:
> 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 <hz...@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
>>>
>>>
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Aled Sage <al...@gmail.com>.
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 <hz...@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
>>
>>
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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
>
>
Re: [PROPOSAL] Refactor packages to avoid the split package problem
Posted by Aled Sage <al...@gmail.com>.
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