Build structure - separating core from extensions

[ant elder <an...@gmail.com>]

Over on the 2.0 themes thread we've said we'd look at separating the core
modules from other extension modules, what would this look like?

As an initial strawman to discuss how about separate folders for each group
of related modules including all their tests and samples. So there could be
a core folder that would contain most of the minimal modules we're currently
bringing in stage 1 along with all the related itests, vtests and samples
relating to those, a webservices folder which has all the binding.ws and
wsdl related modules, and folders for each other extension type or other
sets of related modules we might have.

Although like that the samples are grouped within their related extension
folder that doesnt necessarily mean thats how they need to be structured in
the binary distributions we make. That build structure makes it easier to
develop and build functional areas, in the distribution we could move them
about wherever we like to make it easy for users.

Is this the type of thing others are thinking of?

   ...ant

Re: Build structure - separating core from extensions

[Luciano Resende <lu...@gmail.com>]

On Fri, Nov 21, 2008 at 11:17 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> ATM, I suggest that we focus on refining the code-level de-coupling instead
> of finding a better to organize the physical layout.

+ 1

>
> IIRC, we came to the current project code structure from something similar
> with what is proposed. What do we want to achieve by having separate folder
> tree for the core modules? Can you elaborate a bit more how we could benefit
> from it?
>
> I have a few things in mind:
>
> 1) It's hard to group the Tuscany maven modules in a hierarchical way which
> doesn't support overlapping.
> * Some modules are reused and it's not easy to find its home
> * Some modules are extensions logically, such as implementation-java-xxx,
> are they part of the core or extension?
>
> 2) We can help developers and users knows what's what for the tuscany code
> base
>
> * We already have a good naming convention to help us categorize the
> extensions, such as binding-xxx, implementation-xxx, databindihng-xxx,
> interface-xxx and host-xxx.
> * The current code structure is documented at:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Build+Your+SCA+Light+Distribution
>
> 3) Build distributions for different functions
>
> * We could produce distributions to include related runtime modules, samples
> and itests at different levels, such as core, webservice, all-in-one
>
> Thanks,
> Raymond
> From: Simon Laws
> Sent: Friday, November 21, 2008 8:20 AM
> To: dev@tuscany.apache.org ; antelder@apache.org
> Subject: Re: Build structure - separating core from extensions
>
>
> On Fri, Nov 21, 2008 at 11:19 AM, ant elder <an...@gmail.com> wrote:
>>
>> Over on the 2.0 themes thread we've said we'd look at separating the core
>> modules from other extension modules, what would this look like?
>>
>> As an initial strawman to discuss how about separate folders for each
>> group of related modules including all their tests and samples. So there
>> could be a core folder that would contain most of the minimal modules we're
>> currently bringing in stage 1 along with all the related itests, vtests and
>> samples relating to those, a webservices folder which has all the binding.ws
>> and wsdl related modules, and folders for each other extension type or other
>> sets of related modules we might have.
>>
>> Although like that the samples are grouped within their related extension
>> folder that doesnt necessarily mean thats how they need to be structured in
>> the binary distributions we make. That build structure makes it easier to
>> develop and build functional areas, in the distribution we could move them
>> about wherever we like to make it easy for users.
>>
>> Is this the type of thing others are thinking of?
>>
>>    ...ant
>>
>>
> I was certainly what I had in mind when I wrote that line. I wasn't thinking
> that this related to any particular distribution structure but just as a
> crutch for the newcomer to the project. I know this isn't a popular proposal
> (from mail list exchanges from way back). IIRC the project used to be
> something like this a long time ago and the project moved away from it.  So
> I guess I'm open minded, welcome a bit of a discussion about it and am keen
> to see what happens.
>
> If there is no concensus then I guess what we have is at least simple even
> if it's not easy to understand. If people feel that we must stay with the
> flat structure can we consider adopting some more meaningful module naming
> scheme in order to;
>
> 1/ disitinguish those modules that are loaded as extensions and those that
> aren't
> 2/ consistently associate samples and itests with the function they are
> focused on.
>
> Simon
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Build structure - separating core from extensions

[ant elder <an...@gmail.com>]

On Fri, Nov 21, 2008 at 7:17 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> ATM, I suggest that we focus on refining the code-level de-coupling
instead
> of finding a better to organize the physical layout.
>
> IIRC, we came to the current project code structure from something similar
> with what is proposed. What do we want to achieve by having separate
folder
> tree for the core modules? Can you elaborate a bit more how we could
benefit
> from it?
>
> I have a few things in mind:
>
> 1) It's hard to group the Tuscany maven modules in a hierarchical way
which
> doesn't support overlapping.
> * Some modules are reused and it's not easy to find its home
> * Some modules are extensions logically, such as implementation-java-xxx,
> are they part of the core or extension?
>

Being pragmatic will help so for example if a module needs to be shared and
doesn't cause problems (eg dragging too many dependencies) maybe just put it
in the core hierarchy. I've had a brief skim over the modules and think this
is doable but we're probably not going to find out all the issues without
just trying to do it, before doing that do you have any examples of which
you think might be problematic modules?

  ...ant

Re: Build structure - separating core from extensions

[Raymond Feng <en...@gmail.com>]

Hi,

ATM, I suggest that we focus on refining the code-level de-coupling instead of finding a better to organize the physical layout. 

IIRC, we came to the current project code structure from something similar with what is proposed. What do we want to achieve by having separate folder tree for the core modules? Can you elaborate a bit more how we could benefit from it? 

I have a few things in mind:

1) It's hard to group the Tuscany maven modules in a hierarchical way which doesn't support overlapping. 
* Some modules are reused and it's not easy to find its home 
* Some modules are extensions logically, such as implementation-java-xxx, are they part of the core or extension?

