[server.trunk] user-api and user-library package names

[Stefano Bagnara <ap...@bago.org>]

user-api and user-library seems almost ok as modules, but I feel the 
packages are wrong.

Is this something concerning also other developers or it's me too much 
strict wrt packages/dependencies and this stuff?

we have these packages in user-api:
o.a.j.vut
o.a.j.api.user
o.a.j.services

then we have these in user-library:
o.a.j.core
o.a.j.management
o.a.j.security
o.a.j.services
o.a.j.userrepository
o.a.j.util
o.a.j.vut
o.a.j (for JamesMBean)


e.g:

1) o.a.j.security is only used by user-library in the whole tree and 
contains a single class. I'd like to move it to the generic "util-api" 
module or to move it in the same package of DefaultUser (as it is the 
only client for that class).

2) o.a.j.JamesMBean this is deprecated stuff, let's remove it, forever. 
We have much more/better management interfaces now.

3) the remaining packages should be refactored and moved to the 
org.apache.james.user subpackage, introducing more nesting between api 
and library and leaving space for functions to sub-package api/library 
packages.

4) after #3 I hope (and I'd like) to be able to support backward 
compatibility by using a function module (or the phoenix-deployment 
module as we'll need to "repackage" also functions later) having classes 
in the old bad package.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] user-api and user-library package names

[Robert Burrell Donkin <ro...@gmail.com>]

On Wed, Aug 6, 2008 at 8:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Tue, Aug 5, 2008 at 12:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>
>> <snip>
>>
>>>>> we have these packages in user-api:
>>>>> o.a.j.vut
>>>>> o.a.j.api.user
>>>>> o.a.j.services
>>>>>
>>>>> then we have these in user-library:
>>>>> o.a.j.core
>>>>> o.a.j.management
>>>>> o.a.j.security
>>>>> o.a.j.services
>>>>> o.a.j.userrepository
>>>>> o.a.j.util
>>>>> o.a.j.vut
>>>>> o.a.j (for JamesMBean)
>>>>
>>>> i think that this is too many
>>>>
>>>> i would prefer all api's to be packaged under o.a.j.api.**.* so that
>>>> interfaces used internally from those intended to allow external
>>>> extension and so on
>>>
>>> What about
>>>
>>> moving this in the user-api module:
>>> - from user-api/o.a.j.services/Users*|James* to user-api/o.a.j.api.user
>>> - from user-api/o.a.j.services/Virtual* to user-api/o.a.j.api.vut
>>> - from user-api/o.a.j.vut to user-api/o.a.j.api.vut
>>>
>>> the vut and user packages do not need to be nested because they do not
>>> have
>>> dependencies (they could even be 2 separate modules, but this is a matter
>>> of
>>> style once the packages are correct and self contained).
>>
>> sounds good to me
>>
>>> move this classes from user-library to user-api in the
>>> o.a.j.api.vut.management package:
>>> o.a.j.management.VirtualUserTableManagementException
>>> o.a.j.vut.InvalidMappingException
>>> o.a.j.services.VirtualUserTableManagementService
>>> move this classes from user-library to user-api in the
>>> o.a.j.api.user.management package:
>>> o.a.j.management.UserManagementException
>>> o.a.j.management.UserManagementMBean
>>> (they simply expose "mutable" stuff for the User / VUTs)
>>
>> i've been wondering about the coupling around remote manager and the
>> management interfaces for a while now. in some ways, i think that
>> management interfaces should be private so that implementations can
>> vary but i didn't find including them in higher layer worked for me
>> either. so let's try out this proposal.
>
> I see your point, indeed. I didn't evaluate this so good, so I'll refresh
> this once/if I'll put my hands on this issue.
> BTW my first goal here is to have good packages, then if put some code in
> api instead of library it should be really easy to move it later again.
> I don't think/plan we'll be able to get it right on the first attempt, but
> we have to move some step forward.

+1

definitely: i'm positive about the repackaging but we may need some
more refinements later

>>> move o.a.j.services.JamesUser from library to user-api/o.a.j.api.user
>>> package.
>>>
>>> reorganize classe in user-library according to the repackaging of the
>>> api:
>>> they deserve a similar tree (user | vut | vut.management |
>>> user.management).
>>>
>>> This should make the library module much more compact in term of
>>> packages.
>>
>> i dislike JamesUser and prefer smaller APIs but let's give this a go
>
> IIRC this User / JamesUser / DefaultUser / DefaultJamesUser is something I
> always felt as weird. The api is User but everywhere in server code we check
> instanceof JamesUser and cast to it. Maybe overengineered considering that
> the api currently serve only server codebase.
>
> But this is a different issue, I'd like to keep repackage/remodularization
> separated from other aspects, in order to keep the goal narrow.

