Quick comment...
I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins).
Don't you need to distribute the spec jars as well ? What about java-docs ? On 2/19/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Feb 19, 2007, at 9:45 AM, Jim Marino wrote: > There has been quite a bit of activity over the last month-and-a- > half enhancing the Kernel. Based on this work, I'd like to cut a > release of Kernel, the Standalone Runtime, the Webap Runtime, and > the Maven iTest Plugin as a stepping stone to having a 1. release. > I was thinking we would call this release "1.0 alpha". Works for me. I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). > > I see this "alpha" as evolving into a series of iterative releases > over the next month where we introduce some of the more > "compelling" features we have been discussing related to service > networks, federation, and deployment. The primary goals of the > first alpha release would be centered on enhancements to the > programming model that have been introduced with the recent Kernel > changes. Specifically, the alpha would provide an enhanced version > of Kernel that our users can experiment with, extend and provide us > feedback on. This will assist us in validating he programming model > supported by Kernel. > > The key features of the alpha release would be: > > 1. SCA 1.0 APIs > -Support for many of the new SCA 1.0 Java APIs (ComponentContext, > Conversational annotations) > > 2. An enhanced standalone runtime with JMX support > 3. An enhanced and SCA 1.0-based model for integration testing > (elimination of SCATestCase, which is not spec-compliant I propose we remove the "test" module. > 4. Simplified wiring > 5. Simplified extension model > 6. Architecture for support of federated deployment > 7. Support for web applications using SCA 1.0 concepts > > I'd like to follow the alpha with additional releases that > introduce additional support for federation, deployment, and the > SCA 1.0 APIs. To stage this, perhpaps we the following in the next > release after the alpha: > > - Contribution service > - Refactor of Databinding (mentioned in a separate thread) > - Introduction of master/slave nodes and federated wiring > - More complete support for conversational APIs, including > ServiceReference > > In terms of work items, I think we need the following (besides a > stable kernel :-) ): > > 1. Standalone runtime operational and able to deploy application > and extension SCDLS > 2. At least two samples. I propose the Calculator Sample > (Standalone and Web app) and the Loan Application Sample > > Feel free to suggest additional features. As a general principle, > I'd like to get a release out sooner rather than later with "big" > features introduced in the consecutive releases mentioned > previously. One thing I'd like to see if we can fit in but may have > to cut is the new PhysicalComponent builders. That may be something > we stage later. > > Hopefully, we can cut the release this week. > > Thoughts? The extension model is a bit hokey at the moment requiring users to create new or modify existing profiles which basically means duplicating the installation every time. We've had this view for a while that extensions should be dynamically and automatically loaded based on intent and for the 1.0 timeframe I think we should provide that. However, this really requires the Contribution service be fully working to we can match intent to extension and I don't think that will be ready soon. We do support a very primitive extension mechanism where users can add them by modifying the system scdl (which is now externalized as a text file). I'm OK with releasing an alpha version like that with the intent-based support coming later (i.e. 1.0 beta or final). I think we need to do some clean-up on the poms. As Sebastien pointed out, there is a lot of dependency cruft in the SCA pom which should be stripped out - we can probably reduce that to just the configuration of checkstyle etc. I'm happy to don my build-monkey hat again and clean that up. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende http://people.apache.org/~lresende
