You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/08/05 13:23:10 UTC
[PROPOSAL] add one more "layer" to the server.trunk ant build
The issue raised in 3 different current threads, so maybe it is better
to talk about it in a new thread.
While creating more modules there is the case where we use many utility
classes in our codebase.
The current ant build is by purpose organized in 4 layers:
- deployments
- functions
- libraries
- apis
Each layers module can only depends on modules in the underlying layers.
What layer a module belongs to is automatically recognized by looking at
the module suffix.
Currently our utilities are "hosted" in library modules, and this make
them useless to other library modules (utilities cannot be shared
between libraries).
There is a long term plan of removing the utilities at all or to move
them to external libraries (hosted by JAMES or as part of already
existing Apache "Commons" libraries). My opinion is that similar plans
tend to move attention/efforts to the wrong goal.
--------
PROPOSAL
--------
I propose that we introduce a new kind (or two) of module at the same
level of the api module, so it would be:
- deployments
- functions
- libraries
- apis | commons | utils
The new modules MUST have no dependencies on other modules as for APIs
but they are not API so having new types would help our refactoring in
the short term.
I think this would also be useful to move some library code "down" to a
common/util module because this automatically make it clear that the
code have no dependencies on other servers libraries.
I see the need for:
deliverynotification code being discussed in "[server.trunk] introducing
mail-library"
we then have some stream handling class, a security/digest class, maybe
some encoding/decoding class having no dependencies and being used by
unrelated code. My proposal is to put everything else in a single module
as a first step, and evaluate next steps once we see what ended up
inside the module.
Maybe "deliverynotification-util" and "common-util" are good names for
the "-util" case, or "deliverynotification-common" and "util-common" are
an alternative in the "-common" case.
ATM I would go with the -util suffix.
An alternative would be to use "-library" for the utilities (code with
no dependencies) and "-impl" for current libraries (they often are
implementations of stuff we have in -api modules). I don't have a strong
opinion on the best solution, I just have a strong feeling that we need
a fast/"easy to adopt" solution to accomplish a better modularization.
Opinions?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by James D Carroll <ja...@gmail.com>.
There's a company called Lattix (www.lattix.com) that makes a dependency
discovery tool that may help to tease out what dependencies are in the
code. They offer a free license to open source projects. Perhaps this
tool would be of assistance. I've always wanted to give it a try myself,
but if you guys find it useful, I'd love to see the results.
James
On Tue, 2008-08-05 at 13:23 +0200, Stefano Bagnara wrote:
> The issue raised in 3 different current threads, so maybe it is better
> to talk about it in a new thread.
>
> While creating more modules there is the case where we use many utility
> classes in our codebase.
>
> The current ant build is by purpose organized in 4 layers:
> - deployments
> - functions
> - libraries
> - apis
>
> Each layers module can only depends on modules in the underlying layers.
>
> What layer a module belongs to is automatically recognized by looking at
> the module suffix.
>
> Currently our utilities are "hosted" in library modules, and this make
> them useless to other library modules (utilities cannot be shared
> between libraries).
>
> There is a long term plan of removing the utilities at all or to move
> them to external libraries (hosted by JAMES or as part of already
> existing Apache "Commons" libraries). My opinion is that similar plans
> tend to move attention/efforts to the wrong goal.
>
> --------
> PROPOSAL
> --------
>
> I propose that we introduce a new kind (or two) of module at the same
> level of the api module, so it would be:
> - deployments
> - functions
> - libraries
> - apis | commons | utils
>
> The new modules MUST have no dependencies on other modules as for APIs
> but they are not API so having new types would help our refactoring in
> the short term.
>
> I think this would also be useful to move some library code "down" to a
> common/util module because this automatically make it clear that the
> code have no dependencies on other servers libraries.
>
> I see the need for:
>
> deliverynotification code being discussed in "[server.trunk] introducing
> mail-library"
>
> we then have some stream handling class, a security/digest class, maybe
> some encoding/decoding class having no dependencies and being used by
> unrelated code. My proposal is to put everything else in a single module
> as a first step, and evaluate next steps once we see what ended up
> inside the module.
>
> Maybe "deliverynotification-util" and "common-util" are good names for
> the "-util" case, or "deliverynotification-common" and "util-common" are
> an alternative in the "-common" case.
>
> ATM I would go with the -util suffix.
>
>
> An alternative would be to use "-library" for the utilities (code with
> no dependencies) and "-impl" for current libraries (they often are
> implementations of stuff we have in -api modules). I don't have a strong
> opinion on the best solution, I just have a strong feeling that we need
> a fast/"easy to adopt" solution to accomplish a better modularization.
>
> Opinions?
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RemoteDelivery test issue (Was: [PROPOSAL] add one more "layer" to
the server.trunk ant build)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Aug 7, 2008 at 11:02 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> i should have the ant for this work very soon
>> Cool! If I didn't already give you a kudos on ohloh I should definitely do
>> this after you took care of implementing my proposal. I didn't expect so
>> much :-)
>
> don't be so quick to thank me - RemoteDeliveryTest keeps failing (for
> about the 10 time over the last couple of days) and i don't like
> committing unless the tests are passing :-/
Ok, I see this frustrate you.. I really don't know how to help here. If
I had a choice I would have taken the ant build issue ;-)
I searched google for everything I could think about the stack trace we
have, with no success.
Please feel free to remove the test. If any user will sooner or later
file an issue about this we'll give it an higher priority. I don't have
anything else to be done on my side unless I'll happen to have a
reproducing environment.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 8/7/08, Robert Burrell Donkin <ro...@gmail.com> wrote:
>> On Thu, Aug 7, 2008 at 11:02 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Wed, Aug 6, 2008 at 8:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>>> Robert Burrell Donkin ha scritto:
>>>>>> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org>
>>>>>> wrote:
>>>>>>> I propose that we introduce a new kind (or two) of module at the same
>>>>>>> level
>>>>>>> of the api module, so it would be:
>>>>>>> - deployments
>>>>>>> - functions
>>>>>>> - libraries
>>>>>>> - apis | commons | utils
>>>>>>> [...]
>>>>>>> ATM I would go with the -util suffix.
>>>>>> [...]
>>>>>>> Opinions?
>>>>>> as i read this proposal, it's not really adding any more layers, just
>>>>>> allowing more types of module in the lowest layer. basically, we add
>>>>>> one or two more naming conventions for modules that behave like APIs.
>>>>>> i'm reluctant to add more layers and would strongly prefer JAMES to be
>>>>>> coupled just by APIs but this proposal seems a reasonable stepping
>>>>>> stone to me.
>>>>> Cool! Thank you for "rewording" my proposal. You got it exactly how I
>>>>> thought it :-)
>>>> i should have the ant for this work very soon
>>> Cool! If I didn't already give you a kudos on ohloh I should definitely do
>>> this after you took care of implementing my proposal. I didn't expect so
>>> much :-)
>
> +1 should mean active support ;-)
> [...]
> First cut is in. (Probably not as elegant as I'd like.) Please let me
> if you need any more changes.
>
> Robert
I had to make some fix (utils was not included in libraries classpath,
phoenix-deployments has its own build.xml to be updated too) but it was
really simple.
I already introduced a couple of util modules and Hudson told me he's
happy now with both ant and m2 :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/7/08, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On Thu, Aug 7, 2008 at 11:02 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>>
>>> On Wed, Aug 6, 2008 at 8:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>>
>>>> Robert Burrell Donkin ha scritto:
>>>>>
>>>>> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>>
>>>>>> I propose that we introduce a new kind (or two) of module at the same
>>>>>> level
>>>>>> of the api module, so it would be:
>>>>>> - deployments
>>>>>> - functions
>>>>>> - libraries
>>>>>> - apis | commons | utils
>>>>>> [...]
>>>>>> ATM I would go with the -util suffix.
>>>>>
>>>>> [...]
>>>>>>
>>>>>> Opinions?
>>>>>
>>>>> as i read this proposal, it's not really adding any more layers, just
>>>>> allowing more types of module in the lowest layer. basically, we add
>>>>> one or two more naming conventions for modules that behave like APIs.
>>>>> i'm reluctant to add more layers and would strongly prefer JAMES to be
>>>>> coupled just by APIs but this proposal seems a reasonable stepping
>>>>> stone to me.
>>>>
>>>> Cool! Thank you for "rewording" my proposal. You got it exactly how I
>>>> thought it :-)
>>>
>>> i should have the ant for this work very soon
>>
>> Cool! If I didn't already give you a kudos on ohloh I should definitely do
>> this after you took care of implementing my proposal. I didn't expect so
>> much :-)
+1 should mean active support ;-)
> don't be so quick to thank me - RemoteDeliveryTest keeps failing (for
> about the 10 time over the last couple of days) and i don't like
> committing unless the tests are passing :-/
First cut is in. (Probably not as elegant as I'd like.) Please let me
if you need any more changes.
Robert
>
> - robert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 7, 2008 at 11:02 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Wed, Aug 6, 2008 at 8:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>>
>>>>> I propose that we introduce a new kind (or two) of module at the same
>>>>> level
>>>>> of the api module, so it would be:
>>>>> - deployments
>>>>> - functions
>>>>> - libraries
>>>>> - apis | commons | utils
>>>>> [...]
>>>>> ATM I would go with the -util suffix.
>>>>
>>>> [...]
>>>>>
>>>>> Opinions?
>>>>
>>>> as i read this proposal, it's not really adding any more layers, just
>>>> allowing more types of module in the lowest layer. basically, we add
>>>> one or two more naming conventions for modules that behave like APIs.
>>>> i'm reluctant to add more layers and would strongly prefer JAMES to be
>>>> coupled just by APIs but this proposal seems a reasonable stepping
>>>> stone to me.
>>>
>>> Cool! Thank you for "rewording" my proposal. You got it exactly how I
>>> thought it :-)
>>
>> i should have the ant for this work very soon
>
> Cool! If I didn't already give you a kudos on ohloh I should definitely do
> this after you took care of implementing my proposal. I didn't expect so
> much :-)
don't be so quick to thank me - RemoteDeliveryTest keeps failing (for
about the 10 time over the last couple of days) and i don't like
committing unless the tests are passing :-/
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Wed, Aug 6, 2008 at 8:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> I propose that we introduce a new kind (or two) of module at the same
>>>> level
>>>> of the api module, so it would be:
>>>> - deployments
>>>> - functions
>>>> - libraries
>>>> - apis | commons | utils
>>>> [...]
>>>> ATM I would go with the -util suffix.
>>> [...]
>>>> Opinions?
>>> as i read this proposal, it's not really adding any more layers, just
>>> allowing more types of module in the lowest layer. basically, we add
>>> one or two more naming conventions for modules that behave like APIs.
>>> i'm reluctant to add more layers and would strongly prefer JAMES to be
>>> coupled just by APIs but this proposal seems a reasonable stepping
>>> stone to me.
>> Cool! Thank you for "rewording" my proposal. You got it exactly how I
>> thought it :-)
>
> i should have the ant for this work very soon
Cool! If I didn't already give you a kudos on ohloh I should definitely
do this after you took care of implementing my proposal. I didn't expect
so much :-)
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 6, 2008 at 8:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> I propose that we introduce a new kind (or two) of module at the same
>>> level
>>> of the api module, so it would be:
>>> - deployments
>>> - functions
>>> - libraries
>>> - apis | commons | utils
>>> [...]
>>> ATM I would go with the -util suffix.
>>
>> [...]
>>>
>>> Opinions?
>>
>> as i read this proposal, it's not really adding any more layers, just
>> allowing more types of module in the lowest layer. basically, we add
>> one or two more naming conventions for modules that behave like APIs.
>> i'm reluctant to add more layers and would strongly prefer JAMES to be
>> coupled just by APIs but this proposal seems a reasonable stepping
>> stone to me.
>
> Cool! Thank you for "rewording" my proposal. You got it exactly how I
> thought it :-)
i should have the ant for this work very soon
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> I propose that we introduce a new kind (or two) of module at the same level
>> of the api module, so it would be:
>> - deployments
>> - functions
>> - libraries
>> - apis | commons | utils
>> [...]
>> ATM I would go with the -util suffix.
> [...]
>> Opinions?
>
> as i read this proposal, it's not really adding any more layers, just
> allowing more types of module in the lowest layer. basically, we add
> one or two more naming conventions for modules that behave like APIs.
> i'm reluctant to add more layers and would strongly prefer JAMES to be
> coupled just by APIs but this proposal seems a reasonable stepping
> stone to me.
Cool! Thank you for "rewording" my proposal. You got it exactly how I
thought it :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
> The issue raised in 3 different current threads, so maybe it is better to
> talk about it in a new thread.
>
> While creating more modules there is the case where we use many utility
> classes in our codebase.
>
> The current ant build is by purpose organized in 4 layers:
> - deployments
> - functions
> - libraries
> - apis
>
> Each layers module can only depends on modules in the underlying layers.
>
> What layer a module belongs to is automatically recognized by looking at the
> module suffix.
>
> Currently our utilities are "hosted" in library modules, and this make them
> useless to other library modules (utilities cannot be shared between
> libraries).
>
> There is a long term plan of removing the utilities at all or to move them
> to external libraries (hosted by JAMES or as part of already existing Apache
> "Commons" libraries). My opinion is that similar plans tend to move
> attention/efforts to the wrong goal.
>
> --------
> PROPOSAL
> --------
>
> I propose that we introduce a new kind (or two) of module at the same level
> of the api module, so it would be:
> - deployments
> - functions
> - libraries
> - apis | commons | utils
>
> The new modules MUST have no dependencies on other modules as for APIs but
> they are not API so having new types would help our refactoring in the short
> term.
>
> I think this would also be useful to move some library code "down" to a
> common/util module because this automatically make it clear that the code
> have no dependencies on other servers libraries.
>
> I see the need for:
>
> deliverynotification code being discussed in "[server.trunk] introducing
> mail-library"
>
> we then have some stream handling class, a security/digest class, maybe some
> encoding/decoding class having no dependencies and being used by unrelated
> code. My proposal is to put everything else in a single module as a first
> step, and evaluate next steps once we see what ended up inside the module.
>
> Maybe "deliverynotification-util" and "common-util" are good names for the
> "-util" case, or "deliverynotification-common" and "util-common" are an
> alternative in the "-common" case.
>
> ATM I would go with the -util suffix.
>
>
> An alternative would be to use "-library" for the utilities (code with no
> dependencies) and "-impl" for current libraries (they often are
> implementations of stuff we have in -api modules). I don't have a strong
> opinion on the best solution, I just have a strong feeling that we need a
> fast/"easy to adopt" solution to accomplish a better modularization.
i think we might want to move away from api-library-function but let's
take one step at a time
> Opinions?
as i read this proposal, it's not really adding any more layers, just
allowing more types of module in the lowest layer. basically, we add
one or two more naming conventions for modules that behave like APIs.
i'm reluctant to add more layers and would strongly prefer JAMES to be
coupled just by APIs but this proposal seems a reasonable stepping
stone to me.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org