2) We can help developers and users knows what's what for the tuscany code base

* We already have a good naming convention to help us categorize the extensions, such as binding-xxx, implementation-xxx, databindihng-xxx, interface-xxx and host-xxx.
* The current code structure is documented at: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Build+Your+SCA+Light+Distribution

3) Build distributions for different functions

* We could produce distributions to include related runtime modules, samples and itests at different levels, such as core, webservice, all-in-one

Thanks,
Raymond


From: Simon Laws 
Sent: Friday, November 21, 2008 8:20 AM
To: dev@tuscany.apache.org ; antelder@apache.org 
Subject: Re: Build structure - separating core from extensions





On Fri, Nov 21, 2008 at 11:19 AM, ant elder <an...@gmail.com> wrote:

  Over on the 2.0 themes thread we've said we'd look at separating the core modules from other extension modules, what would this look like?

  As an initial strawman to discuss how about separate folders for each group of related modules including all their tests and samples. So there could be a core folder that would contain most of the minimal modules we're currently bringing in stage 1 along with all the related itests, vtests and samples relating to those, a webservices folder which has all the binding.ws and wsdl related modules, and folders for each other extension type or other sets of related modules we might have.

  Although like that the samples are grouped within their related extension folder that doesnt necessarily mean thats how they need to be structured in the binary distributions we make. That build structure makes it easier to develop and build functional areas, in the distribution we could move them about wherever we like to make it easy for users.

  Is this the type of thing others are thinking of?

     ...ant



I was certainly what I had in mind when I wrote that line. I wasn't thinking that this related to any particular distribution structure but just as a crutch for the newcomer to the project. I know this isn't a popular proposal (from mail list exchanges from way back). IIRC the project used to be something like this a long time ago and the project moved away from it.  So I guess I'm open minded, welcome a bit of a discussion about it and am keen to see what happens. 

If there is no concensus then I guess what we have is at least simple even if it's not easy to understand. If people feel that we must stay with the flat structure can we consider adopting some more meaningful module naming scheme in order to;

1/ disitinguish those modules that are loaded as extensions and those that aren't
2/ consistently associate samples and itests with the function they are focused on.

Simon

Re: Build structure - separating core from extensions

[ant elder <an...@apache.org>]

On Fri, Nov 21, 2008 at 4:20 PM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Fri, Nov 21, 2008 at 11:19 AM, ant elder <an...@gmail.com> wrote:
>
>> Over on the 2.0 themes thread we've said we'd look at separating the core
>> modules from other extension modules, what would this look like?
>>
>> As an initial strawman to discuss how about separate folders for each
>> group of related modules including all their tests and samples. So there
>> could be a core folder that would contain most of the minimal modules we're
>> currently bringing in stage 1 along with all the related itests, vtests and
>> samples relating to those, a webservices folder which has all the
>> binding.ws and wsdl related modules, and folders for each other extension
>> type or other sets of related modules we might have.
>>
>> Although like that the samples are grouped within their related extension
>> folder that doesnt necessarily mean thats how they need to be structured in
>> the binary distributions we make. That build structure makes it easier to
>> develop and build functional areas, in the distribution we could move them
>> about wherever we like to make it easy for users.
>>
>> Is this the type of thing others are thinking of?
>>
>>    ...ant
>>
>>
>> I was certainly what I had in mind when I wrote that line. I wasn't
> thinking that this related to any particular distribution structure but just
> as a crutch for the newcomer to the project. I know this isn't a popular
> proposal (from mail list exchanges from way back). IIRC the project used to
> be something like this a long time ago and the project moved away from it.
> So I guess I'm open minded, welcome a bit of a discussion about it and am
> keen to see what happens.
>


IIRC the main reason we moved away from that structure was because back then
there were few tests and a lot of changes and refactoring going on all the
time, and that meant that the extensions were constantly getting broken due
to changes in the core modules happening without noticing they broke
extensions. Now that we have a lot of tests and the continuum build machine
i'd hope this wouldn't be such a problem.

   ...ant

Re: Build structure - separating core from extensions

[Simon Laws <si...@googlemail.com>]

On Fri, Nov 21, 2008 at 11:19 AM, ant elder <an...@gmail.com> wrote:

> Over on the 2.0 themes thread we've said we'd look at separating the core
> modules from other extension modules, what would this look like?
>
> As an initial strawman to discuss how about separate folders for each group
> of related modules including all their tests and samples. So there could be
> a core folder that would contain most of the minimal modules we're currently
> bringing in stage 1 along with all the related itests, vtests and samples
> relating to those, a webservices folder which has all the binding.ws and
> wsdl related modules, and folders for each other extension type or other
> sets of related modules we might have.
>
> Although like that the samples are grouped within their related extension
> folder that doesnt necessarily mean thats how they need to be structured in
> the binary distributions we make. That build structure makes it easier to
> develop and build functional areas, in the distribution we could move them
> about wherever we like to make it easy for users.
>
> Is this the type of thing others are thinking of?
>
>    ...ant
>
>
> I was certainly what I had in mind when I wrote that line. I wasn't
thinking that this related to any particular distribution structure but just
as a crutch for the newcomer to the project. I know this isn't a popular
proposal (from mail list exchanges from way back). IIRC the project used to
be something like this a long time ago and the project moved away from it.
So I guess I'm open minded, welcome a bit of a discussion about it and am
keen to see what happens.

If there is no concensus then I guess what we have is at least simple even
if it's not easy to understand. If people feel that we must stay with the
flat structure can we consider adopting some more meaningful module naming
scheme in order to;

1/ disitinguish those modules that are loaded as extensions and those that
aren't
2/ consistently associate samples and itests with the function they are
focused on.

Simon