You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/03/18 20:23:52 UTC
Project structure
One theme that came out of the recent project promotion thread was a
need to establish what our project structure should be. Part of that
also is the level of "support" between parts of that project structure.
I'd like to propose a strawman, not only of the structure but also of
the rules.
A project "core" that:
* is as small as possible with carefully controlled dependencies
* provides the fabric for the runtime (Contexts)
* provides APIs for providing plugin extensions
* provides SPIs for embedding in host environments
* can be built separately and used by extensions in binary form
(implying versioning and stability on the extension APIs)
* has a rule that incompatible changes to the API require the changer
to upgrade and test all extensions in the Tuscany project and with
a specific vote to accept them
Baseline services that are distributed with the core that:
* provide a deployment model for extensions (include loading,
context building, package handling (classpath))
* provide critical system services (monitoring, admin enablement)
* provide system services needed to support baseline extensions
(security provider, transaction manager, work manager, ...)
* has the same rule on API changes for those services as the core
Baseline extensions that are distributed with the core:
* programming models that are part of the specification
(currently Java, futures being C++, Spring, J2EE, BPEL, ...)
* transport bindings that are part of the specification
(currently WS, futures being JMS, ...)
* data bindings that are part of the specification
(currently SDO, futures being JAXB, ...)
* policy handlers that are part of the specification
(futures being Security, Transaction, ...)
Optional services that can be used to extend the runtime:
* programming models that are not part of the specification
(currently JavaScript, future being PHP, ???)
* transport bindings that are not part of the specification
(currently JSON-RPC, future being ???)
* data bindings that are not part of the specification
(currently JSON, future being ???)
* services for use by applications
(database access, DAS implementations, directory access, ...)
* these would be released separately and could be deployed
to a host environment by a user
Host integrations that provide installable distributions:
* provide implementations of the core's SPIs that allow
Tuscany to run in different environments.
(currently J2SE, J2EE WAR and Tomcat,
future being full J2EE, Geronimo, OSGi(Eclipse), ...)
* provide installable distributions that include all the
baseline compoments applicable to that environment
* provide "extended" distributions tailored to different
user communities that include selected optional services
Sample and demo applications that:
* show key concepts from the SCA programming model
(currently helloworld)
* show how to build a large scale application
(currently bigbank)
* show how to use Tuscany in different environments
Testing
* compliance test for the specification (when available)
* pre-release tests for Tuscany
* ALL modules above should test their own functionality
(at both the unit and integration levels) as part of their
own build. No manual setup should be required.
Given that, I would suggest the following changes to the project layout:
sca/
# "core" system
sca/system/common
sca/system/model
sca/system/core
# "baseline" services and extensions
sca/baseline/service/monitor
sca/baseline/service/security
sca/baseline/service/transaction
sca/baseline/service/work
sca/baseline/container/java
sca/baseline/transport/axis2
sca/baseline/data/sdo
sca/baseline/policy/security
# "optional" services and extensions
sca/extension/container/rhino
sca/extension/transport/jsonrpc
sca/extension/data/json
sca/extension/service/jndi
sca/extension/service/jdbc
# host environment integration
sca/host/tomcat/runtime # integration code
sca/host/tomcat/testing # integration testing
sca/host/tomcat/win32 # packaging for release
sca/host/j2se/runtime # etc...
# samples and testing modules that are not part of a developer build
sca/samples/helloworld/j2se
sca/samples/helloworld/war
sca/samples/bigbank
sca/testing/compliance
Thoughts?
--
Jeremy
Re: Project structure
Posted by ant elder <an...@gmail.com>.
On 3/18/06, Jeremy Boynes <jb...@apache.org> wrote:
<snip/>
> # samples and testing modules that are not part of a developer build
> sca/samples/helloworld/j2se
> sca/samples/helloworld/war
> sca/samples/bigbank
> sca/testing/compliance
Could you explain that part a bit more? Where do samples for contributed
extensions fit in and what if something other than helloworld and bigbank is
more appropriate for some extension? (I'm not suggesting this structure is
wrong, just trying to understand it)
Why are these not part of a developer build? If we're not building them
they'll break. The samples are the first thing new users will look at so
shouldn't we try to keep them always working?
...ant
Re: Project structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> Its still in SVN under sca/bindings, but its not part of the build, neither
> are helloworldaxis or helloworldaxissvc part of the build. All these haven't
> been part of the build since we moved up to Axis2. As it hasn't been part of
> the build binding.axis now fails if you try to build it.
>
> They'll be in SVN history and I'm not really convinced they have so much
> value now anyway...how about we delete them.
>
> ...ant
>
> On 3/29/06, Raymond Feng <en...@gmail.com> wrote:
>
>> There's a minor issue: the binding.axis is gone from the latest revision.
>> Is
>> it on purpose? It seems the "helloworldaxis" and "helloworldaxissvc" still
>> have dependencies on it.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "ant elder" <an...@gmail.com>
>> To: <tuscany-dev@ws.apache.org >
>> Sent: Wednesday, March 29, 2006 5:38 AM
>> Subject: Re: Project structure
>>
>>
>> Ok I've finished this move now and a clean checkout/build seems to work.
>>
>> ...ant
>>
>> On 3/28/06, ant elder < ant.elder@gmail.com> wrote:
>>
>>> Just a reminder I said I do this...will give it a shot tomorrow morning
>>> GMT.
>>>
>>> ...ant
>>>
>>>
>>> On 3/24/06, Jeremy Boynes < jboynes@apache.org> wrote:
>>>
>>>> ant elder wrote:
>>>>
>>>>> Can we turn this into a lazy consensus vote - if theres no -1s after
>>>>>
>>>> next
>>>>
>>>>> Tuesday I'll make the change.
>>>>>
>>>>> No one is particularly wedded to this structure, so if you'd rather
>>>>>
>> an
>>
>>>>> alternative post it. Its also not cast in stone, I don't see why we
>>>>>
>>>> can't
>>>>
>>>>> review it again in some months.
>>>>>
>>>>>
>>>> I'm +1 on the restructure.
>>>>
>>>> I think you may need to move the tomcat module into a separate tree as
>>>> well as it depends on the containers and bindings.
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>>
>>>
>>
>
>
+1 from me. We may want to resurrect the axis1 binding at some point
later maybe... if we ever run into blocking issues trying to communicate
with existing web services with Axis2 (but I'm not even sure about
that). I think we should focus on getting our Axis2 integration work
well, and we can always get old code back from the SVN history so I'm +1
for deleting them for now.
--
Jean-Sebastien
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Its still in SVN under sca/bindings, but its not part of the build, neither
are helloworldaxis or helloworldaxissvc part of the build. All these haven't
been part of the build since we moved up to Axis2. As it hasn't been part of
the build binding.axis now fails if you try to build it.
They'll be in SVN history and I'm not really convinced they have so much
value now anyway...how about we delete them.
...ant
On 3/29/06, Raymond Feng <en...@gmail.com> wrote:
>
> There's a minor issue: the binding.axis is gone from the latest revision.
> Is
> it on purpose? It seems the "helloworldaxis" and "helloworldaxissvc" still
> have dependencies on it.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "ant elder" <an...@gmail.com>
> To: <tuscany-dev@ws.apache.org >
> Sent: Wednesday, March 29, 2006 5:38 AM
> Subject: Re: Project structure
>
>
> Ok I've finished this move now and a clean checkout/build seems to work.
>
> ...ant
>
> On 3/28/06, ant elder < ant.elder@gmail.com> wrote:
> >
> > Just a reminder I said I do this...will give it a shot tomorrow morning
> > GMT.
> >
> > ...ant
> >
> >
> > On 3/24/06, Jeremy Boynes < jboynes@apache.org> wrote:
> > >
> > > ant elder wrote:
> > > > Can we turn this into a lazy consensus vote - if theres no -1s after
> > > next
> > > > Tuesday I'll make the change.
> > > >
> > > > No one is particularly wedded to this structure, so if you'd rather
> an
> > > > alternative post it. Its also not cast in stone, I don't see why we
> > > can't
> > > > review it again in some months.
> > > >
> > >
> > > I'm +1 on the restructure.
> > >
> > > I think you may need to move the tomcat module into a separate tree as
> > > well as it depends on the containers and bindings.
> > >
> > > --
> > > Jeremy
> > >
> >
> >
>
>
Re: Project structure
Posted by Raymond Feng <en...@gmail.com>.
There's a minor issue: the binding.axis is gone from the latest revision. Is
it on purpose? It seems the "helloworldaxis" and "helloworldaxissvc" still
have dependencies on it.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, March 29, 2006 5:38 AM
Subject: Re: Project structure
Ok I've finished this move now and a clean checkout/build seems to work.
...ant
On 3/28/06, ant elder <an...@gmail.com> wrote:
>
> Just a reminder I said I do this...will give it a shot tomorrow morning
> GMT.
>
> ...ant
>
>
> On 3/24/06, Jeremy Boynes < jboynes@apache.org> wrote:
> >
> > ant elder wrote:
> > > Can we turn this into a lazy consensus vote - if theres no -1s after
> > next
> > > Tuesday I'll make the change.
> > >
> > > No one is particularly wedded to this structure, so if you'd rather an
> > > alternative post it. Its also not cast in stone, I don't see why we
> > can't
> > > review it again in some months.
> > >
> >
> > I'm +1 on the restructure.
> >
> > I think you may need to move the tomcat module into a separate tree as
> > well as it depends on the containers and bindings.
> >
> > --
> > Jeremy
> >
>
>
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Ok I've finished this move now and a clean checkout/build seems to work.
...ant
On 3/28/06, ant elder <an...@gmail.com> wrote:
>
> Just a reminder I said I do this...will give it a shot tomorrow morning
> GMT.
>
> ...ant
>
>
> On 3/24/06, Jeremy Boynes < jboynes@apache.org> wrote:
> >
> > ant elder wrote:
> > > Can we turn this into a lazy consensus vote - if theres no -1s after
> > next
> > > Tuesday I'll make the change.
> > >
> > > No one is particularly wedded to this structure, so if you'd rather an
> > > alternative post it. Its also not cast in stone, I don't see why we
> > can't
> > > review it again in some months.
> > >
> >
> > I'm +1 on the restructure.
> >
> > I think you may need to move the tomcat module into a separate tree as
> > well as it depends on the containers and bindings.
> >
> > --
> > Jeremy
> >
>
>
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Just a reminder I said I do this...will give it a shot tomorrow morning GMT.
...ant
On 3/24/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> ant elder wrote:
> > Can we turn this into a lazy consensus vote - if theres no -1s after
> next
> > Tuesday I'll make the change.
> >
> > No one is particularly wedded to this structure, so if you'd rather an
> > alternative post it. Its also not cast in stone, I don't see why we
> can't
> > review it again in some months.
> >
>
> I'm +1 on the restructure.
>
> I think you may need to move the tomcat module into a separate tree as
> well as it depends on the containers and bindings.
>
> --
> Jeremy
>
Re: Project structure
Posted by Jeremy Boynes <jb...@apache.org>.
ant elder wrote:
> Can we turn this into a lazy consensus vote - if theres no -1s after next
> Tuesday I'll make the change.
>
> No one is particularly wedded to this structure, so if you'd rather an
> alternative post it. Its also not cast in stone, I don't see why we can't
> review it again in some months.
>
I'm +1 on the restructure.
I think you may need to move the tomcat module into a separate tree as
well as it depends on the containers and bindings.
--
Jeremy
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Can we turn this into a lazy consensus vote - if theres no -1s after next
Tuesday I'll make the change.
No one is particularly wedded to this structure, so if you'd rather an
alternative post it. Its also not cast in stone, I don't see why we can't
review it again in some months.
...ant
On 3/23/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > Are we any closer to deciding on this now? How about just keeping what
> we
> > have right now in SVN but adding bindings and containers folders to sca
> and
> > moving all the binding and container impls there (and the same for
> policys,
> > services, etc when we have some of those)?
> >
> > ...ant
> >
> Ant, +1 from me. This will keep things simple.
>
> > On 3/18/06, Jeremy Boynes <jb...@apache.org> wrote:
> >
> >> One theme that came out of the recent project promotion thread was a
> >> need to establish what our project structure should be. Part of that
> >> also is the level of "support" between parts of that project structure.
> >> I'd like to propose a strawman, not only of the structure but also of
> >> the rules.
> >>
> >> A project "core" that:
> >> * is as small as possible with carefully controlled dependencies
> >> * provides the fabric for the runtime (Contexts)
> >> * provides APIs for providing plugin extensions
> >> * provides SPIs for embedding in host environments
> >> * can be built separately and used by extensions in binary form
> >> (implying versioning and stability on the extension APIs)
> >> * has a rule that incompatible changes to the API require the changer
> >> to upgrade and test all extensions in the Tuscany project and with
> >> a specific vote to accept them
> >>
> >> Baseline services that are distributed with the core that:
> >> * provide a deployment model for extensions (include loading,
> >> context building, package handling (classpath))
> >> * provide critical system services (monitoring, admin enablement)
> >> * provide system services needed to support baseline extensions
> >> (security provider, transaction manager, work manager, ...)
> >> * has the same rule on API changes for those services as the core
> >>
> >> Baseline extensions that are distributed with the core:
> >> * programming models that are part of the specification
> >> (currently Java, futures being C++, Spring, J2EE, BPEL, ...)
> >> * transport bindings that are part of the specification
> >> (currently WS, futures being JMS, ...)
> >> * data bindings that are part of the specification
> >> (currently SDO, futures being JAXB, ...)
> >> * policy handlers that are part of the specification
> >> (futures being Security, Transaction, ...)
> >>
> >> Optional services that can be used to extend the runtime:
> >> * programming models that are not part of the specification
> >> (currently JavaScript, future being PHP, ???)
> >> * transport bindings that are not part of the specification
> >> (currently JSON-RPC, future being ???)
> >> * data bindings that are not part of the specification
> >> (currently JSON, future being ???)
> >> * services for use by applications
> >> (database access, DAS implementations, directory access, ...)
> >> * these would be released separately and could be deployed
> >> to a host environment by a user
> >>
> >> Host integrations that provide installable distributions:
> >> * provide implementations of the core's SPIs that allow
> >> Tuscany to run in different environments.
> >> (currently J2SE, J2EE WAR and Tomcat,
> >> future being full J2EE, Geronimo, OSGi(Eclipse), ...)
> >> * provide installable distributions that include all the
> >> baseline compoments applicable to that environment
> >> * provide "extended" distributions tailored to different
> >> user communities that include selected optional services
> >>
> >> Sample and demo applications that:
> >> * show key concepts from the SCA programming model
> >> (currently helloworld)
> >> * show how to build a large scale application
> >> (currently bigbank)
> >> * show how to use Tuscany in different environments
> >>
> >> Testing
> >> * compliance test for the specification (when available)
> >> * pre-release tests for Tuscany
> >> * ALL modules above should test their own functionality
> >> (at both the unit and integration levels) as part of their
> >> own build. No manual setup should be required.
> >>
> >>
> >> Given that, I would suggest the following changes to the project
> layout:
> >>
> >> sca/
> >> # "core" system
> >> sca/system/common
> >> sca/system/model
> >> sca/system/core
> >>
> >> # "baseline" services and extensions
> >> sca/baseline/service/monitor
> >> sca/baseline/service/security
> >> sca/baseline/service/transaction
> >> sca/baseline/service/work
> >> sca/baseline/container/java
> >> sca/baseline/transport/axis2
> >> sca/baseline/data/sdo
> >> sca/baseline/policy/security
> >>
> >> # "optional" services and extensions
> >> sca/extension/container/rhino
> >> sca/extension/transport/jsonrpc
> >> sca/extension/data/json
> >> sca/extension/service/jndi
> >> sca/extension/service/jdbc
> >>
> >> # host environment integration
> >> sca/host/tomcat/runtime # integration code
> >> sca/host/tomcat/testing # integration testing
> >> sca/host/tomcat/win32 # packaging for release
> >> sca/host/j2se/runtime # etc...
> >>
> >> # samples and testing modules that are not part of a developer build
> >> sca/samples/helloworld/j2se
> >> sca/samples/helloworld/war
> >> sca/samples/bigbank
> >> sca/testing/compliance
> >>
> >> Thoughts?
> >> --
> >> Jeremy
> >>
> >>
> >
> >
> --
> Jean-Sebastien
>
>
Re: Project structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> Are we any closer to deciding on this now? How about just keeping what we
> have right now in SVN but adding bindings and containers folders to sca and
> moving all the binding and container impls there (and the same for policys,
> services, etc when we have some of those)?
>
> ...ant
>
Ant, +1 from me. This will keep things simple.
> On 3/18/06, Jeremy Boynes <jb...@apache.org> wrote:
>
>> One theme that came out of the recent project promotion thread was a
>> need to establish what our project structure should be. Part of that
>> also is the level of "support" between parts of that project structure.
>> I'd like to propose a strawman, not only of the structure but also of
>> the rules.
>>
>> A project "core" that:
>> * is as small as possible with carefully controlled dependencies
>> * provides the fabric for the runtime (Contexts)
>> * provides APIs for providing plugin extensions
>> * provides SPIs for embedding in host environments
>> * can be built separately and used by extensions in binary form
>> (implying versioning and stability on the extension APIs)
>> * has a rule that incompatible changes to the API require the changer
>> to upgrade and test all extensions in the Tuscany project and with
>> a specific vote to accept them
>>
>> Baseline services that are distributed with the core that:
>> * provide a deployment model for extensions (include loading,
>> context building, package handling (classpath))
>> * provide critical system services (monitoring, admin enablement)
>> * provide system services needed to support baseline extensions
>> (security provider, transaction manager, work manager, ...)
>> * has the same rule on API changes for those services as the core
>>
>> Baseline extensions that are distributed with the core:
>> * programming models that are part of the specification
>> (currently Java, futures being C++, Spring, J2EE, BPEL, ...)
>> * transport bindings that are part of the specification
>> (currently WS, futures being JMS, ...)
>> * data bindings that are part of the specification
>> (currently SDO, futures being JAXB, ...)
>> * policy handlers that are part of the specification
>> (futures being Security, Transaction, ...)
>>
>> Optional services that can be used to extend the runtime:
>> * programming models that are not part of the specification
>> (currently JavaScript, future being PHP, ???)
>> * transport bindings that are not part of the specification
>> (currently JSON-RPC, future being ???)
>> * data bindings that are not part of the specification
>> (currently JSON, future being ???)
>> * services for use by applications
>> (database access, DAS implementations, directory access, ...)
>> * these would be released separately and could be deployed
>> to a host environment by a user
>>
>> Host integrations that provide installable distributions:
>> * provide implementations of the core's SPIs that allow
>> Tuscany to run in different environments.
>> (currently J2SE, J2EE WAR and Tomcat,
>> future being full J2EE, Geronimo, OSGi(Eclipse), ...)
>> * provide installable distributions that include all the
>> baseline compoments applicable to that environment
>> * provide "extended" distributions tailored to different
>> user communities that include selected optional services
>>
>> Sample and demo applications that:
>> * show key concepts from the SCA programming model
>> (currently helloworld)
>> * show how to build a large scale application
>> (currently bigbank)
>> * show how to use Tuscany in different environments
>>
>> Testing
>> * compliance test for the specification (when available)
>> * pre-release tests for Tuscany
>> * ALL modules above should test their own functionality
>> (at both the unit and integration levels) as part of their
>> own build. No manual setup should be required.
>>
>>
>> Given that, I would suggest the following changes to the project layout:
>>
>> sca/
>> # "core" system
>> sca/system/common
>> sca/system/model
>> sca/system/core
>>
>> # "baseline" services and extensions
>> sca/baseline/service/monitor
>> sca/baseline/service/security
>> sca/baseline/service/transaction
>> sca/baseline/service/work
>> sca/baseline/container/java
>> sca/baseline/transport/axis2
>> sca/baseline/data/sdo
>> sca/baseline/policy/security
>>
>> # "optional" services and extensions
>> sca/extension/container/rhino
>> sca/extension/transport/jsonrpc
>> sca/extension/data/json
>> sca/extension/service/jndi
>> sca/extension/service/jdbc
>>
>> # host environment integration
>> sca/host/tomcat/runtime # integration code
>> sca/host/tomcat/testing # integration testing
>> sca/host/tomcat/win32 # packaging for release
>> sca/host/j2se/runtime # etc...
>>
>> # samples and testing modules that are not part of a developer build
>> sca/samples/helloworld/j2se
>> sca/samples/helloworld/war
>> sca/samples/bigbank
>> sca/testing/compliance
>>
>> Thoughts?
>> --
>> Jeremy
>>
>>
>
>
--
Jean-Sebastien
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Are we any closer to deciding on this now? How about just keeping what we
have right now in SVN but adding bindings and containers folders to sca and
moving all the binding and container impls there (and the same for policys,
services, etc when we have some of those)?
...ant
On 3/18/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> One theme that came out of the recent project promotion thread was a
> need to establish what our project structure should be. Part of that
> also is the level of "support" between parts of that project structure.
> I'd like to propose a strawman, not only of the structure but also of
> the rules.
>
> A project "core" that:
> * is as small as possible with carefully controlled dependencies
> * provides the fabric for the runtime (Contexts)
> * provides APIs for providing plugin extensions
> * provides SPIs for embedding in host environments
> * can be built separately and used by extensions in binary form
> (implying versioning and stability on the extension APIs)
> * has a rule that incompatible changes to the API require the changer
> to upgrade and test all extensions in the Tuscany project and with
> a specific vote to accept them
>
> Baseline services that are distributed with the core that:
> * provide a deployment model for extensions (include loading,
> context building, package handling (classpath))
> * provide critical system services (monitoring, admin enablement)
> * provide system services needed to support baseline extensions
> (security provider, transaction manager, work manager, ...)
> * has the same rule on API changes for those services as the core
>
> Baseline extensions that are distributed with the core:
> * programming models that are part of the specification
> (currently Java, futures being C++, Spring, J2EE, BPEL, ...)
> * transport bindings that are part of the specification
> (currently WS, futures being JMS, ...)
> * data bindings that are part of the specification
> (currently SDO, futures being JAXB, ...)
> * policy handlers that are part of the specification
> (futures being Security, Transaction, ...)
>
> Optional services that can be used to extend the runtime:
> * programming models that are not part of the specification
> (currently JavaScript, future being PHP, ???)
> * transport bindings that are not part of the specification
> (currently JSON-RPC, future being ???)
> * data bindings that are not part of the specification
> (currently JSON, future being ???)
> * services for use by applications
> (database access, DAS implementations, directory access, ...)
> * these would be released separately and could be deployed
> to a host environment by a user
>
> Host integrations that provide installable distributions:
> * provide implementations of the core's SPIs that allow
> Tuscany to run in different environments.
> (currently J2SE, J2EE WAR and Tomcat,
> future being full J2EE, Geronimo, OSGi(Eclipse), ...)
> * provide installable distributions that include all the
> baseline compoments applicable to that environment
> * provide "extended" distributions tailored to different
> user communities that include selected optional services
>
> Sample and demo applications that:
> * show key concepts from the SCA programming model
> (currently helloworld)
> * show how to build a large scale application
> (currently bigbank)
> * show how to use Tuscany in different environments
>
> Testing
> * compliance test for the specification (when available)
> * pre-release tests for Tuscany
> * ALL modules above should test their own functionality
> (at both the unit and integration levels) as part of their
> own build. No manual setup should be required.
>
>
> Given that, I would suggest the following changes to the project layout:
>
> sca/
> # "core" system
> sca/system/common
> sca/system/model
> sca/system/core
>
> # "baseline" services and extensions
> sca/baseline/service/monitor
> sca/baseline/service/security
> sca/baseline/service/transaction
> sca/baseline/service/work
> sca/baseline/container/java
> sca/baseline/transport/axis2
> sca/baseline/data/sdo
> sca/baseline/policy/security
>
> # "optional" services and extensions
> sca/extension/container/rhino
> sca/extension/transport/jsonrpc
> sca/extension/data/json
> sca/extension/service/jndi
> sca/extension/service/jdbc
>
> # host environment integration
> sca/host/tomcat/runtime # integration code
> sca/host/tomcat/testing # integration testing
> sca/host/tomcat/win32 # packaging for release
> sca/host/j2se/runtime # etc...
>
> # samples and testing modules that are not part of a developer build
> sca/samples/helloworld/j2se
> sca/samples/helloworld/war
> sca/samples/bigbank
> sca/testing/compliance
>
> Thoughts?
> --
> Jeremy
>
Re: Project structure
Posted by Daniel Kulp <da...@iona.com>.
Jeremy,
> A project "core" that:
>........
> Baseline services that are distributed with the core that:
>........
> Baseline extensions that are distributed with the core:
> * programming models that are part of the specification
> (currently Java, futures being C++, Spring, J2EE, BPEL, ...)
How come you broke those sections up in the above part, but in the project
structure, you lumped them all together....
> # "baseline" services and extensions
> sca/baseline/service/monitor
> sca/baseline/service/security
> sca/baseline/service/transaction
> sca/baseline/service/work
> sca/baseline/container/java
> sca/baseline/transport/axis2
> sca/baseline/data/sdo
> sca/baseline/policy/security
Next question: where would something like my celtix transport/binding
thing go? I suppose into "optional", but it's really designed as a
replacement for the axis2 one. If we (Celtix folks) were to ship a
version of tuscany with our distribution, we probably wouldn't ship the
Axis stuff. Thus, does axis belong at the same level as the true "core"
services?
Mostly just throwing out some thoughts....
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: Project structure
Posted by ant elder <an...@gmail.com>.
Whats not completely clear from this is the 'rules', specifically when must
the 'optional' stuff be built? If code isn't being built in the regular
build that everyone runs it quickly goes stale. Look at our old Axis1
binding, been out of the regular build a couple of weeks and already it
fails to build.
I'd like to see everything being included in the regular build. If some
extension makes building difficult vote it out, don't exclude every
extension by default.
Is so much structure needed at this stage, or does it just makes things more
complicated and make an unnecessary decision now about how Tuscany must be
used. Maybe I just don't like the baseline vs extension distinction.
I'd go for a more simple hierarchy and leave the structuring to the
distributions. More like the way Mule or DOJO do things with various
distributions designed for specific environments - minimal, SCA-SPEC, J2EE,
the kitchen sink, etc. Perhaps with distributions customizable with a fancy
build script to add/remove things - "minimal,+JavaScript".
...ant
On 3/18/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> One theme that came out of the recent project promotion thread was a
> need to establish what our project structure should be. Part of that
> also is the level of "support" between parts of that project structure.
> I'd like to propose a strawman, not only of the structure but also of
> the rules.
>
> A project "core" that:
> * is as small as possible with carefully controlled dependencies
> * provides the fabric for the runtime (Contexts)
> * provides APIs for providing plugin extensions
> * provides SPIs for embedding in host environments
> * can be built separately and used by extensions in binary form
> (implying versioning and stability on the extension APIs)
> * has a rule that incompatible changes to the API require the changer
> to upgrade and test all extensions in the Tuscany project and with
> a specific vote to accept them
>
> Baseline services that are distributed with the core that:
> * provide a deployment model for extensions (include loading,
> context building, package handling (classpath))
> * provide critical system services (monitoring, admin enablement)
> * provide system services needed to support baseline extensions
> (security provider, transaction manager, work manager, ...)
> * has the same rule on API changes for those services as the core
>
> Baseline extensions that are distributed with the core:
> * programming models that are part of the specification
> (currently Java, futures being C++, Spring, J2EE, BPEL, ...)
> * transport bindings that are part of the specification
> (currently WS, futures being JMS, ...)
> * data bindings that are part of the specification
> (currently SDO, futures being JAXB, ...)
> * policy handlers that are part of the specification
> (futures being Security, Transaction, ...)
>
> Optional services that can be used to extend the runtime:
> * programming models that are not part of the specification
> (currently JavaScript, future being PHP, ???)
> * transport bindings that are not part of the specification
> (currently JSON-RPC, future being ???)
> * data bindings that are not part of the specification
> (currently JSON, future being ???)
> * services for use by applications
> (database access, DAS implementations, directory access, ...)
> * these would be released separately and could be deployed
> to a host environment by a user
>
> Host integrations that provide installable distributions:
> * provide implementations of the core's SPIs that allow
> Tuscany to run in different environments.
> (currently J2SE, J2EE WAR and Tomcat,
> future being full J2EE, Geronimo, OSGi(Eclipse), ...)
> * provide installable distributions that include all the
> baseline compoments applicable to that environment
> * provide "extended" distributions tailored to different
> user communities that include selected optional services
>
> Sample and demo applications that:
> * show key concepts from the SCA programming model
> (currently helloworld)
> * show how to build a large scale application
> (currently bigbank)
> * show how to use Tuscany in different environments
>
> Testing
> * compliance test for the specification (when available)
> * pre-release tests for Tuscany
> * ALL modules above should test their own functionality
> (at both the unit and integration levels) as part of their
> own build. No manual setup should be required.
>
>
> Given that, I would suggest the following changes to the project layout:
>
> sca/
> # "core" system
> sca/system/common
> sca/system/model
> sca/system/core
>
> # "baseline" services and extensions
> sca/baseline/service/monitor
> sca/baseline/service/security
> sca/baseline/service/transaction
> sca/baseline/service/work
> sca/baseline/container/java
> sca/baseline/transport/axis2
> sca/baseline/data/sdo
> sca/baseline/policy/security
>
> # "optional" services and extensions
> sca/extension/container/rhino
> sca/extension/transport/jsonrpc
> sca/extension/data/json
> sca/extension/service/jndi
> sca/extension/service/jdbc
>
> # host environment integration
> sca/host/tomcat/runtime # integration code
> sca/host/tomcat/testing # integration testing
> sca/host/tomcat/win32 # packaging for release
> sca/host/j2se/runtime # etc...
>
> # samples and testing modules that are not part of a developer build
> sca/samples/helloworld/j2se
> sca/samples/helloworld/war
> sca/samples/bigbank
> sca/testing/compliance
>
> Thoughts?
> --
> Jeremy
>