You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/11/11 11:11:42 UTC
[DISCUSS] Tuscany 2.0 themes?
We've agreed that we are going to develop OASIS compliant function in trunk.
I just started a discussion on what the starting point is. But what are the
themes for trunk up to the 2.0 release? What would we hope to be announcing
in the release notes that are going to get people excited? What are this
things that are going to make the code base easier to work with?
OASIS is clearly on the list. Ant's survey should help. But what else?
IMO this is not really about a detailed shopping list of code changes but
more about themes (as per the thread title), i.e. more the what than the
how.
Regards
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@gmail.com>.
On Wed, Nov 12, 2008 at 8:20 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Nov 11, 2008 at 10:23 PM, Raymond Feng <en...@gmail.com>wrote:
>
>> Interesting. I agree we are talking about some potential "big" features in
>> the 2.x development stream.
>>
>> On the other hand, is release 2.0 required to be super set of what we have
>> in 1.x? Does it have to include all the "big" themes we are proposing. IMO,
>> the themes can be delivered via one or more incremental 2.x releases. In
>> some cases, even one theme will deserve to have a release.
>>
>> Thanks,
>> Raymond
>>
>> From: Simon Laws
>> Sent: Tuesday, November 11, 2008 1:45 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: [DISCUSS] Tuscany 2.0 themes?
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>> Having themes with major releases is a good idea.
>>
>> Here are a few themes I have in mind:
>>
>> * OSGi enablement with clean SPI and modularity
>> * Consistent SCA domain story (deployment and management)
>> * QoS: Improved Policy Framework with transaction and security
>> * JEE/SCA integration
>>
>> Thanks,
>> Raymond
>>
>> From: Simon Laws
>> Sent: Tuesday, November 11, 2008 2:11 AM
>> To: tuscany-dev
>> Subject: [DISCUSS] Tuscany 2.0 themes?
>>
>>
>>
>> We've agreed that we are going to develop OASIS compliant function in
>> trunk. I just started a discussion on what the starting point is. But what
>> are the themes for trunk up to the 2.0 release? What would we hope to be
>> announcing in the release notes that are going to get people excited? What
>> are this things that are going to make the code base easier to work with?
>>
>> OASIS is clearly on the list. Ant's survey should help. But what else?
>>
>> IMO this is not really about a detailed shopping list of code changes but
>> more about themes (as per the thread title), i.e. more the what than the
>> how.
>>
>> Regards
>>
>> Simon
>>
>>
>> I was pinged off list about why I was suggesting an imminent 2.0 release.
>> I tried to pick my words quite carefully in starting this thread but
>> obviously not carefully enough. I'm not pushing any particular timescale for
>> a 2.0 release but simply suggesting that we work out what is on the roadmap
>> that takes us to 2.0. I would imagine that in order to get to 2.0 we will go
>> through a number of iterations and alpha/beta release. So what do we want to
>> do and what order do we need to do it in to get to 2.0 eventually is the
>> question on the table here;-)
>>
>> Simon
>>
>
> Oh dear. I seem to be struggling to convey a point here. I imagined a 2.0
> release out in the future some time that demonstrated OASIS compliance and a
> reasonable set of the improvements being described here. Maybe I should have
> called it 2.x as I don't mind if we get there through a sequence of releases
> such as
>
> 2.0 -> 2.1 -> 2.2 -> 2.3 -> 2.4 -> 2.5 etc
>
> or a sequence such as
>
> 2.0-M1 -> 2.0-M2 -> 2.0-M3 -> 2.0-Alpha -> 2.0-Beta -> 2.0
>
> I had actually imagined the latter but I don't really mind. What I would
> like to understand is what the steps are we think we need to go through in
> order to declare victory re. the pieces of work we agree on in this thread.
> Any clearer? The joy of the written word!
>
> Simon
>
>
>
I'd imagined this take some time and the later of those as well (2.0-M1 ->
2.0-M2 -> 2.0-M3 -> 2.0-Alpha -> 2.0-Beta -> 2.0). I don't think a 2.0 would
necessarily need to be a super set of what we have in 1.x or include every
one of the themes mentioned but it would be good to be at least a
significant subset.
The name "2.0" does make a statement, we'd make some noise about a 2.0
release and people would come have a look so we want them to be impressed.
Also, without adding some of the edge function we don't know that the core
is done yet, so for example, if we change/cleanup the SPIs i don't think we
should release that as 2.0 without first a period where they're 2.0-alpha to
get some experience with using them to validate that they're good.
...ant
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Raymond Feng <en...@gmail.com>.
Thanks for the clarification. The staging approach sounds good to me.
Raymond
From: Simon Laws
Sent: Wednesday, November 12, 2008 12:20 AM
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Tuscany 2.0 themes?
On Tue, Nov 11, 2008 at 10:23 PM, Raymond Feng <en...@gmail.com> wrote:
Interesting. I agree we are talking about some potential "big" features in
the 2.x development stream.
On the other hand, is release 2.0 required to be super set of what we have
in 1.x? Does it have to include all the "big" themes we are proposing. IMO,
the themes can be delivered via one or more incremental 2.x releases. In
some cases, even one theme will deserve to have a release.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, November 11, 2008 1:45 PM
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Tuscany 2.0 themes?
On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
Having themes with major releases is a good idea.
Here are a few themes I have in mind:
* OSGi enablement with clean SPI and modularity
* Consistent SCA domain story (deployment and management)
* QoS: Improved Policy Framework with transaction and security
* JEE/SCA integration
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, November 11, 2008 2:11 AM
To: tuscany-dev
Subject: [DISCUSS] Tuscany 2.0 themes?
We've agreed that we are going to develop OASIS compliant function in trunk.
I just started a discussion on what the starting point is. But what are the
themes for trunk up to the 2.0 release? What would we hope to be announcing
in the release notes that are going to get people excited? What are this
things that are going to make the code base easier to work with?
OASIS is clearly on the list. Ant's survey should help. But what else?
IMO this is not really about a detailed shopping list of code changes but
more about themes (as per the thread title), i.e. more the what than the
how.
Regards
Simon
I was pinged off list about why I was suggesting an imminent 2.0 release. I
tried to pick my words quite carefully in starting this thread but obviously
not carefully enough. I'm not pushing any particular timescale for a 2.0
release but simply suggesting that we work out what is on the roadmap that
takes us to 2.0. I would imagine that in order to get to 2.0 we will go
through a number of iterations and alpha/beta release. So what do we want to
do and what order do we need to do it in to get to 2.0 eventually is the
question on the table here;-)
Simon
Oh dear. I seem to be struggling to convey a point here. I imagined a 2.0
release out in the future some time that demonstrated OASIS compliance and a
reasonable set of the improvements being described here. Maybe I should have
called it 2.x as I don't mind if we get there through a sequence of releases
such as
2.0 -> 2.1 -> 2.2 -> 2.3 -> 2.4 -> 2.5 etc
or a sequence such as
2.0-M1 -> 2.0-M2 -> 2.0-M3 -> 2.0-Alpha -> 2.0-Beta -> 2.0
I had actually imagined the latter but I don't really mind. What I would
like to understand is what the steps are we think we need to go through in
order to declare victory re. the pieces of work we agree on in this thread.
Any clearer? The joy of the written word!
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Nov 11, 2008 at 10:23 PM, Raymond Feng <en...@gmail.com> wrote:
> Interesting. I agree we are talking about some potential "big" features in
> the 2.x development stream.
>
> On the other hand, is release 2.0 required to be super set of what we have
> in 1.x? Does it have to include all the "big" themes we are proposing. IMO,
> the themes can be delivered via one or more incremental 2.x releases. In
> some cases, even one theme will deserve to have a release.
>
> Thanks,
> Raymond
>
> From: Simon Laws
> Sent: Tuesday, November 11, 2008 1:45 PM
> To: dev@tuscany.apache.org
> Subject: Re: [DISCUSS] Tuscany 2.0 themes?
>
>
>
>
>
>
> On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Having themes with major releases is a good idea.
>
> Here are a few themes I have in mind:
>
> * OSGi enablement with clean SPI and modularity
> * Consistent SCA domain story (deployment and management)
> * QoS: Improved Policy Framework with transaction and security
> * JEE/SCA integration
>
> Thanks,
> Raymond
>
> From: Simon Laws
> Sent: Tuesday, November 11, 2008 2:11 AM
> To: tuscany-dev
> Subject: [DISCUSS] Tuscany 2.0 themes?
>
>
>
> We've agreed that we are going to develop OASIS compliant function in
> trunk. I just started a discussion on what the starting point is. But what
> are the themes for trunk up to the 2.0 release? What would we hope to be
> announcing in the release notes that are going to get people excited? What
> are this things that are going to make the code base easier to work with?
>
> OASIS is clearly on the list. Ant's survey should help. But what else?
>
> IMO this is not really about a detailed shopping list of code changes but
> more about themes (as per the thread title), i.e. more the what than the
> how.
>
> Regards
>
> Simon
>
>
> I was pinged off list about why I was suggesting an imminent 2.0 release. I
> tried to pick my words quite carefully in starting this thread but obviously
> not carefully enough. I'm not pushing any particular timescale for a 2.0
> release but simply suggesting that we work out what is on the roadmap that
> takes us to 2.0. I would imagine that in order to get to 2.0 we will go
> through a number of iterations and alpha/beta release. So what do we want to
> do and what order do we need to do it in to get to 2.0 eventually is the
> question on the table here;-)
>
> Simon
>
Oh dear. I seem to be struggling to convey a point here. I imagined a 2.0
release out in the future some time that demonstrated OASIS compliance and a
reasonable set of the improvements being described here. Maybe I should have
called it 2.x as I don't mind if we get there through a sequence of releases
such as
2.0 -> 2.1 -> 2.2 -> 2.3 -> 2.4 -> 2.5 etc
or a sequence such as
2.0-M1 -> 2.0-M2 -> 2.0-M3 -> 2.0-Alpha -> 2.0-Beta -> 2.0
I had actually imagined the latter but I don't really mind. What I would
like to understand is what the steps are we think we need to go through in
order to declare victory re. the pieces of work we agree on in this thread.
Any clearer? The joy of the written word!
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Raymond Feng <en...@gmail.com>.
Interesting. I agree we are talking about some potential "big" features in
the 2.x development stream.
On the other hand, is release 2.0 required to be super set of what we have
in 1.x? Does it have to include all the "big" themes we are proposing. IMO,
the themes can be delivered via one or more incremental 2.x releases. In
some cases, even one theme will deserve to have a release.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, November 11, 2008 1:45 PM
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Tuscany 2.0 themes?
On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
Having themes with major releases is a good idea.
Here are a few themes I have in mind:
* OSGi enablement with clean SPI and modularity
* Consistent SCA domain story (deployment and management)
* QoS: Improved Policy Framework with transaction and security
* JEE/SCA integration
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, November 11, 2008 2:11 AM
To: tuscany-dev
Subject: [DISCUSS] Tuscany 2.0 themes?
We've agreed that we are going to develop OASIS compliant function in trunk.
I just started a discussion on what the starting point is. But what are the
themes for trunk up to the 2.0 release? What would we hope to be announcing
in the release notes that are going to get people excited? What are this
things that are going to make the code base easier to work with?
OASIS is clearly on the list. Ant's survey should help. But what else?
IMO this is not really about a detailed shopping list of code changes but
more about themes (as per the thread title), i.e. more the what than the
how.
Regards
Simon
I was pinged off list about why I was suggesting an imminent 2.0 release. I
tried to pick my words quite carefully in starting this thread but obviously
not carefully enough. I'm not pushing any particular timescale for a 2.0
release but simply suggesting that we work out what is on the roadmap that
takes us to 2.0. I would imagine that in order to get to 2.0 we will go
through a number of iterations and alpha/beta release. So what do we want to
do and what order do we need to do it in to get to 2.0 eventually is the
question on the table here;-)
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
> Having themes with major releases is a good idea.
>
> Here are a few themes I have in mind:
>
> * OSGi enablement with clean SPI and modularity
> * Consistent SCA domain story (deployment and management)
> * QoS: Improved Policy Framework with transaction and security
> * JEE/SCA integration
>
> Thanks,
> Raymond
>
> From: Simon Laws
> Sent: Tuesday, November 11, 2008 2:11 AM
> To: tuscany-dev
> Subject: [DISCUSS] Tuscany 2.0 themes?
>
>
>
> We've agreed that we are going to develop OASIS compliant function in
> trunk. I just started a discussion on what the starting point is. But what
> are the themes for trunk up to the 2.0 release? What would we hope to be
> announcing in the release notes that are going to get people excited? What
> are this things that are going to make the code base easier to work with?
>
> OASIS is clearly on the list. Ant's survey should help. But what else?
>
> IMO this is not really about a detailed shopping list of code changes but
> more about themes (as per the thread title), i.e. more the what than the
> how.
>
> Regards
>
> Simon
>
I was pinged off list about why I was suggesting an imminent 2.0 release. I
tried to pick my words quite carefully in starting this thread but obviously
not carefully enough. I'm not pushing any particular timescale for a 2.0
release but simply suggesting that we work out what is on the roadmap that
takes us to 2.0. I would imagine that in order to get to 2.0 we will go
through a number of iterations and alpha/beta release. So what do we want to
do and what order do we need to do it in to get to 2.0 eventually is the
question on the table here;-)
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@gmail.com>.
On Tue, Nov 11, 2008 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
> Having themes with major releases is a good idea.
>
> Here are a few themes I have in mind:
>
> * OSGi enablement with clean SPI and modularity
> * Consistent SCA domain story (deployment and management)
Could you say a bit more about the type of things you're thinking
about with the SCA domain work? I think this would be good too but
without more detail not sure that we're thinking of the same things.
One thing I'd really like is to make our SCA domain to be a bit more
dynamic, we have had bits of work done towards that in the past and it
keeps on coming up again and again on the user list, most recently
yesterday [1].
...ant
[1] http://apache.markmail.org/message/ugbzhwbyqr5bsc3m
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Raymond Feng <en...@gmail.com>.
Having themes with major releases is a good idea.
Here are a few themes I have in mind:
* OSGi enablement with clean SPI and modularity
* Consistent SCA domain story (deployment and management)
* QoS: Improved Policy Framework with transaction and security
* JEE/SCA integration
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, November 11, 2008 2:11 AM
To: tuscany-dev
Subject: [DISCUSS] Tuscany 2.0 themes?
We've agreed that we are going to develop OASIS compliant function in trunk.
I just started a discussion on what the starting point is. But what are the
themes for trunk up to the 2.0 release? What would we hope to be announcing
in the release notes that are going to get people excited? What are this
things that are going to make the code base easier to work with?
OASIS is clearly on the list. Ant's survey should help. But what else?
IMO this is not really about a detailed shopping list of code changes but
more about themes (as per the thread title), i.e. more the what than the
how.
Regards
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Dan Becker <da...@gmail.com>.
I'm not a Visio user, but I am an OpenOffice user. I will take the task
of trying to read those and creating an OpenOffice template/stencil.
ant elder wrote:
> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com> wrote:
>
>> Personally I get frustrated when I read or make Tuscany demos or
>> presentations and the simple composites must be created with PaintShop or
>> some non-tech tool.
>>
>
> This may not be quite what you had in mind but a while back someone created
> an SCA diagram stencil for Visio [1], lots of people wont have Visio so
> maybe we should create a similar template for OpenOffice Draw and make that
> available on the Tuscany website so anyone can use it to create good looking
> pictures. (Disclaimer, i know little about OpenOffice Draw but googling it
> it does seem to have a stencil facility)
>
> ...ant
>
> [1]
> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>
--
Thanks, Dan Becker
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Nov 22, 2008 at 4:03 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Fri, Nov 21, 2008 at 11:35 AM, Raymond Feng <en...@gmail.com>
> wrote:
> > Hi,
> >
> > For stage 1, the distribution could be the core (or the pdetarget). I
> would
> > really rather stay in the core for JSE and OSGi than rushing to bring up
> > other pieces. We are trying to build a better foundation for the 2.x
> stream
> > now and I don't think we are settled to move into the bringup stage.
>
> +1 I think that having a better foundation to start will make our life
> much easier when bringing up the other pieces of the runtime,
> extensions, etc.
>
> >
> > Thanks,
> > Raymond
> >
> > From: ant elder
> > Sent: Friday, November 21, 2008 2:29 AM
> > To: Simon Laws
> > Cc: dev@tuscany.apache.org
> > Subject: Re: [DISCUSS] Tuscany 2.0 themes?
> >
> > [[snip]]
> >
> > I agree there should be some "distribution" items on the stage 1 list.
> I'd
> > also like to bring up sooner rather than later the various runtime
> options -
> > so j2se and webapps along with equinox.
> >
> > ...ant
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
In the gaps today I've been going through the minimum set of 2.x modules
using Ramymond's comments [1] to understand changes and making notes about
areas that may need more attention before we start pulling in everything
else. Here are my raw notes from today so I don't loose them. More later.
General
======
Minimum and simplest set of dependendencies
use asm (remove cglib) - TUSCANY-2359
still lots of impls being exported
get the right things in contrib
Get rid of warnings where possible
Builder Tidy
Endpoint
RRB
Policy
Run with security enabled to see how we stand
Look for all TODO/FIXME in the code and review
Review JIRA to see what needs to be addressed in 2.x
Try and avoid packages appearing in unexpected places. Core package in
extensibility for example
Test structure
How should unit tests operation
Sample structure
How should samples operate
Distribution
Runtime options.
Let's understand (and document) our minimum runtime useage scenarios, for
example, I'd like to know this kind of thing
Command line
java -jar domain.jar
java -jar node.jar
Starting node adds it to the domain
URL info?
java -jar node.jar composite contribution
java -jar node.jar configurURL
java -jar node.jar debug
prod the node from a simple command prompt, force tracing on, etc?
Eclipse
Right clink on composite file to run
Right click on multiple composite files causes them to be stared in the
same domain?
Webapp
Drop web app into container with
Generally bundles seem to import their own packages. Why?
What is the SPI?
Java doc for these minimal modules + Explicit SPI
Module Specific Comments
------------------------
[INFO] Apache Tuscany SCA Extensibility ...................... SUCCESS
[0.000s]
Module Activator - What dictates using this rather than specific extension
point
Why are there o.a.t.s.core packages here? Change the package or change the
module
Imports itself and core????
Remove dependency on equinox extensibility. Will have to find a way of
having the
the equinox module register with the extensibility package.
[INFO] Apache Tuscany SCA Policy Model ....................... SUCCESS
[3.375s]
Needs reorg
[INFO] Apache Tuscany SCA Interface Model .................... SUCCESS
[1.110s]
[INFO] Apache Tuscany SCA Assembly Model XML Schemas ......... SUCCESS
[0.015s]
All the schema being in one place seems inconsistent
[INFO] Apache Tuscany SCA Definitions ........................ SUCCESS
[1.094s]
Seems OK
[INFO] Apache Tuscany SCA Monitor ............................ SUCCESS
[0.016s]
Seems OK
[INFO] Apache Tuscany SCA Assembly Model ..................... SUCCESS
[3.250s]
Imports itself?
Exports Impls. Presumably so that core can extend
Separate module for builders, especially now they are an extension point.
We do
have users who change the builders.
[INFO] Apache Tuscany SCA Contribution Model ................. SUCCESS
[1.484s]
Classloaders?
get rid of service package
[INFO] Apache Tuscany SCA API ................................ SUCCESS
[0.016s]
need OASIS versions
[INFO] Apache Tuscany SCA Core SPI ........................... SUCCESS
[2.297s]
How do we understand what constitutes the Tuscany SPI.
[INFO] Apache Tuscany SCA Namespace Import/Export Model ...... SUCCESS
[1.187s]
[INFO] Apache Tuscany SCA Java Import/Export Model ........... SUCCESS
[0.031s]
[INFO] Apache Tuscany SCA Policy XML Model ................... SUCCESS
[0.016s]
[INFO] Apache Tuscany SCA Definitions XML Model .............. SUCCESS
[1.172s]
[INFO] Apache Tuscany SCA XML Assembly Model ................. SUCCESS
[3.281s]
[INFO] Apache Tuscany SCA Java Interface Model ............... SUCCESS
[0.016s]
[INFO] Apache Tuscany SCA Core Runtime ....................... SUCCESS
[1.187s]
Doesn't actually export o.a.t.s.core but extensibility does
Move activator into it's own package
Wire -> EndpointWire
Refine Endpoint vs EndpointReference
Runtime component, references and services extend assembly
implementations
Why not just put them in assembly
Invocation seems like a funny set of stuff when the RuntimeWire itself is
in assembly
Scope needs work. Request scope is going I believe
org.apache.tuscany.sca.core.ModuleActivatorExtensionPoint used 3 modules.
Shouldn't this be done using normal extension points now
DataBindingModuleActivator
JavaImplementationModuleActivator
JavaRuntimeModulesActivator
[INFO] Apache Tuscany SCA Default Binding Model .............. SUCCESS
[2.266s]
Remote binding decision plug point
[INFO] Apache Tuscany SCA Default Binding XML Model .......... SUCCESS
[1.328s]
[INFO] Apache Tuscany SCA XML Contribution Model ............. SUCCESS
[0.016s]
Why is the processor.xml stuff here different from that in contribution
[INFO] Apache Tuscany SCA XSD Model .......................... SUCCESS
[0.093s]
[INFO] Apache Tuscany SCA DataBinding Framework .............. SUCCESS
[1.141s]
[INFO] Apache Tuscany SCA Data Binding for JAXB .............. SUCCESS
[1.828s]
[INFO] Apache Tuscany SCA Java Interface XML Model ........... SUCCESS
[0.031s]
[INFO] Apache Tuscany Java Interface for JAXWS ............... SUCCESS
[6.688s]
[INFO] Apache Tuscany SCA Core/DataBinding Integration ....... SUCCESS
[1.125s]
[INFO] Apache Tuscany SCA Domain Workspace Model ............. SUCCESS
[0.016s]
Why is this called domain and not contribution. The workspace
is used in the node now as well as in the domain
[INFO] Apache Tuscany SCA Domain Workspace XML Model ......... SUCCESS
[1.078s]
[INFO] Apache Tuscany SCA Domain Workspace Implementation .... SUCCESS
[2.265s]
[INFO] Apache Tuscany SCA Java Implementation Model .......... SUCCESS
[0.032s]
[INFO] Apache Tuscany SCA Java Implementation XML Model ...... SUCCESS
[1.140s]
[INFO] Apache Tuscany SCA Default Endpoint Implementation .... SUCCESS
[2.094s]
Needs work
[INFO] Apache Tuscany SCA Extensibility for Eclipse Equinox .. SUCCESS
[5.312s]
Has DynamicImport-Package: *
[INFO] Apache Tuscany SCA Java Implementation Model .......... SUCCESS
[0.047s]
[INFO] Apache Tuscany SCA Node Implementation Model .......... SUCCESS
[1.282s]
I find this confusing so would like to discuss
In paricular the runtime part vs just straighforward node modules as
control
seems to switch backward and forward between the two. I appreciate the
desire
to have a pluggable node implementation in some sense but having it
called
implementation doesn't IMO make things clearer. Anyhow a topic for
discussion
[INFO] Apache Tuscany SCA Node API ........................... SUCCESS
[0.000s]
[INFO] Apache Tuscany SCA Node Launcher ...................... SUCCESS
[0.015s]
No suggesting all theseUnderstand the range of start up options, e.g
[INFO] Apache Tuscany SCA Node Implementation ................ SUCCESS
[5.797s]
Policy resolution - currently commented out
[INFO] Apache Tuscany SCA Node Implementation Extension ...... SUCCESS
[3.500s]
[INFO] Apache Tuscany SCA Node Equinox OSGi Launcher ......... SUCCESS
[4.609s]
[INFO] Apache Tuscany Security Policy Model .................. SUCCESS
[0.032s]
Needs tidying - think about separation of model and implementation
I have puts some of both in here previously
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Equinox+Branch+Merge
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Nov 21, 2008 at 11:35 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> For stage 1, the distribution could be the core (or the pdetarget). I would
> really rather stay in the core for JSE and OSGi than rushing to bring up
> other pieces. We are trying to build a better foundation for the 2.x stream
> now and I don't think we are settled to move into the bringup stage.
+1 I think that having a better foundation to start will make our life
much easier when bringing up the other pieces of the runtime,
extensions, etc.
>
> Thanks,
> Raymond
>
> From: ant elder
> Sent: Friday, November 21, 2008 2:29 AM
> To: Simon Laws
> Cc: dev@tuscany.apache.org
> Subject: Re: [DISCUSS] Tuscany 2.0 themes?
>
> [[snip]]
>
> I agree there should be some "distribution" items on the stage 1 list. I'd
> also like to bring up sooner rather than later the various runtime options -
> so j2se and webapps along with equinox.
>
> ...ant
>
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Raymond Feng <en...@gmail.com>.
Hi,
For stage 1, the distribution could be the core (or the pdetarget). I would
really rather stay in the core for JSE and OSGi than rushing to bring up
other pieces. We are trying to build a better foundation for the 2.x stream
now and I don't think we are settled to move into the bringup stage.
Thanks,
Raymond
From: ant elder
Sent: Friday, November 21, 2008 2:29 AM
To: Simon Laws
Cc: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Tuscany 2.0 themes?
[[snip]]
I agree there should be some "distribution" items on the stage 1 list. I'd
also like to bring up sooner rather than later the various runtime options -
so j2se and webapps along with equinox.
...ant
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@apache.org>.
On Thu, Nov 20, 2008 at 4:00 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Nov 14, 2008 at 5:32 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Nov 13, 2008 at 11:39 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Nov 13, 2008 at 11:14 AM, ant elder <an...@apache.org> wrote:
>>>
>>>> On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <dan.o.becker@gmail.com
>>>> >
>>>> >> wrote:
>>>> >>
>>>> >> <snip>
>>>> >>
>>>> >>
>>>> >>>
>>>> >>> Personally I get frustrated when I read or make Tuscany demos or
>>>> >>> presentations and the simple composites must be created with
>>>> PaintShop or
>>>> >>> some non-tech tool.
>>>> >>
>>>> >> This may not be quite what you had in mind but a while back someone
>>>> >> created an SCA diagram stencil for Visio [1], lots of people wont
>>>> have Visio
>>>> >> so maybe we should create a similar template for OpenOffice Draw and
>>>> make
>>>> >> that available on the Tuscany website so anyone can use it to create
>>>> good
>>>> >> looking pictures. (Disclaimer, i know little about OpenOffice Draw
>>>> but
>>>> >> googling it it does seem to have a stencil facility)
>>>> >>
>>>> >> ...ant
>>>> >>
>>>> >> [1]
>>>> >>
>>>> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>>>> >>
>>>> >
>>>> > I'm interested in consumability and ease of use. I've tried to extract
>>>> a few
>>>> > things from my mental list that I think have an impact...
>>>> >
>>>> > For the user
>>>> > Documentation
>>>> > Complete extension documentation
>>>> > Document common tasks +1 Ram's suggestion of document/sample
>>>> alignment.
>>>> > Also share README content with website
>>>> > Distribution
>>>> > Separation of core from extensions
>>>> > Smaller total number of jars and remove all jar
>>>> > Have an obvious first steps thread in the distro
>>>> > Development
>>>> > Improve policy story
>>>> > Deployment
>>>> > * Clear hosting/deployment options with samples
>>>> > Clarify/Simplify domain story
>>>> > Management
>>>> > Debug
>>>> > Restructure validation itests and index from messages
>>>> > Improve tracing and document how to exploit
>>>> > Runtime model dump
>>>> >
>>>> > For the developer
>>>> > Development
>>>> > * Review SPI, clean and document
>>>> > * Modularity (there has been much discussion already)
>>>> > * Remove IOC nature of runtime construction
>>>> > * Builders structure
>>>> > * Contribution processing structure
>>>> > Build
>>>> > Speed it up
>>>> > * Structure. I'd like to separate core from extensions and
>>>> disitributed
>>>> > content from content in development
>>>> > * Build/test with the distribution structure
>>>> > Release
>>>> > Need to simplify and make it easily repeatable
>>>> >
>>>> > * marks the things I think have to be at least considered (but not
>>>> > necessarily completed) at trunk bring up. Everything else builds on
>>>> this.
>>>> >
>>>> > Simon
>>>> >
>>>>
>>>> Those all sound good.
>>>>
>>>> With "Remove IOC nature of runtime construction", thats not something
>>>> I recall coming up before so could you say a bit more about that?
>>>
>>>
>>> At the moment the runtime builder injects specific resolvers, factories
>>> etc into the various runtime components. In nine times out of ten it just
>>> gets them from the extension registry so I would like to remove the majority
>>> of the runtime builder code and let each function do it itself given the
>>> registry. If we need to allow access to some new extension in the future
>>> then that doesn't involve rewriting layers of constructors.
>>>
>>> I appreciate the benefit from IOC generally but in this case I don't
>>> think its adding anything.
>>>
>>>
>>>>
>>>>
>>>> The items under "Build" seem good too, i think the easiest way to make
>>>> the build significantly faster will be a reorg like you describe.
>>>> Would things like itests, vtests, samples be moved to be within
>>>> separate folders under the extension they relate to? I think that
>>>> might be good, is it what you had in mind - so for example all the
>>>> webservice things be moved to be under the webservice extension
>>>> folder?
>>>
>>>
>>> Actually I hadn't thought that far. But I like the though that we could
>>> make extensions more modular to include Itest, vtest etc. This also ties up
>>> with Ram's thoughts about tieing it all closer to documentation on the web
>>> site also.
>>>
>>>>
>>>>
>>>> Under "Distribution" there is "Smaller total number of jars", thats
>>>> come up a number of times from users, for example, a comment saying
>>>> the calculator2 sample which uses the aggregate jars prototype is
>>>> easier to understand, and the discussion on using JDK6 would also help
>>>> with this. Not sure how we're going to decide what the themes to focus
>>>> on are but I think this would be a good one to do, and if we end up
>>>> with multiple distribution having an extra one using aggregated jars
>>>> seems like it could be a harmless and useful option along with all the
>>>> other distributions.
>>>
>>>
>>> Agreed.
>>>
>>> Re. deciding on themes. I think we're getting to the stage where all the
>>> ideas so far can be summarized and someone can make a proposal on
>>>
>>> 1. A high level set of themes
>>> 2. If there is any natural order that these things have to flow in
>>>
>>> If none else gets to it I'll have a go later today. I have a few other
>>> things to ge through first.
>>>
>>> I imagine there will be debate about the "how" of some of these items.
>>> But that is different from agreeing that items need addressing.
>>>
>>>
>>>>
>>>> ...ant
>>>>
>>>
>>>
>> Conversation here has died down so I'd like to close this out. Here is a
>> summary of the ideas that have been put forward. Apologies if I missed any.
>> I took the liberty of organizing in the rather arbitrary categories from my
>> post. I've had a go a marking those items that need to get done to get
>> through the stage 1 that has been proposed where we bring up the minimum
>> number of modules to define the base code and best practice for bringing up
>> the large number of other modules. Just my view so your view may differ.
>> Comments please.
>>
>> I would be very surprised if we don't think of more things for Stage2 as
>> we go through Stage1. That's fine. People will be drawn to the things they
>> really want to see fixed. I guess after we've discussed a bit we can put
>> this list up on a wiki page for future reference. I imagine that each
>> individual item will get a thread of its own at the appropriate time.
>>
>>
>> Stage 1 - minimal bring up
>> Stage 2 - bring up to 1.x level of function
>>
>> I've marked 1 and everthing else is 2.
>>
>> For the user
>> consumability
>> honing the user experience - probably overlaps with lots of these
>> things
>> Documentation
>> Complete extension documentation
>> Document common tasks +1 Ram's suggestion of document/sample
>> alignment. Also share README content with website
>> documentation improved to include patterns and better links to info
>> in samples
>> Set of docs specifically for 2.0
>> Documentatin for official SPIs/APIs
>> Make complete docs a condition of 2.0 release
>> Distribution
>> Separation of core from extensions
>> Smaller total number of jars and remove all jar
>> Have an obvious first steps thread in the distro
>> Re-organized samples and itests
>> top notch demos and presentations
>> Development
>> OASIS spec support
>> OSOA spec suport
>> promoting graphical tools and syntax assist tools to work with
>> Tuscany
>> tooling integration?
>> Deployment
>> Clear hosting/deployment options with samples
>> 1 Start with just node and and get rid on host-embedded for now -
>> rethink embedding, launching etc.
>> Clarify/Simplify/Consistent SCA domain story (deployment and
>> management)
>> Make our SCA domain to be a bit more dynamic
>> QoS: Improved Policy Framework with transaction and security
>> Management
>> JEE/SCA integration.
>> Improved JEE/Webapp support
>> Work well with domain
>> Complete wiring support
>> Have good test framework testing all extensions in this
>> environment
>> Support some standard web frameworks
>> Debug
>> Restructure validation itests and index from messages
>> Improve tracing and document how to exploit
>> Runtime model dump
>>
>> For the developer
>> Development
>> 1 Review SPI, clean and document
>> 1 Modularity (there has been much discussion already) / OSGI
>> enablement
>> 1 Remove IOC nature of runtime construction
>> 1 Builders structure
>> 1 Contribution processing structure
>> Build
>> Find a way to make the build easier.
>> Single Jar with JDK 6
>> Speed it up
>> 1 Structure. I'd like to separate core from extensions and disitributed
>> content from content in development (contrib)
>> 1 Build/test with the distribution structure
>> Release
>> Need to simplify and make it easily repeatable
>>
>> Regards
>>
>> Simon
>>
>
> So it's time we got back on here. We've made a start on Stage1 in that the
> minimum set of modules is up an running just about. What are the things we
> need/want to do before we start on the wider themes. In summary this was the
> list we captured from this thread.
>
> 1 Start with just node and and get rid on host-embedded for now -
> rethink embedding, launching etc.
> Looks like host-embedded has gone in the node rework in the equinox
> branch so we need to review that
> 1 Review SPI, clean and document
> 1 Modularity (there has been much discussion already) / OSGI enablement
> 1 Remove IOC nature of runtime construction
> 1 Builders structure
> 1 Contribution processing structure
> 1 Structure. I'd like to separate core from extensions and disitributed
> content from content in development (contrib)
> 1 Build/test with the distribution structure
>
> A) Are the things that should be added/removed
> B) who is going to do what.
>
> I would probably add to this list some of the "distribution" items to this
> stage 1 list. There has been a reorg in the equinox branch and we should
> review that.
>
> I'm going to ease myself in gently by looking at the builder extension
> point and doing some tidying there. Not a particularly high priority but a
> chance to get a feel for the changes in the code.
>
> Simon
>
I agree there should be some "distribution" items on the stage 1 list. I'd
also like to bring up sooner rather than later the various runtime options -
so j2se and webapps along with equinox.
...ant
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Nov 14, 2008 at 5:32 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Nov 13, 2008 at 11:39 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Nov 13, 2008 at 11:14 AM, ant elder <an...@apache.org> wrote:
>>
>>> On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>> >
>>> >
>>> > On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com>
>>> wrote:
>>> >>
>>> >>
>>> >> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> <snip>
>>> >>
>>> >>
>>> >>>
>>> >>> Personally I get frustrated when I read or make Tuscany demos or
>>> >>> presentations and the simple composites must be created with
>>> PaintShop or
>>> >>> some non-tech tool.
>>> >>
>>> >> This may not be quite what you had in mind but a while back someone
>>> >> created an SCA diagram stencil for Visio [1], lots of people wont have
>>> Visio
>>> >> so maybe we should create a similar template for OpenOffice Draw and
>>> make
>>> >> that available on the Tuscany website so anyone can use it to create
>>> good
>>> >> looking pictures. (Disclaimer, i know little about OpenOffice Draw but
>>> >> googling it it does seem to have a stencil facility)
>>> >>
>>> >> ...ant
>>> >>
>>> >> [1]
>>> >>
>>> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>>> >>
>>> >
>>> > I'm interested in consumability and ease of use. I've tried to extract
>>> a few
>>> > things from my mental list that I think have an impact...
>>> >
>>> > For the user
>>> > Documentation
>>> > Complete extension documentation
>>> > Document common tasks +1 Ram's suggestion of document/sample
>>> alignment.
>>> > Also share README content with website
>>> > Distribution
>>> > Separation of core from extensions
>>> > Smaller total number of jars and remove all jar
>>> > Have an obvious first steps thread in the distro
>>> > Development
>>> > Improve policy story
>>> > Deployment
>>> > * Clear hosting/deployment options with samples
>>> > Clarify/Simplify domain story
>>> > Management
>>> > Debug
>>> > Restructure validation itests and index from messages
>>> > Improve tracing and document how to exploit
>>> > Runtime model dump
>>> >
>>> > For the developer
>>> > Development
>>> > * Review SPI, clean and document
>>> > * Modularity (there has been much discussion already)
>>> > * Remove IOC nature of runtime construction
>>> > * Builders structure
>>> > * Contribution processing structure
>>> > Build
>>> > Speed it up
>>> > * Structure. I'd like to separate core from extensions and
>>> disitributed
>>> > content from content in development
>>> > * Build/test with the distribution structure
>>> > Release
>>> > Need to simplify and make it easily repeatable
>>> >
>>> > * marks the things I think have to be at least considered (but not
>>> > necessarily completed) at trunk bring up. Everything else builds on
>>> this.
>>> >
>>> > Simon
>>> >
>>>
>>> Those all sound good.
>>>
>>> With "Remove IOC nature of runtime construction", thats not something
>>> I recall coming up before so could you say a bit more about that?
>>
>>
>> At the moment the runtime builder injects specific resolvers, factories
>> etc into the various runtime components. In nine times out of ten it just
>> gets them from the extension registry so I would like to remove the majority
>> of the runtime builder code and let each function do it itself given the
>> registry. If we need to allow access to some new extension in the future
>> then that doesn't involve rewriting layers of constructors.
>>
>> I appreciate the benefit from IOC generally but in this case I don't think
>> its adding anything.
>>
>>
>>>
>>>
>>> The items under "Build" seem good too, i think the easiest way to make
>>> the build significantly faster will be a reorg like you describe.
>>> Would things like itests, vtests, samples be moved to be within
>>> separate folders under the extension they relate to? I think that
>>> might be good, is it what you had in mind - so for example all the
>>> webservice things be moved to be under the webservice extension
>>> folder?
>>
>>
>> Actually I hadn't thought that far. But I like the though that we could
>> make extensions more modular to include Itest, vtest etc. This also ties up
>> with Ram's thoughts about tieing it all closer to documentation on the web
>> site also.
>>
>>>
>>>
>>> Under "Distribution" there is "Smaller total number of jars", thats
>>> come up a number of times from users, for example, a comment saying
>>> the calculator2 sample which uses the aggregate jars prototype is
>>> easier to understand, and the discussion on using JDK6 would also help
>>> with this. Not sure how we're going to decide what the themes to focus
>>> on are but I think this would be a good one to do, and if we end up
>>> with multiple distribution having an extra one using aggregated jars
>>> seems like it could be a harmless and useful option along with all the
>>> other distributions.
>>
>>
>> Agreed.
>>
>> Re. deciding on themes. I think we're getting to the stage where all the
>> ideas so far can be summarized and someone can make a proposal on
>>
>> 1. A high level set of themes
>> 2. If there is any natural order that these things have to flow in
>>
>> If none else gets to it I'll have a go later today. I have a few other
>> things to ge through first.
>>
>> I imagine there will be debate about the "how" of some of these items. But
>> that is different from agreeing that items need addressing.
>>
>>
>>>
>>> ...ant
>>>
>>
>>
> Conversation here has died down so I'd like to close this out. Here is a
> summary of the ideas that have been put forward. Apologies if I missed any.
> I took the liberty of organizing in the rather arbitrary categories from my
> post. I've had a go a marking those items that need to get done to get
> through the stage 1 that has been proposed where we bring up the minimum
> number of modules to define the base code and best practice for bringing up
> the large number of other modules. Just my view so your view may differ.
> Comments please.
>
> I would be very surprised if we don't think of more things for Stage2 as we
> go through Stage1. That's fine. People will be drawn to the things they
> really want to see fixed. I guess after we've discussed a bit we can put
> this list up on a wiki page for future reference. I imagine that each
> individual item will get a thread of its own at the appropriate time.
>
>
> Stage 1 - minimal bring up
> Stage 2 - bring up to 1.x level of function
>
> I've marked 1 and everthing else is 2.
>
> For the user
> consumability
> honing the user experience - probably overlaps with lots of these
> things
> Documentation
> Complete extension documentation
> Document common tasks +1 Ram's suggestion of document/sample
> alignment. Also share README content with website
> documentation improved to include patterns and better links to info in
> samples
> Set of docs specifically for 2.0
> Documentatin for official SPIs/APIs
> Make complete docs a condition of 2.0 release
> Distribution
> Separation of core from extensions
> Smaller total number of jars and remove all jar
> Have an obvious first steps thread in the distro
> Re-organized samples and itests
> top notch demos and presentations
> Development
> OASIS spec support
> OSOA spec suport
> promoting graphical tools and syntax assist tools to work with Tuscany
> tooling integration?
> Deployment
> Clear hosting/deployment options with samples
> 1 Start with just node and and get rid on host-embedded for now -
> rethink embedding, launching etc.
> Clarify/Simplify/Consistent SCA domain story (deployment and
> management)
> Make our SCA domain to be a bit more dynamic
> QoS: Improved Policy Framework with transaction and security
> Management
> JEE/SCA integration.
> Improved JEE/Webapp support
> Work well with domain
> Complete wiring support
> Have good test framework testing all extensions in this environment
> Support some standard web frameworks
> Debug
> Restructure validation itests and index from messages
> Improve tracing and document how to exploit
> Runtime model dump
>
> For the developer
> Development
> 1 Review SPI, clean and document
> 1 Modularity (there has been much discussion already) / OSGI enablement
> 1 Remove IOC nature of runtime construction
> 1 Builders structure
> 1 Contribution processing structure
> Build
> Find a way to make the build easier.
> Single Jar with JDK 6
> Speed it up
> 1 Structure. I'd like to separate core from extensions and disitributed
> content from content in development (contrib)
> 1 Build/test with the distribution structure
> Release
> Need to simplify and make it easily repeatable
>
> Regards
>
> Simon
>
So it's time we got back on here. We've made a start on Stage1 in that the
minimum set of modules is up an running just about. What are the things we
need/want to do before we start on the wider themes. In summary this was the
list we captured from this thread.
1 Start with just node and and get rid on host-embedded for now -
rethink embedding, launching etc.
Looks like host-embedded has gone in the node rework in the equinox
branch so we need to review that
1 Review SPI, clean and document
1 Modularity (there has been much discussion already) / OSGI enablement
1 Remove IOC nature of runtime construction
1 Builders structure
1 Contribution processing structure
1 Structure. I'd like to separate core from extensions and disitributed
content from content in development (contrib)
1 Build/test with the distribution structure
A) Are the things that should be added/removed
B) who is going to do what.
I would probably add to this list some of the "distribution" items to this
stage 1 list. There has been a reorg in the equinox branch and we should
review that.
I'm going to ease myself in gently by looking at the builder extension point
and doing some tidying there. Not a particularly high priority but a chance
to get a feel for the changes in the code.
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Nov 13, 2008 at 11:39 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Nov 13, 2008 at 11:14 AM, ant elder <an...@apache.org> wrote:
>
>> On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com>
>> wrote:
>> >>
>> >>
>> >> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com>
>> >> wrote:
>> >>
>> >> <snip>
>> >>
>> >>
>> >>>
>> >>> Personally I get frustrated when I read or make Tuscany demos or
>> >>> presentations and the simple composites must be created with PaintShop
>> or
>> >>> some non-tech tool.
>> >>
>> >> This may not be quite what you had in mind but a while back someone
>> >> created an SCA diagram stencil for Visio [1], lots of people wont have
>> Visio
>> >> so maybe we should create a similar template for OpenOffice Draw and
>> make
>> >> that available on the Tuscany website so anyone can use it to create
>> good
>> >> looking pictures. (Disclaimer, i know little about OpenOffice Draw but
>> >> googling it it does seem to have a stencil facility)
>> >>
>> >> ...ant
>> >>
>> >> [1]
>> >>
>> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>> >>
>> >
>> > I'm interested in consumability and ease of use. I've tried to extract a
>> few
>> > things from my mental list that I think have an impact...
>> >
>> > For the user
>> > Documentation
>> > Complete extension documentation
>> > Document common tasks +1 Ram's suggestion of document/sample
>> alignment.
>> > Also share README content with website
>> > Distribution
>> > Separation of core from extensions
>> > Smaller total number of jars and remove all jar
>> > Have an obvious first steps thread in the distro
>> > Development
>> > Improve policy story
>> > Deployment
>> > * Clear hosting/deployment options with samples
>> > Clarify/Simplify domain story
>> > Management
>> > Debug
>> > Restructure validation itests and index from messages
>> > Improve tracing and document how to exploit
>> > Runtime model dump
>> >
>> > For the developer
>> > Development
>> > * Review SPI, clean and document
>> > * Modularity (there has been much discussion already)
>> > * Remove IOC nature of runtime construction
>> > * Builders structure
>> > * Contribution processing structure
>> > Build
>> > Speed it up
>> > * Structure. I'd like to separate core from extensions and
>> disitributed
>> > content from content in development
>> > * Build/test with the distribution structure
>> > Release
>> > Need to simplify and make it easily repeatable
>> >
>> > * marks the things I think have to be at least considered (but not
>> > necessarily completed) at trunk bring up. Everything else builds on
>> this.
>> >
>> > Simon
>> >
>>
>> Those all sound good.
>>
>> With "Remove IOC nature of runtime construction", thats not something
>> I recall coming up before so could you say a bit more about that?
>
>
> At the moment the runtime builder injects specific resolvers, factories etc
> into the various runtime components. In nine times out of ten it just gets
> them from the extension registry so I would like to remove the majority of
> the runtime builder code and let each function do it itself given the
> registry. If we need to allow access to some new extension in the future
> then that doesn't involve rewriting layers of constructors.
>
> I appreciate the benefit from IOC generally but in this case I don't think
> its adding anything.
>
>
>>
>>
>> The items under "Build" seem good too, i think the easiest way to make
>> the build significantly faster will be a reorg like you describe.
>> Would things like itests, vtests, samples be moved to be within
>> separate folders under the extension they relate to? I think that
>> might be good, is it what you had in mind - so for example all the
>> webservice things be moved to be under the webservice extension
>> folder?
>
>
> Actually I hadn't thought that far. But I like the though that we could
> make extensions more modular to include Itest, vtest etc. This also ties up
> with Ram's thoughts about tieing it all closer to documentation on the web
> site also.
>
>>
>>
>> Under "Distribution" there is "Smaller total number of jars", thats
>> come up a number of times from users, for example, a comment saying
>> the calculator2 sample which uses the aggregate jars prototype is
>> easier to understand, and the discussion on using JDK6 would also help
>> with this. Not sure how we're going to decide what the themes to focus
>> on are but I think this would be a good one to do, and if we end up
>> with multiple distribution having an extra one using aggregated jars
>> seems like it could be a harmless and useful option along with all the
>> other distributions.
>
>
> Agreed.
>
> Re. deciding on themes. I think we're getting to the stage where all the
> ideas so far can be summarized and someone can make a proposal on
>
> 1. A high level set of themes
> 2. If there is any natural order that these things have to flow in
>
> If none else gets to it I'll have a go later today. I have a few other
> things to ge through first.
>
> I imagine there will be debate about the "how" of some of these items. But
> that is different from agreeing that items need addressing.
>
>
>>
>> ...ant
>>
>
>
Conversation here has died down so I'd like to close this out. Here is a
summary of the ideas that have been put forward. Apologies if I missed any.
I took the liberty of organizing in the rather arbitrary categories from my
post. I've had a go a marking those items that need to get done to get
through the stage 1 that has been proposed where we bring up the minimum
number of modules to define the base code and best practice for bringing up
the large number of other modules. Just my view so your view may differ.
Comments please.
I would be very surprised if we don't think of more things for Stage2 as we
go through Stage1. That's fine. People will be drawn to the things they
really want to see fixed. I guess after we've discussed a bit we can put
this list up on a wiki page for future reference. I imagine that each
individual item will get a thread of its own at the appropriate time.
Stage 1 - minimal bring up
Stage 2 - bring up to 1.x level of function
I've marked 1 and everthing else is 2.
For the user
consumability
honing the user experience - probably overlaps with lots of these
things
Documentation
Complete extension documentation
Document common tasks +1 Ram's suggestion of document/sample alignment.
Also share README content with website
documentation improved to include patterns and better links to info in
samples
Set of docs specifically for 2.0
Documentatin for official SPIs/APIs
Make complete docs a condition of 2.0 release
Distribution
Separation of core from extensions
Smaller total number of jars and remove all jar
Have an obvious first steps thread in the distro
Re-organized samples and itests
top notch demos and presentations
Development
OASIS spec support
OSOA spec suport
promoting graphical tools and syntax assist tools to work with Tuscany
tooling integration?
Deployment
Clear hosting/deployment options with samples
1 Start with just node and and get rid on host-embedded for now -
rethink embedding, launching etc.
Clarify/Simplify/Consistent SCA domain story (deployment and
management)
Make our SCA domain to be a bit more dynamic
QoS: Improved Policy Framework with transaction and security
Management
JEE/SCA integration.
Improved JEE/Webapp support
Work well with domain
Complete wiring support
Have good test framework testing all extensions in this environment
Support some standard web frameworks
Debug
Restructure validation itests and index from messages
Improve tracing and document how to exploit
Runtime model dump
For the developer
Development
1 Review SPI, clean and document
1 Modularity (there has been much discussion already) / OSGI enablement
1 Remove IOC nature of runtime construction
1 Builders structure
1 Contribution processing structure
Build
Find a way to make the build easier.
Single Jar with JDK 6
Speed it up
1 Structure. I'd like to separate core from extensions and disitributed
content from content in development (contrib)
1 Build/test with the distribution structure
Release
Need to simplify and make it easily repeatable
Regards
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Nov 13, 2008 at 11:14 AM, ant elder <an...@apache.org> wrote:
> On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <si...@googlemail.com>
> wrote:
> >
> >
> > On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com> wrote:
> >>
> >>
> >> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com>
> >> wrote:
> >>
> >> <snip>
> >>
> >>
> >>>
> >>> Personally I get frustrated when I read or make Tuscany demos or
> >>> presentations and the simple composites must be created with PaintShop
> or
> >>> some non-tech tool.
> >>
> >> This may not be quite what you had in mind but a while back someone
> >> created an SCA diagram stencil for Visio [1], lots of people wont have
> Visio
> >> so maybe we should create a similar template for OpenOffice Draw and
> make
> >> that available on the Tuscany website so anyone can use it to create
> good
> >> looking pictures. (Disclaimer, i know little about OpenOffice Draw but
> >> googling it it does seem to have a stencil facility)
> >>
> >> ...ant
> >>
> >> [1]
> >>
> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
> >>
> >
> > I'm interested in consumability and ease of use. I've tried to extract a
> few
> > things from my mental list that I think have an impact...
> >
> > For the user
> > Documentation
> > Complete extension documentation
> > Document common tasks +1 Ram's suggestion of document/sample
> alignment.
> > Also share README content with website
> > Distribution
> > Separation of core from extensions
> > Smaller total number of jars and remove all jar
> > Have an obvious first steps thread in the distro
> > Development
> > Improve policy story
> > Deployment
> > * Clear hosting/deployment options with samples
> > Clarify/Simplify domain story
> > Management
> > Debug
> > Restructure validation itests and index from messages
> > Improve tracing and document how to exploit
> > Runtime model dump
> >
> > For the developer
> > Development
> > * Review SPI, clean and document
> > * Modularity (there has been much discussion already)
> > * Remove IOC nature of runtime construction
> > * Builders structure
> > * Contribution processing structure
> > Build
> > Speed it up
> > * Structure. I'd like to separate core from extensions and
> disitributed
> > content from content in development
> > * Build/test with the distribution structure
> > Release
> > Need to simplify and make it easily repeatable
> >
> > * marks the things I think have to be at least considered (but not
> > necessarily completed) at trunk bring up. Everything else builds on this.
> >
> > Simon
> >
>
> Those all sound good.
>
> With "Remove IOC nature of runtime construction", thats not something
> I recall coming up before so could you say a bit more about that?
At the moment the runtime builder injects specific resolvers, factories etc
into the various runtime components. In nine times out of ten it just gets
them from the extension registry so I would like to remove the majority of
the runtime builder code and let each function do it itself given the
registry. If we need to allow access to some new extension in the future
then that doesn't involve rewriting layers of constructors.
I appreciate the benefit from IOC generally but in this case I don't think
its adding anything.
>
>
> The items under "Build" seem good too, i think the easiest way to make
> the build significantly faster will be a reorg like you describe.
> Would things like itests, vtests, samples be moved to be within
> separate folders under the extension they relate to? I think that
> might be good, is it what you had in mind - so for example all the
> webservice things be moved to be under the webservice extension
> folder?
Actually I hadn't thought that far. But I like the though that we could make
extensions more modular to include Itest, vtest etc. This also ties up with
Ram's thoughts about tieing it all closer to documentation on the web site
also.
>
>
> Under "Distribution" there is "Smaller total number of jars", thats
> come up a number of times from users, for example, a comment saying
> the calculator2 sample which uses the aggregate jars prototype is
> easier to understand, and the discussion on using JDK6 would also help
> with this. Not sure how we're going to decide what the themes to focus
> on are but I think this would be a good one to do, and if we end up
> with multiple distribution having an extra one using aggregated jars
> seems like it could be a harmless and useful option along with all the
> other distributions.
Agreed.
Re. deciding on themes. I think we're getting to the stage where all the
ideas so far can be summarized and someone can make a proposal on
1. A high level set of themes
2. If there is any natural order that these things have to flow in
If none else gets to it I'll have a go later today. I have a few other
things to ge through first.
I imagine there will be debate about the "how" of some of these items. But
that is different from agreeing that items need addressing.
>
> ...ant
>
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@apache.org>.
On Wed, Nov 12, 2008 at 1:04 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com> wrote:
>>
>>
>> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com>
>> wrote:
>>
>> <snip>
>>
>>
>>>
>>> Personally I get frustrated when I read or make Tuscany demos or
>>> presentations and the simple composites must be created with PaintShop or
>>> some non-tech tool.
>>
>> This may not be quite what you had in mind but a while back someone
>> created an SCA diagram stencil for Visio [1], lots of people wont have Visio
>> so maybe we should create a similar template for OpenOffice Draw and make
>> that available on the Tuscany website so anyone can use it to create good
>> looking pictures. (Disclaimer, i know little about OpenOffice Draw but
>> googling it it does seem to have a stencil facility)
>>
>> ...ant
>>
>> [1]
>> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>>
>
> I'm interested in consumability and ease of use. I've tried to extract a few
> things from my mental list that I think have an impact...
>
> For the user
> Documentation
> Complete extension documentation
> Document common tasks +1 Ram's suggestion of document/sample alignment.
> Also share README content with website
> Distribution
> Separation of core from extensions
> Smaller total number of jars and remove all jar
> Have an obvious first steps thread in the distro
> Development
> Improve policy story
> Deployment
> * Clear hosting/deployment options with samples
> Clarify/Simplify domain story
> Management
> Debug
> Restructure validation itests and index from messages
> Improve tracing and document how to exploit
> Runtime model dump
>
> For the developer
> Development
> * Review SPI, clean and document
> * Modularity (there has been much discussion already)
> * Remove IOC nature of runtime construction
> * Builders structure
> * Contribution processing structure
> Build
> Speed it up
> * Structure. I'd like to separate core from extensions and disitributed
> content from content in development
> * Build/test with the distribution structure
> Release
> Need to simplify and make it easily repeatable
>
> * marks the things I think have to be at least considered (but not
> necessarily completed) at trunk bring up. Everything else builds on this.
>
> Simon
>
Those all sound good.
With "Remove IOC nature of runtime construction", thats not something
I recall coming up before so could you say a bit more about that?
The items under "Build" seem good too, i think the easiest way to make
the build significantly faster will be a reorg like you describe.
Would things like itests, vtests, samples be moved to be within
separate folders under the extension they relate to? I think that
might be good, is it what you had in mind - so for example all the
webservice things be moved to be under the webservice extension
folder?
Under "Distribution" there is "Smaller total number of jars", thats
come up a number of times from users, for example, a comment saying
the calculator2 sample which uses the aggregate jars prototype is
easier to understand, and the discussion on using JDK6 would also help
with this. Not sure how we're going to decide what the themes to focus
on are but I think this would be a good one to do, and if we end up
with multiple distribution having an extra one using aggregated jars
seems like it could be a harmless and useful option along with all the
other distributions.
...ant
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Nov 12, 2008 at 11:25 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com>wrote:
>
> <snip>
>
>
>
>> Personally I get frustrated when I read or make Tuscany demos or
>> presentations and the simple composites must be created with PaintShop or
>> some non-tech tool.
>>
>
> This may not be quite what you had in mind but a while back someone created
> an SCA diagram stencil for Visio [1], lots of people wont have Visio so
> maybe we should create a similar template for OpenOffice Draw and make that
> available on the Tuscany website so anyone can use it to create good looking
> pictures. (Disclaimer, i know little about OpenOffice Draw but googling it
> it does seem to have a stencil facility)
>
> ...ant
>
> [1]
> http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
>
>
I'm interested in consumability and ease of use. I've tried to extract a few
things from my mental list that I think have an impact...
For the user
Documentation
Complete extension documentation
Document common tasks +1 Ram's suggestion of document/sample alignment.
Also share README content with website
Distribution
Separation of core from extensions
Smaller total number of jars and remove all jar
Have an obvious first steps thread in the distro
Development
Improve policy story
Deployment
* Clear hosting/deployment options with samples
Clarify/Simplify domain story
Management
Debug
Restructure validation itests and index from messages
Improve tracing and document how to exploit
Runtime model dump
For the developer
Development
* Review SPI, clean and document
* Modularity (there has been much discussion already)
* Remove IOC nature of runtime construction
* Builders structure
* Contribution processing structure
Build
Speed it up
* Structure. I'd like to separate core from extensions and disitributed
content from content in development
* Build/test with the distribution structure
Release
Need to simplify and make it easily repeatable
* marks the things I think have to be at least considered (but not
necessarily completed) at trunk bring up. Everything else builds on this.
Simon
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@gmail.com>.
On Tue, Nov 11, 2008 at 11:30 PM, Dan Becker <da...@gmail.com> wrote:
<snip>
> Personally I get frustrated when I read or make Tuscany demos or
> presentations and the simple composites must be created with PaintShop or
> some non-tech tool.
>
This may not be quite what you had in mind but a while back someone created
an SCA diagram stencil for Visio [1], lots of people wont have Visio so
maybe we should create a similar template for OpenOffice Draw and make that
available on the Tuscany website so anyone can use it to create good looking
pictures. (Disclaimer, i know little about OpenOffice Draw but googling it
it does seem to have a stencil facility)
...ant
[1]
http://soastation.blogspot.com/2007/10/sca-diagram-stencil-for-visio.html
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by haleh mahbod <hm...@gmail.com>.
Ram,
This is a good idea and goes hand-in-hand with what I posted a while ago
about having an index for samples by functionality. I'd like to work on this
if you are interested to work together.
Haleh
On Tue, Nov 11, 2008 at 10:28 PM, Ramkumar R <ra...@gmail.com> wrote:
> Here's something that I had in mind:
>
> Re-organized samples and itests:
> I believe current samples and itests are pretty good in their contents but
> not well organized, many a times I keep searching for a right sample/itest
> for a functionality.
>
> I would suggest a one-to-one mapping of samples and itests with the each of
> implementation types, binding types and contribution types we support,
> which would demostrates the complete functionality offered by each of these
> implementation types, binding types and contribution types.
> Probably, we might need to have sub-project under each of these samples to
> demonstrate more relevant features to their parent, by not duplicating
> things as much as possible.
>
> Other advantages of this re-organization would be:
> 1. Easy to pick up samples and itests, when we build a smaller distribution
> for the users.
> 2. Easy for developers to verify their fixes by checking with smaller
> chunck of samples and itests.
>
> Any suggestions/comments on the same are welcome.
>
>
>
> On Wed, Nov 12, 2008 at 5:00 AM, Dan Becker <da...@gmail.com>wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Nov 11, 2008 at 10:11 AM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>> OASIS is clearly on the list. Ant's survey should help. But what else?
>>>>
>>>> IMO this is not really about a detailed shopping list of code changes
>>>> but
>>>> more about themes (as per the thread title), i.e. more the what than the
>>>> how.
>>>>
>>>>
>>> Here's some things i think it could be good to look at:
>>>
>>> More coherent documentation.
>>> Improved JEE/Webapp support.
>>> Policy and QoS
>>> Distribution
>>>
>>>
>> I agree with the these technical suggestions. I think the OSGI enablement
>> will be a big draw (even if it comes before 2.0). We are going to need some
>> good samples and demos that show this off.
>>
>> I'd also like to see the documentation improved. I spend a lot of time
>> searching the samples for specific techniques and patterns. I think the
>> samples have many golden nuggets hidden in there. The documentation
>> would be a nice way to expose the riches and put them to use.
>>
>> In a similar vein, I think consumability would be a good theme. We could
>> spend a few more cycles honing the user experience. I'd like to see more
>> top notch demos and presentations of the Tuscany capabilities. Perhaps this
>> is not our development realm, but promoting graphical tools and syntax
>> assist tools to work with Tuscany. Personally I get frustrated when I read
>> or make Tuscany demos or presentations and the simple composites must be
>> created with PaintShop or some non-tech tool.
>>
>>
>> --
>> Thanks, Dan Becker
>>
>>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Ramkumar R <ra...@gmail.com>.
Here's something that I had in mind:
Re-organized samples and itests:
I believe current samples and itests are pretty good in their contents but
not well organized, many a times I keep searching for a right sample/itest
for a functionality.
I would suggest a one-to-one mapping of samples and itests with the each of
implementation types, binding types and contribution types we support,
which would demostrates the complete functionality offered by each of these
implementation types, binding types and contribution types.
Probably, we might need to have sub-project under each of these samples to
demonstrate more relevant features to their parent, by not duplicating
things as much as possible.
Other advantages of this re-organization would be:
1. Easy to pick up samples and itests, when we build a smaller distribution
for the users.
2. Easy for developers to verify their fixes by checking with smaller chunck
of samples and itests.
Any suggestions/comments on the same are welcome.
On Wed, Nov 12, 2008 at 5:00 AM, Dan Becker <da...@gmail.com> wrote:
> ant elder wrote:
>
>> On Tue, Nov 11, 2008 at 10:11 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>> OASIS is clearly on the list. Ant's survey should help. But what else?
>>>
>>> IMO this is not really about a detailed shopping list of code changes but
>>> more about themes (as per the thread title), i.e. more the what than the
>>> how.
>>>
>>>
>> Here's some things i think it could be good to look at:
>>
>> More coherent documentation.
>> Improved JEE/Webapp support.
>> Policy and QoS
>> Distribution
>>
>>
> I agree with the these technical suggestions. I think the OSGI enablement
> will be a big draw (even if it comes before 2.0). We are going to need some
> good samples and demos that show this off.
>
> I'd also like to see the documentation improved. I spend a lot of time
> searching the samples for specific techniques and patterns. I think the
> samples have many golden nuggets hidden in there. The documentation
> would be a nice way to expose the riches and put them to use.
>
> In a similar vein, I think consumability would be a good theme. We could
> spend a few more cycles honing the user experience. I'd like to see more
> top notch demos and presentations of the Tuscany capabilities. Perhaps this
> is not our development realm, but promoting graphical tools and syntax
> assist tools to work with Tuscany. Personally I get frustrated when I read
> or make Tuscany demos or presentations and the simple composites must be
> created with PaintShop or some non-tech tool.
>
>
> --
> Thanks, Dan Becker
>
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by Dan Becker <da...@gmail.com>.
ant elder wrote:
> On Tue, Nov 11, 2008 at 10:11 AM, Simon Laws <si...@googlemail.com> wrote:
>> OASIS is clearly on the list. Ant's survey should help. But what else?
>>
>> IMO this is not really about a detailed shopping list of code changes but
>> more about themes (as per the thread title), i.e. more the what than the
>> how.
>>
>
> Here's some things i think it could be good to look at:
>
> More coherent documentation.
> Improved JEE/Webapp support.
> Policy and QoS
> Distribution
>
I agree with the these technical suggestions. I think the OSGI
enablement will be a big draw (even if it comes before 2.0). We are
going to need some good samples and demos that show this off.
I'd also like to see the documentation improved. I spend a lot of time
searching the samples for specific techniques and patterns. I think the
samples have many golden nuggets hidden in there. The documentation
would be a nice way to expose the riches and put them to use.
In a similar vein, I think consumability would be a good theme. We could
spend a few more cycles honing the user experience. I'd like to see
more top notch demos and presentations of the Tuscany capabilities.
Perhaps this is not our development realm, but promoting graphical tools
and syntax assist tools to work with Tuscany. Personally I get
frustrated when I read or make Tuscany demos or presentations and the
simple composites must be created with PaintShop or some non-tech tool.
--
Thanks, Dan Becker
Re: [DISCUSS] Tuscany 2.0 themes?
Posted by ant elder <an...@gmail.com>.
On Tue, Nov 11, 2008 at 10:11 AM, Simon Laws <si...@googlemail.com> wrote:
> We've agreed that we are going to develop OASIS compliant function in trunk.
> I just started a discussion on what the starting point is. But what are the
> themes for trunk up to the 2.0 release? What would we hope to be announcing
> in the release notes that are going to get people excited? What are this
> things that are going to make the code base easier to work with?
>
> OASIS is clearly on the list. Ant's survey should help. But what else?
>
> IMO this is not really about a detailed shopping list of code changes but
> more about themes (as per the thread title), i.e. more the what than the
> how.
>
Here's some things i think it could be good to look at:
More coherent documentation.
Maybe try to have a set of documentation specifically for 2.0 that
covers all the major features and functions as well as introductory
getting started, and how to run and environment type options to help
new users. Clearly document what the official APIs and SPIs are and
how we recommend people use them to be supported across releases. And
don't leave all this as an after thought - don't release 2.0 till we
think the doc is in an ok state.
Improved JEE/Webapp support.
Its a bit neglected these days in Tuscany but this seems to be how
most people run Tuscany so we should make it work really well. Have it
be a or participate well in a domain with complete wiring support, all
the main Tuscany extensions working and tested in this environment,
and support some standard Web frameworks so people can use what they
know - JSP, JSF, Struts, Wicket, GWT, Flex etc, even if we don't
support all of those at least show how it could be done.
Policy and QoS
a big part of SCA is declarative policy so we should demonstrate that
with things like transactions and confidentiality support which work
and consistently across Tuscany extensions and environments.
Distribution
users keep commenting on it and we keep talking about it. I don't
think we'll find a single solution that suits every environment and
makes everyone happy but i don't think what we have today (in any
branch) is the complete answer yet. One thing I'd like to see is a lot
less jars and an easier way to build without transitive dependencies.
I also think it would be good to have a minimal runtime that can run
simple things like calculator with just a single jar to make it look
really easy to get started with Tuscany - and we can do this with JDK6
as it includes all the dependencies we need.
Find a way to make the build easier.
Not sure exactly how yet :) but its so big and hard it puts people off
helping and a 45 minute build is too long.
...ant