+1

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] user-api and user-library package names

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Tue, Aug 5, 2008 at 12:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <ap...@bago.org> wrote:
> 
> <snip>
> 
>>>> we have these packages in user-api:
>>>> o.a.j.vut
>>>> o.a.j.api.user
>>>> o.a.j.services
>>>>
>>>> then we have these in user-library:
>>>> o.a.j.core
>>>> o.a.j.management
>>>> o.a.j.security
>>>> o.a.j.services
>>>> o.a.j.userrepository
>>>> o.a.j.util
>>>> o.a.j.vut
>>>> o.a.j (for JamesMBean)
>>> i think that this is too many
>>>
>>> i would prefer all api's to be packaged under o.a.j.api.**.* so that
>>> interfaces used internally from those intended to allow external
>>> extension and so on
>> What about
>>
>> moving this in the user-api module:
>> - from user-api/o.a.j.services/Users*|James* to user-api/o.a.j.api.user
>> - from user-api/o.a.j.services/Virtual* to user-api/o.a.j.api.vut
>> - from user-api/o.a.j.vut to user-api/o.a.j.api.vut
>>
>> the vut and user packages do not need to be nested because they do not have
>> dependencies (they could even be 2 separate modules, but this is a matter of
>> style once the packages are correct and self contained).
> 
> sounds good to me
> 
>> move this classes from user-library to user-api in the
>> o.a.j.api.vut.management package:
>> o.a.j.management.VirtualUserTableManagementException
>> o.a.j.vut.InvalidMappingException
>> o.a.j.services.VirtualUserTableManagementService
>> move this classes from user-library to user-api in the
>> o.a.j.api.user.management package:
>> o.a.j.management.UserManagementException
>> o.a.j.management.UserManagementMBean
>> (they simply expose "mutable" stuff for the User / VUTs)
> 
> i've been wondering about the coupling around remote manager and the
> management interfaces for a while now. in some ways, i think that
> management interfaces should be private so that implementations can
> vary but i didn't find including them in higher layer worked for me
> either. so let's try out this proposal.

I see your point, indeed. I didn't evaluate this so good, so I'll 
refresh this once/if I'll put my hands on this issue.
BTW my first goal here is to have good packages, then if put some code 
in api instead of library it should be really easy to move it later again.
I don't think/plan we'll be able to get it right on the first attempt, 
but we have to move some step forward.

>> move o.a.j.services.JamesUser from library to user-api/o.a.j.api.user
>> package.
>>
>> reorganize classe in user-library according to the repackaging of the api:
>> they deserve a similar tree (user | vut | vut.management | user.management).
>>
>> This should make the library module much more compact in term of packages.
> 
> i dislike JamesUser and prefer smaller APIs but let's give this a go

IIRC this User / JamesUser / DefaultUser / DefaultJamesUser is something 
I always felt as weird. The api is User but everywhere in server code we 
check instanceof JamesUser and cast to it. Maybe overengineered 
considering that the api currently serve only server codebase.

But this is a different issue, I'd like to keep 
repackage/remodularization separated from other aspects, in order to 
keep the goal narrow.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] user-api and user-library package names

[Robert Burrell Donkin <ro...@gmail.com>]

On Tue, Aug 5, 2008 at 12:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <ap...@bago.org> wrote:

<snip>

>>> we have these packages in user-api:
>>> o.a.j.vut
>>> o.a.j.api.user
>>> o.a.j.services
>>>
>>> then we have these in user-library:
>>> o.a.j.core
>>> o.a.j.management
>>> o.a.j.security
>>> o.a.j.services
>>> o.a.j.userrepository
>>> o.a.j.util
>>> o.a.j.vut
>>> o.a.j (for JamesMBean)
>>
>> i think that this is too many
>>
>> i would prefer all api's to be packaged under o.a.j.api.**.* so that
>> interfaces used internally from those intended to allow external
>> extension and so on
>
> What about
>
> moving this in the user-api module:
> - from user-api/o.a.j.services/Users*|James* to user-api/o.a.j.api.user
> - from user-api/o.a.j.services/Virtual* to user-api/o.a.j.api.vut
> - from user-api/o.a.j.vut to user-api/o.a.j.api.vut
>
> the vut and user packages do not need to be nested because they do not have
> dependencies (they could even be 2 separate modules, but this is a matter of
> style once the packages are correct and self contained).

sounds good to me

> move this classes from user-library to user-api in the
> o.a.j.api.vut.management package:
> o.a.j.management.VirtualUserTableManagementException
> o.a.j.vut.InvalidMappingException
> o.a.j.services.VirtualUserTableManagementService
> move this classes from user-library to user-api in the
> o.a.j.api.user.management package:
> o.a.j.management.UserManagementException
> o.a.j.management.UserManagementMBean
> (they simply expose "mutable" stuff for the User / VUTs)

i've been wondering about the coupling around remote manager and the
management interfaces for a while now. in some ways, i think that
management interfaces should be private so that implementations can
vary but i didn't find including them in higher layer worked for me
either. so let's try out this proposal.

> move o.a.j.services.JamesUser from library to user-api/o.a.j.api.user
> package.
>
> reorganize classe in user-library according to the repackaging of the api:
> they deserve a similar tree (user | vut | vut.management | user.management).
>
> This should make the library module much more compact in term of packages.

