You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/02/19 18:45:38 UTC
Java Kernel Release
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".
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
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?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
> I propose we remove the "test" module.
>
+1. If you are going to don the build-monkey-suit, do you want to go
ahead and remove it?
> 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.
>
Raymond and Luciano, you guys started work on this. Is this something
you feel could be ready over the next couple of weeks?
> 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).
>
For an alpha, I think this is fine.
> 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.
>
+1
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Rick Rineholt <cr...@gmail.com>.
Jeremy Boynes 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
+0
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
> 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 ?
>
Yeah, we'll need to distribute the spec jars. For OSOA JavaDoc, I
don't think we need it other than posting something to the web site
(the jar is small enough and doesn't contain any implementation). For
Kernel JavaDoc, I'd just assume we cut a source distribution which
people can use and have online JavaDoc (in addition to the binary
distributions).
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> +1 on the spec release criteria.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jim Marino" <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Monday, February 19, 2007 6:29 PM
> Subject: Re: Java Kernel Release
>
>
>>
>> On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote:
>>
>>> On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
>>>
>>>> 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 ?
>>>
>>> Yes, and I think we should have stricter release criteria for these
>>> as well. Specifically:
>>> +1 I have compared the candidate to the spec and have not found any
>>> discrepancy[1]
>>> +0 I have reviewed them but have not done a detailed comparison to
>>> the spec
>>> -1 I have compared the candidate to the spec and have found a
>>> discrepancy
>>>
>>> with any -1 being a veto.
>>>
>>> Thoughts?
>> +1 on the vote for spec release criteria
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
+1
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Raymond Feng <en...@gmail.com>.
+1 on the spec release criteria.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Monday, February 19, 2007 6:29 PM
Subject: Re: Java Kernel Release
>
> On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote:
>
>> On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
>>
>>> 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 ?
>>
>> Yes, and I think we should have stricter release criteria for these
>> as well. Specifically:
>> +1 I have compared the candidate to the spec and have not found any
>> discrepancy[1]
>> +0 I have reviewed them but have not done a detailed comparison to
>> the spec
>> -1 I have compared the candidate to the spec and have found a
>> discrepancy
>>
>> with any -1 being a veto.
>>
>> Thoughts?
> +1 on the vote for spec release criteria
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote:
> On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
>
>> 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 ?
>
> Yes, and I think we should have stricter release criteria for these
> as well. Specifically:
> +1 I have compared the candidate to the spec and have not found any
> discrepancy[1]
> +0 I have reviewed them but have not done a detailed comparison to
> the spec
> -1 I have compared the candidate to the spec and have found a
> discrepancy
>
> with any -1 being a veto.
>
> Thoughts?
+1 on the vote for spec release criteria
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jeremy Boynes <jb...@apache.org>.
The spec jar.
--
Jeremy
On Feb 19, 2007, at 4:37 PM, Raymond Feng wrote:
> Hi, Jeremy.
>
> Does your comment apply to the whole release or just the SCA spec jar?
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jeremy Boynes"
> <jb...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, February 19, 2007 4:32 PM
> Subject: Re: Java Kernel Release
>
>
>> On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
>>> 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 ?
>> Yes, and I think we should have stricter release criteria for
>> these as well. Specifically:
>> +1 I have compared the candidate to the spec and have not found
>> any discrepancy[1]
>> +0 I have reviewed them but have not done a detailed comparison
>> to the spec
>> -1 I have compared the candidate to the spec and have found a
>> discrepancy
>> with any -1 being a veto.
>> Thoughts?
>> --
>> Jeremy
>> [1] defining discrepancy the same way Sun do for signature
>> verification for API jars (i.e. nothing added, nothing removed)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Raymond Feng <en...@gmail.com>.
Hi, Jeremy.
Does your comment apply to the whole release or just the SCA spec jar?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, February 19, 2007 4:32 PM
Subject: Re: Java Kernel Release
> On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
>
>> 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 ?
>
> Yes, and I think we should have stricter release criteria for these
> as well. Specifically:
> +1 I have compared the candidate to the spec and have not found any
> discrepancy[1]
> +0 I have reviewed them but have not done a detailed comparison to
> the spec
> -1 I have compared the candidate to the spec and have found a
> discrepancy
>
> with any -1 being a veto.
>
> Thoughts?
> --
> Jeremy
>
> [1] defining discrepancy the same way Sun do for signature
> verification for API jars (i.e. nothing added, nothing removed)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
> 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 ?
Yes, and I think we should have stricter release criteria for these
as well. Specifically:
+1 I have compared the candidate to the spec and have not found any
discrepancy[1]
+0 I have reviewed them but have not done a detailed comparison to
the spec
-1 I have compared the candidate to the spec and have found a
discrepancy
with any -1 being a veto.
Thoughts?
--
Jeremy
[1] defining discrepancy the same way Sun do for signature
verification for API jars (i.e. nothing added, nothing removed)
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Luciano Resende <lu...@gmail.com>.
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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Java Kernel Release
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
>
> It's a simple question. There has been many changes in the SCA
> assembly model between 0.96 and 1.0, you are proposing a 1.0-alpha
> release of a Kernel supporting a subset of the 1.0 SCA assembly
> model. I'm simply asking "Which subset of 1.0?" to help all of us
> understand how to integrate the many other pieces of Tuscany with
> this, which scenarios we will be able to run, which integration
> tests can be developed etc.
>
>> Instead of having us compile a laundry list, which would be quite
>> extensive,
>
> Isn't there a middle ground between an extensive "laundry list" and
> an answer of the type "... SCA 1.0 - not all of it for sure but a
> baseline..."?
>
>> maybe you could list a few features you are interested in
>> including in the release (keeping in mind we are trying to release
>> sooner and staging larger functionality such as distribution for
>> subsequent releases)? We will have release doco describing the
>> features but it isn't complete yet
>
> Any doc, even incomplete, will help us understand the supported
> features. Are you developing that doc on our Wiki?
>
I planning to do it as part of the distributions. I'm sure we can
figure a way to post it to the wiki. In the meantime, I think there
is a ton of postings to the list which will help you understand which
features we have been working on and their status. Also, the unit
tests are all up-to-date. Sorry I don't have the doco finished but
will shortly as I've been tied up at work. Another option is if you
want to take a stab at compiling an initial list, it would help me
out a great deal given I have a bunch of other release-related items
to take care of.
>> and it sounds like you have a few specific things in mind.
>
> They are listed there: http://mail-archives.apache.org/mod_mbox/ws-
> tuscany-dev/200702.mbox/%3c45C7D7A2.8040102@apache.org%3e
Great! Which ones are you planning on getting into kernel? If you do
some of them over the next day or so we can include them in the
release. I'm not quite sure where you are at as there has been little
discussion on the list related to your plans.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Rick Rineholt <cr...@gmail.com>.
But if we have not done sufficient testing of the release that we feel
confident that users won't have to immediately wait for a new "release"
or go to snapshot what has it accomplished ?
Jim Marino wrote:
>
> On Feb 22, 2007, at 7:49 AM, Rick Rineholt wrote:
>
>> I was going with the scenario that the release was out. Given that
>> unlike past releases we've done where we had major number of bindings
>> running and samples running to give a level of confidence that there
>> was a fair amount that could be done with the release code that
>> wouldn't require updating I'm not seeing quite seeing the value of
>> "release" code verses just published snapshots following this approach.
>
> One of the values of the release is that it publishes a fixed SPI set
> for people to develop against and validate. SNAPSHOT serves a
> different purpose, to reflect the current status of HEAD, and as such
> is constantly moving.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 22, 2007, at 7:49 AM, Rick Rineholt wrote:
> I was going with the scenario that the release was out. Given that
> unlike past releases we've done where we had major number of
> bindings running and samples running to give a level of confidence
> that there was a fair amount that could be done with the release
> code that wouldn't require updating I'm not seeing quite seeing the
> value of "release" code verses just published snapshots following
> this approach.
One of the values of the release is that it publishes a fixed SPI set
for people to develop against and validate. SNAPSHOT serves a
different purpose, to reflect the current status of HEAD, and as such
is constantly moving.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Rick Rineholt <cr...@gmail.com>.
I was going with the scenario that the release was out. Given that
unlike past releases we've done where we had major number of bindings
running and samples running to give a level of confidence that there
was a fair amount that could be done with the release code that
wouldn't require updating I'm not seeing quite seeing the value of
"release" code verses just published snapshots following this approach.
Jim Marino wrote:
>
> On Feb 22, 2007, at 6:47 AM, Rick Rineholt wrote:
>
>> Jim Marino wrote:
>>>
>>> On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote:
>>>
>>>> I didn't see any mention what bindings are supported or have been
>>>> tested with this kernel release. In past we had several web
>>>> services, RMI all validating that the kernel and the SPIs. We also
>>>> had several implementation supported Java script, Ruby. It was my
>>>> experience that these really fleshed out a lot of issues and gave a
>>>> lot of confidences the kernel was working and could be used to
>>>> build upon by people wanted to build extensions.
>>>
>>> That's one of the goals of having the kernel release, to get
>>> feedback and validation on the SPI :-) Also, one of the goals of
>>> modularity as I understand it was to enable releases early and
>>> often, with kernel coming out before extensions. Otherwise, we will
>>> wind up in the unworkable situation we did with the past two
>>> milestones releases.
>>>
>>> In any event, the SPI for bindings has not significantly changed
>>> from M2. I suspect they will somewhat when we introduce full support
>>> for federation, put IMO it is important we get something out now to
>>> validate where we are.
>>>
>>> Jim
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>> If I start taking this kernel release and find issues what will be
>> the plan of action? Wait for the next release ? Goto the next
>> SNAPSHOT published driver?
>
> It depends on if the release has gone out. If not, then we need to
> consider if the fix is small enough to incorporate or should be pushed
> out to the next release. Assuming the release has gone out, there are
> two options, which are not exclusive: move to SNAPSHOT (not the 'next'
> snapshot as SNAPSHOT continually changes) or publish a new release.
> Now that we are trying to release early, release often, releases can
> be done at a very quick pace. Those of us working in trunk would like
> to avoid months-long release processes and hence our desire to start
> getting these releases out.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 22, 2007, at 6:47 AM, Rick Rineholt wrote:
> Jim Marino wrote:
>>
>> On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote:
>>
>>> I didn't see any mention what bindings are supported or have been
>>> tested with this kernel release. In past we had several web
>>> services, RMI all validating that the kernel and the SPIs. We
>>> also had several implementation supported Java script, Ruby. It
>>> was my experience that these really fleshed out a lot of issues
>>> and gave a lot of confidences the kernel was working and could be
>>> used to build upon by people wanted to build extensions.
>>
>> That's one of the goals of having the kernel release, to get
>> feedback and validation on the SPI :-) Also, one of the goals of
>> modularity as I understand it was to enable releases early and
>> often, with kernel coming out before extensions. Otherwise, we
>> will wind up in the unworkable situation we did with the past two
>> milestones releases.
>>
>> In any event, the SPI for bindings has not significantly changed
>> from M2. I suspect they will somewhat when we introduce full
>> support for federation, put IMO it is important we get something
>> out now to validate where we are.
>>
>> Jim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> If I start taking this kernel release and find issues what will be
> the plan of action? Wait for the next release ? Goto the next
> SNAPSHOT published driver?
It depends on if the release has gone out. If not, then we need to
consider if the fix is small enough to incorporate or should be
pushed out to the next release. Assuming the release has gone out,
there are two options, which are not exclusive: move to SNAPSHOT (not
the 'next' snapshot as SNAPSHOT continually changes) or publish a new
release. Now that we are trying to release early, release often,
releases can be done at a very quick pace. Those of us working in
trunk would like to avoid months-long release processes and hence our
desire to start getting these releases out.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Rick Rineholt <cr...@gmail.com>.
Jim Marino wrote:
>
> On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote:
>
>> I didn't see any mention what bindings are supported or have been
>> tested with this kernel release. In past we had several web services,
>> RMI all validating that the kernel and the SPIs. We also had several
>> implementation supported Java script, Ruby. It was my experience
>> that these really fleshed out a lot of issues and gave a lot of
>> confidences the kernel was working and could be used to build upon by
>> people wanted to build extensions.
>
> That's one of the goals of having the kernel release, to get feedback
> and validation on the SPI :-) Also, one of the goals of modularity as
> I understand it was to enable releases early and often, with kernel
> coming out before extensions. Otherwise, we will wind up in the
> unworkable situation we did with the past two milestones releases.
>
> In any event, the SPI for bindings has not significantly changed from
> M2. I suspect they will somewhat when we introduce full support for
> federation, put IMO it is important we get something out now to
> validate where we are.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
If I start taking this kernel release and find issues what will be the
plan of action? Wait for the next release ? Goto the next SNAPSHOT
published driver?
I think a release of something should signify the community confidence
in what is being released. My experience has been in past releases it
wasn't till we had major integration of binding extensions, alternative
component implementations and some reasonably more that hello world
scenarios driving the kernel that I felt confident it was worth
releasing. Curious, how others feel about that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote:
> I didn't see any mention what bindings are supported or have been
> tested with this kernel release. In past we had several web
> services, RMI all validating that the kernel and the SPIs. We also
> had several implementation supported Java script, Ruby. It was my
> experience that these really fleshed out a lot of issues and gave a
> lot of confidences the kernel was working and could be used to
> build upon by people wanted to build extensions.
That's one of the goals of having the kernel release, to get feedback
and validation on the SPI :-) Also, one of the goals of modularity as
I understand it was to enable releases early and often, with kernel
coming out before extensions. Otherwise, we will wind up in the
unworkable situation we did with the past two milestones releases.
In any event, the SPI for bindings has not significantly changed from
M2. I suspect they will somewhat when we introduce full support for
federation, put IMO it is important we get something out now to
validate where we are.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Rick Rineholt <cr...@gmail.com>.
I didn't see any mention what bindings are supported or have been tested
with this kernel release. In past we had several web services, RMI all
validating that the kernel and the SPIs. We also had several
implementation supported Java script, Ruby. It was my experience that
these really fleshed out a lot of issues and gave a lot of confidences
the kernel was working and could be used to build upon by people wanted
to build extensions.
Jim Marino wrote:
>
>> Any doc, even incomplete, will help us understand the supported
>> features. Are you developing that doc on our Wiki?
>>
>>>
>>
> O.K. I've just checked in a first cut of the release doc for kernel here:
>
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
>
> There will be other release docs for the runtimes (standalone, webapp,
> iTest). I'm sure I missed a bunch of things so if people could update
> the doc I would appreciate it.
>
>>
>>> I know those of us working on trunk would also appreciate it if you
>>> could volunteer some of your time to implement them as well.
>>>
>>> Jim
>>>
>>>
>>
>> I'd like to. I'm trying to work on some end to end scenarios first to
>> help put these features in context.
>>
> I've also checked in a sample that demonstrates SCA 1.0 conversational
> services and callbacks here:
>
> https://svn.apache.org/viewvc/incubator/tuscany/java/sca/core-samples/standalone/loanapplication/
>
>
> Do you have any other samples or suggestions you feel would be useful
> for the kernel release?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
> Any doc, even incomplete, will help us understand the supported
> features. Are you developing that doc on our Wiki?
>
>>
>
O.K. I've just checked in a first cut of the release doc for kernel
here:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
There will be other release docs for the runtimes (standalone,
webapp, iTest). I'm sure I missed a bunch of things so if people
could update the doc I would appreciate it.
>
>> I know those of us working on trunk would also appreciate it if
>> you could volunteer some of your time to implement them as well.
>>
>> Jim
>>
>>
>
> I'd like to. I'm trying to work on some end to end scenarios first
> to help put these features in context.
>
I've also checked in a sample that demonstrates SCA 1.0
conversational services and callbacks here:
https://svn.apache.org/viewvc/incubator/tuscany/java/sca/core-samples/
standalone/loanapplication/
Do you have any other samples or suggestions you feel would be useful
for the kernel release?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>>>>
>>>> I think it will be good to have a stable kernel. Which level of
>>>> SCDL and which features from the SCA assembly model are you
>>>> proposing to support in that kernel level?
>>>
>>> As it says, SCA 1.0 level - not all of it for sure but a baseline
>>> for itest, standalone and webapp environments.
>>> --Jeremy
>>>
>>>
>>
>> A baseline? Do you have an idea of which features from the SCA
>> assembly model? includes? nested composition? wiring across
>> composites? promotion of services? complex properties or not? which
>> databindings? any support for WSDL? any support for configured
>> implementations?
>>
>> --Jean-Sebastien
>
> Hi Sebastien,
>
> I'm not sure I completely follow your questions...
It's a simple question. There has been many changes in the SCA assembly
model between 0.96 and 1.0, you are proposing a 1.0-alpha release of a
Kernel supporting a subset of the 1.0 SCA assembly model. I'm simply
asking "Which subset of 1.0?" to help all of us understand how to
integrate the many other pieces of Tuscany with this, which scenarios we
will be able to run, which integration tests can be developed etc.
> Instead of having us compile a laundry list, which would be quite
> extensive,
Isn't there a middle ground between an extensive "laundry list" and an
answer of the type "... SCA 1.0 - not all of it for sure but a baseline..."?
> maybe you could list a few features you are interested in including in
> the release (keeping in mind we are trying to release sooner and
> staging larger functionality such as distribution for subsequent
> releases)? We will have release doco describing the features but it
> isn't complete yet
Any doc, even incomplete, will help us understand the supported
features. Are you developing that doc on our Wiki?
> and it sounds like you have a few specific things in mind.
They are listed there:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200702.mbox/%3c45C7D7A2.8040102@apache.org%3e
> I know those of us working on trunk would also appreciate it if you
> could volunteer some of your time to implement them as well.
>
> Jim
>
>
I'd like to. I'm trying to work on some end to end scenarios first to
help put these features in context.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
>>>
>>> I think it will be good to have a stable kernel. Which level of
>>> SCDL and which features from the SCA assembly model are you
>>> proposing to support in that kernel level?
>>
>> As it says, SCA 1.0 level - not all of it for sure but a baseline
>> for itest, standalone and webapp environments.
>> --
>> Jeremy
>>
>>
>
> A baseline? Do you have an idea of which features from the SCA
> assembly model? includes? nested composition? wiring across
> composites? promotion of services? complex properties or not? which
> databindings? any support for WSDL? any support for configured
> implementations?
>
> --
> Jean-Sebastien
Hi Sebastien,
I'm not sure I completely follow your questions...Instead of having
us compile a laundry list, which would be quite extensive, maybe you
could list a few features you are interested in including in the
release (keeping in mind we are trying to release sooner and staging
larger functionality such as distribution for subsequent releases)?
We will have release doco describing the features but it isn't
complete yet and it sounds like you have a few specific things in
mind. I know those of us working on trunk would also appreciate it if
you could volunteer some of your time to implement them as well.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> On Feb 20, 2007, at 1:02 PM, Jean-Sebastien Delfino wrote:
>
>> 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".
>>>
>>> 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
>>> 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?
>>>
>>> Jim
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>> I think it will be good to have a stable kernel. Which level of SCDL
>> and which features from the SCA assembly model are you proposing to
>> support in that kernel level?
>
> As it says, SCA 1.0 level - not all of it for sure but a baseline for
> itest, standalone and webapp environments.
> --
> Jeremy
>
>
A baseline? Do you have an idea of which features from the SCA assembly
model? includes? nested composition? wiring across composites? promotion
of services? complex properties or not? which databindings? any support
for WSDL? any support for configured implementations?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 20, 2007, at 1:02 PM, Jean-Sebastien Delfino wrote:
> 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".
>>
>> 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
>> 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?
>>
>> Jim
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> I think it will be good to have a stable kernel. Which level of
> SCDL and which features from the SCA assembly model are you
> proposing to support in that kernel level?
As it says, SCA 1.0 level - not all of it for sure but a baseline for
itest, standalone and webapp environments.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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".
>
> 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
> 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?
>
> Jim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I think it will be good to have a stable kernel. Which level of SCDL and
which features from the SCA assembly model are you proposing to support
in that kernel level?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java Kernel Release
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 19, 2007, at 3:06 PM, Meeraj Kunnumpurath wrote:
> Jim,
>
> I think, it is a good idea to a have a set of iterative alpha
> releases gearing towards a final 1.0 release.
>
> These are the features I see in the 1.0 final release ..
>
> 1. Full support for heterogeneous federation
> 2. Distributed assembly and deployment
> 3. Contribution mechanisms
> 4. Support for the 1.0 dpec changes
> 5. Standlone server and support for JMX-based management
> 6. The itest framework
> 7. And anything I have missed :)
>
+1. Sounds like a reasonable set of features.
> I think for the first alpha release, I would suggest we include
> spec 1.0 changes with ability to run with the laucher, itest and
> webapp runtimes. We need to discuss how we want to take the
> standalone server forward with JMX support. This may have some
> dependency on the federation stuff we have been working on. That
> means the standalone server with JMX and support for simple
> scenarios with federated deployment can go together in the second
> alpha release. We can plan for rest of the features in the next two
> releases or the ones after that.
Moving JMX out to the follow-on release sounds good based on the tie-
in with federation. Let's start a separate thread to discuss how we
want to evolve the JMX support.
>
> My view is to get the first alpha release out as early as we can
> with 1.0 programming model and support for laucher, webapp and
> itest runtimes.
>
+1
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Java Kernel Release
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Jim,
I think, it is a good idea to a have a set of iterative alpha releases
gearing towards a final 1.0 release.
These are the features I see in the 1.0 final release ..
1. Full support for heterogeneous federation
2. Distributed assembly and deployment
3. Contribution mechanisms
4. Support for the 1.0 dpec changes
5. Standlone server and support for JMX-based management
6. The itest framework
7. And anything I have missed :)
I think for the first alpha release, I would suggest we include spec 1.0
changes with ability to run with the laucher, itest and webapp runtimes. We
need to discuss how we want to take the standalone server forward with JMX
support. This may have some dependency on the federation stuff we have been
working on. That means the standalone server with JMX and support for simple
scenarios with federated deployment can go together in the second alpha
release. We can plan for rest of the features in the next two releases or
the ones after that.
My view is to get the first alpha release out as early as we can with 1.0
programming model and support for laucher, webapp and itest runtimes.
Ta
Meeraj
>From: Jim Marino <jm...@myromatours.com>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Java Kernel Release
>Date: Mon, 19 Feb 2007 09:45:38 -0800
>
>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".
>
>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
>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?
>
>Jim
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Upload 500 photos a month & blog with your Messenger buddies on Windows Live
Spaces. Get yours now, FREE! http://specials.uk.msn.com/spaces/default.aspx
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org