Found the spec directory - never mind!

-----Original Message-----
From: Hawkins, Joel [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 26, 2006 1:54 PM
To: tuscany-dev@ws.apache.org
Subject: SCA in OSGi - was SCA Spec Update and Recursive Core
presentation

Turn about is fair play - just got back from vacation myself - 6 days of
cycling in the Rockies. :-)

I think this approach will work well for me. I've done an update on the
sandbox code and am having troubles building. It appears that the
sca-api jar has been updated with some new classes
(org.osoa.sca.CompositeContext, for example), but the SNAPSHOT available
to Maven hasn't been. Am I catching the code in an in between state? Any
hints would be appreciated!

My goal for the week is to get the simple composite example working,
using the deployment you describe below. I'm sure I'll bump into lots of
sharp objects, which will generate lots of questions. Looking forward to
the journey.

Cheers,
Joel

-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 18, 2006 3:58 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Subject: SCA Spec Update and Recursive Core presentation

Sorry for the delay, I've been on vacation...
On Jun 13, 2006, at 6:54 AM, Hawkins, Joel wrote:

> Hi Jim,
>
> My personal interest is in SCA-OSGi integration. I listened to your
> presentation on the new core architecture, and am going through the
> sandbox code trying to gain some understanding of how it all hangs
> together. I'd really like to be involved in this area, and would
> appreciate any suggestions you can make.
>

That would be great. I checked in a skeleton OSGi project that uses  
Equinox. There are a number of items that we need to figure out,  
including:

- The details on OSGi as a host environment. I was thinking the root  
runtime context would be loaded in an OSGi and registered as an OSGi  
service. Application composites (e.g. applications contributed from  
end users) would be loaded as separate bundles and they would  
reference the SCA OSGi service to register themselves with the  
Tuscany runtime. Likewise, system composites would register  
themselves in a similar way.

-  Related to the first point, deployment structure. I'd like to see  
us figure out specifics concerning the deployment process such as run  
levels

- How to access OSGi services. I was thinking there would be an  
"OSGi" binding.

The easiest way to proceed may be for you to start posting questions  
as you work through looking at how the sandbox code works. Once we do  
that, we can move to specifics on how to integrate with OSGi. Does  
that work for you?

> I've got a separate thread going with Jervis around the management
> capabilities. We (the Corona team) are currently working on a WSDM
> interface for the OSGi runtime - I would hope that the lessons learned
> would be directly applicable to a WSDM interface for SCA.
>
O.K. that's great
> Thanks,
> Joel
>
>
> -----Original Message-----
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 12, 2006 4:38 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Subject: SCA Spec Update and Recursive Core presentation
>
> Hi Joel,
>
> Great.  Do you have some specific areas you are interested in working
> on w.r.t to Tuscany? I started a skeleton project of getting Tuscany
> to deploy into Equinox. Also, there has been a thread on providing
> management capabilities for Tuscany (Jervis I beleive was looking
> into this).  We can definitely use help in these areas as well as the
> other areas we outlined in the June 9 message from this same thread.
> Let me know and I can point you at things in more detail.
>
> Jim
>
>
>
> On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote:
>
>> Jim,
>>
>> My name is Joel Hawkins, and I'm working with the Apache Muse
>> project on
>> porting the IBM contribution for the new version of Muse to OSGi. I'm
>> also working on a recently formed Eclipse project (the Corona
>> project) -
>> which has a goal of providing a manageable (using Muse's WSDM
>> implementation) SCA-type environment (hopefully using Tuscany) for
>> Eclipse. I've been following the Tuscany project for some time, and
>> after sitting through the presentation of the latest spec update, I
>> believe SCA has a very important role to play in moving OSGi's
>> Declarative Services spec forward, and I'd be very interested in
>> helping
>> out in these areas.
>>
>> Cheers,
>> Joel Hawkins
>>
>> -----Original Message-----
>> From: Jim Marino [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, June 10, 2006 1:08 PM
>> To: tuscany-dev@ws.apache.org
>> Subject: Re: Subject: SCA Spec Update and Recursive Core presentation
>>
>> I also forgot one big area that needs work: Management.  This is a
>> topic that is starting to come up in the spec group and it would be
>> great if we could propose some ideas to them.
>>
>> Jim
>>
>> On Jun 9, 2006, at 2:48 PM, Jim Marino wrote:
>>
>>> Hi,
>>>
>>> Thanks everyone who attended today's call. The slides have been
>>> checked
>>> into SVN at:
>>>
>>> http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/
>>> doc
>>>
>>> We would appreciate any comments, questions, feedback, and
>>> suggestions
>>> on the session, and more importantly, the sandbox code at:
>>>
>>> http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/
>>>
>>> Most importantly, we would appreciate help from those interested.
>>> There are a bunch of areas in particular that need a lot of work,
>>> including:
>>>
>>> - Model loading. Jeremy is working on annotations and bootstrapping.
>>> - Spring support. Ken is moving this along.
>>> - Binding integration. I'm looking at getting the Celtix stuff
>>> working.
>>> Raymond is working on SDO integration.
>>> - Component implementation types. There is a start of a Groovy
>>> implementation donated by Meeraj which has partially been ported
>>> - Transport binding integration. I checked in the skeleton of an  
>>> HTTP
>>> Jetty transport.
>>> - Alternative host environments. I started a skeleton project for
>>> Equinox as a way to begin tackling OSGI deployment as well as the
>>> inevitable classloader problems we will encounter in restrictive
>>> container environments
>>> - Policy in general: transactions, security, etc.
>>> - Policy and wire optimization. I have started work here so please
>>> sync with me.
>>> - Less "fun" work includes Javadoc and testcases. Contributions
>>> building
>>> these areas out would be greatly appreciated; just knowing where we
>>> are
>>> lacking would be very valuable.
>>> - Integration test framework. We discussed having this in the past
>>> but not much work has been done.
>>>
>>> These are just the areas at the front of my mind. If you see other
>>> things you want to work on, jump on in.
>>>
>>> Jim
>>>
>>> --------------------------------------------------------------------

>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> The contents of this e-mail are intended for the named addressee
>> only. It contains information that may be confidential. Unless you
>> are the named addressee or an authorized designee, you may not copy
>> or use it, or disclose it to anyone else. If you received it in
>> error please notify us immediately and then destroy it.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> The contents of this e-mail are intended for the named addressee  
> only. It contains information that may be confidential. Unless you  
> are the named addressee or an authorized designee, you may not copy  
> or use it, or disclose it to anyone else. If you received it in  
> error please notify us immediately and then destroy it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it. 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to