i dislike JamesUser and prefer smaller APIs but let's give this a go

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] user-api and user-library package names

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> user-api and user-library seems almost ok as modules, but I feel the
>> packages are wrong.
> 
> +1
> 
>> Is this something concerning also other developers or it's me too much
>> strict wrt packages/dependencies and this stuff?
> 
> no: illuminated issues with packages was one reason why i started the
> modularisation

Modules are really good at this. Thank you.
maven allow to easily create nice dependencies graph for modules, they 
are great to improve sources self-documentation.

>> we have these packages in user-api:
>> o.a.j.vut
>> o.a.j.api.user
>> o.a.j.services
>>
>> then we have these in user-library:
>> o.a.j.core
>> o.a.j.management
>> o.a.j.security
>> o.a.j.services
>> o.a.j.userrepository
>> o.a.j.util
>> o.a.j.vut
>> o.a.j (for JamesMBean)
> 
> i think that this is too many
> 
> i would prefer all api's to be packaged under o.a.j.api.**.* so that
> interfaces used internally from those intended to allow external
> extension and so on

What about

moving this in the user-api module:
- from user-api/o.a.j.services/Users*|James* to user-api/o.a.j.api.user
- from user-api/o.a.j.services/Virtual* to user-api/o.a.j.api.vut
- from user-api/o.a.j.vut to user-api/o.a.j.api.vut

the vut and user packages do not need to be nested because they do not 
have dependencies (they could even be 2 separate modules, but this is a 
matter of style once the packages are correct and self contained).

move this classes from user-library to user-api in the 
o.a.j.api.vut.management package:
o.a.j.management.VirtualUserTableManagementException
o.a.j.vut.InvalidMappingException
o.a.j.services.VirtualUserTableManagementService
move this classes from user-library to user-api in the 
o.a.j.api.user.management package:
o.a.j.management.UserManagementException
o.a.j.management.UserManagementMBean
(they simply expose "mutable" stuff for the User / VUTs)

move o.a.j.services.JamesUser from library to user-api/o.a.j.api.user 
package.

reorganize classe in user-library according to the repackaging of the 
api: they deserve a similar tree (user | vut | vut.management | 
user.management).

This should make the library module much more compact in term of packages.

>> e.g:
>>
>> 1) o.a.j.security is only used by user-library in the whole tree and
>> contains a single class. I'd like to move it to the generic "util-api"
>> module or to move it in the same package of DefaultUser (as it is the only
>> client for that class).
> 
> i have reservations about util-api but i'll detail these when i finish
> an earlier mail

I wrote a PROPOSAL for this. For the matter of this refactoring it could 
even be moved to the o.a.j.user package and left in this module.

>> 2) o.a.j.JamesMBean this is deprecated stuff, let's remove it, forever. We
>> have much more/better management interfaces now.
> 
> +1
> 
>> 3) the remaining packages should be refactored and moved to the
>> org.apache.james.user subpackage, introducing more nesting between api and
>> library and leaving space for functions to sub-package api/library packages.
> 
> sounds reasonable
> 
>> 4) after #3 I hope (and I'd like) to be able to support backward
>> compatibility by using a function module (or the phoenix-deployment module
>> as we'll need to "repackage" also functions later) having classes in the old
>> bad package.
> 
> i would like to see pheonix-deployed used to maintain compatibility

Yes, I see it is better than a function.
I hope it is possible, but we'll see if/when we'll actually try to do 
all of this.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] user-api and user-library package names

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 12:59 AM, Stefano Bagnara <ap...@bago.org> wrote:
> user-api and user-library seems almost ok as modules, but I feel the
> packages are wrong.

+1

> Is this something concerning also other developers or it's me too much
> strict wrt packages/dependencies and this stuff?

no: illuminated issues with packages was one reason why i started the
modularisation

> we have these packages in user-api:
> o.a.j.vut
> o.a.j.api.user
> o.a.j.services
>
> then we have these in user-library:
> o.a.j.core
> o.a.j.management
> o.a.j.security
> o.a.j.services
> o.a.j.userrepository
> o.a.j.util
> o.a.j.vut
> o.a.j (for JamesMBean)

i think that this is too many

i would prefer all api's to be packaged under o.a.j.api.**.* so that
interfaces used internally from those intended to allow external
extension and so on

> e.g:
>
> 1) o.a.j.security is only used by user-library in the whole tree and
> contains a single class. I'd like to move it to the generic "util-api"
> module or to move it in the same package of DefaultUser (as it is the only
> client for that class).

i have reservations about util-api but i'll detail these when i finish
an earlier mail

> 2) o.a.j.JamesMBean this is deprecated stuff, let's remove it, forever. We
> have much more/better management interfaces now.

+1

> 3) the remaining packages should be refactored and moved to the
> org.apache.james.user subpackage, introducing more nesting between api and
> library and leaving space for functions to sub-package api/library packages.

sounds reasonable

> 4) after #3 I hope (and I'd like) to be able to support backward
> compatibility by using a function module (or the phoenix-deployment module
> as we'll need to "repackage" also functions later) having classes in the old
> bad package.

i would like to see pheonix-deployed used to maintain compatibility

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org