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 ; [EMAIL PROTECTED] Subject: Re: Build structure - separating core from extensions On Fri, Nov 21, 2008 at 11:19 AM, ant elder <[EMAIL PROTECTED]> 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
