On Fri, Nov 21, 2008 at 11:17 AM, Raymond Feng <[EMAIL PROTECTED]> 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: [email protected] ; [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 > -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
