On 6/10/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > >> 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 >> >> > I think that the right design is one bundle per maven module.
>From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I don't think that aggregating multiple modules into a single bundle makes > much sense, or they should be aggregated in a single Maven module in the > first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 "modules" based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime of a different version? The answer is probably "no". But that does not necessarily mean that these should be combined into a single maven module. In some cases the splitting of modules does have a point beyond versioning - eg. separating models and runtimes like you have been doing. Now that is good reason to define different bundles for these two - enabling bundles to be used independently of each other. But I dont believe that we have 100 different entities in Tuscany that can be separately versioned or used independently. If we look at the total Tuscany distribution including Tuscany modules and 3rd party libraries, aggregating Tuscany modules doesn't add much value unless 3rd party libs that go with these modules are also combined together with the Tuscany modules in a "bundle". And that to me is completely impractical. If we are anyway going to require a "launcher" of some form, wouldn't it be just as easy to maintain one-bundle-per-module? > -- > Jean-Sebastien > -- Thank you... Regards, Rajini
