On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Simon Nash wrote: > >> ant elder wrote: >> >>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino < >>> [EMAIL PROTECTED]> wrote: >>> >>>> Jean-Sebastien Delfino wrote: >>>> >>>>> I'd like to discuss the following: "What distro Zips are we building >>>>> and >>>>> what do they contain?" >>>>> >>>>> I think we could improve our distro scheme to provide: >>>>> - smaller packages >>>>> - easier for people to find what they need >>>>> >>>>> I was thinking about the following binary distro zips: >>>>> >>>>> - tuscany-core.zip - The base that everybody needs. >>>>> core assembly model and runtime >>>>> Java APIs, Java components >>>>> >>>>> - tuscany-web.zip - For WS and Web developers >>>>> WS binding, Web 2.0 bindings, Scripting components, Widget components >>>>> >>>>> - tuscany-jee.zip - For JEE app integration >>>>> EJB, RMI and JMS bindings, Spring components >>>>> >>>>> - tuscany-process.zip - For process development >>>>> BPEL and XQuery components >>>>> >>>>> - tuscany-all.zip - all of the above >>>>> >>>>> Note that I'm not trying to tackle release cycles and the potential for >>>>> releasing the above zips independently in this discussion and I'm >>>>> >>>> assuming >>> >>>> that we release all of the above together. >>>>> >>>>> I'm also assuming that the relevant samples are included in each zip. >>>>> >>>>> This email was from 1/22/08, generated a lot of discussion for about 3 >>>> weeks, lots of opinions, no conclusion, no commits :) >>>> >>>> >>> No commits as we haven't found much consensus yet. >>> >>> I still think the same as what I had posted then, plus additional ideas: >>>> >>>> - Use OSGi exports/imports to export clean SPIs, hide internals, and >>>> >>> refine >>> >>>> the contents of the distros and their dependencies. >>>> >>>> Disclaimer - Please don't get me wrong I'm not saying that one distro == >>>> >>> one >>> >>>> OSGi bundle, as I've already said several times on the list that the >>>> big-OSGi-bundle approach didn't make sense to me :) I just think that >>>> declaring and enforcing clean dependencies using OSGi will help us >>>> refine >>>> the contents of each distro. >>>> >>>> The term "enforcing" seems to suggest that there might be an OSGi >> dependency for the Tuscany runtime. I don't know if this was >> intended. I think the right approach is to have a Tuscany+OSGi >> runtime (as we are building in itest\osgi-tuscany) which would >> actually do enforcement, and a non-OSGi Tuscany runtime in which >> the exports/imports are present in the jars but not enforced. >> > > Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi > environment... > > >> What would be the granularity of these OSGi bundles? If the bundles >> are the current maven modules, I think we will find a number of >> classes that need to be exported even though these classes are not >> considered part of the SPI or API that the module provides. >> To resolve this I see the following options: >> a) Export more than we really believe is correct. This >> leaves us in the current unsatisfactory position of exposing >> unwanted implementation internals. >> b) Combine multiple maven modules with a close implementation >> affinity into a single OSGi bundle, and only expose true >> APIs or SPIs from these bundles. >> c) Refactor the code to remove dependencies on internals of other >> modules, and create new SPIs or APIs when this isn't possible. >> >> I believe a combination of b) and c) is the best approach. >> > > We've already rehashed this (and disagreed on this) in several other > threads, where I've already given my opinion: > - 1 bundle per module > - clean API/SPI imports/exports By "1 bundle per module" do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant
