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. > > - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension > registry mechanism (what we have now in Tuscany or better a combination of > what we have now and the Eclipse Equinox registry for example) to detect > which pieces are installed and activate their capabilities. > Can you say a bit more about what an "extension registry mechanism" would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? ...ant
