date:20060719



On Jul 19, 2006, at 10:48 PM, rakesh dash wrote:


Jim,

Thanks a lot for your response.

1. In the slide 4, it states to reduce the number of concepts of  
SCA. How

does composite attains it?

 For example- services are equivalent to entry point,  
references are

similar to external service.
The added thing is properties.
It keeps similar concepts of modules and adds properties also. How  
do we
think that it redu ces SCA concept when it is adding more  
functionality to

it?
Here I would recommend to use the existing module/M1 concept and  
add things
to it instead of doing things from scratch. Let us reuse the  
functionality

which is already in M1. Please clarify.
The *specification* has changed and we (Tuscany) are following the  
specification. I think if you compare UML representations of the .9  
spec and recursive model it is dramatically simpler, two of the most  
apparent examples being:


- Components have services and references; there is no need for  
additional concepts of entry points or external services


-  We removed the concept of module component. Since module  
components could also be configured, the notion of composite  
properties is not really new, although with the addition of XPath and  
includes, it is significantly more powerful.


Also, I'm not sure I follow you but I think having fewer concepts can  
result in something that is much more powerful. For example,  
recursion reduces the number of specialized concepts yet is offers  
many more possibilities than the 2-level model we had before.




2. In slide 11 there is a list of reasons provided which tries  
giving us

explanation of why the current M1 architecture requires refactoring?
I would request to provide a one to one mapping of this list to the  
new

concepts of M2 which resolves the issues of M1 architecture.
I'm sure this would be helpful and if someone is brave enough to  
attempt this, I am willing to answer questions. However, since that  
is a very wide open request (and difficult to tackle in its  
entirety), my suggestion would instead be to proceed by asking  
specific questions.


Apart from this, I do agree with you that the wiring concept in M2  
may be
simplified with all the present functionalities. We should  
certainly make it

more simplified keeping the existing functionality.

It would be great if you could give me a clear picture on how  
targetInvoker
works. I understand that the targetInvoker resolves the target  
instance by

resolving scopeContainer.
It actually invokes on Component, which uses a scope container to  
resolve an implementation instance.

I think the whole process should have the address
of target instance using which the target invoker may locate the  
target

instance.
Outside of a callback and reference that invokes over a binding, why  
does a target invoker need the address of the component? In SCA,  
components cannot be directly exposed or directly invoke outside the  
boundaries of their parent composite; all cross-composite invocations  
must flow across services and references. This means we can  
statically analyze and wire all component-to-component invocations,  
alleviating the need to use addresses for intra-composite invocations.



I am not sure where this address is provided to the targetInvoker?
Do the ScopeContainer provides the target address/reference to the
targetInvoker?
The scope container is responsible for tracking implementation  
instances using whatever mechanisms are appropriate (e.g. session/ 
conversation id, etc.). That should be opaque to clients of the scope  
container, such as Components.


Can you please clarify? Can you please let me know the packages/ 
classes

which I can go through to get a good idea about it.

In core there is an implementation package. There are also samples.  
My recommendation would be to start perhaps with the eager init or  
calculator samples and then work your way into running the test  
cases. If you have any questions, I'll try to help as best I can.


Jim


cheers,
Rakesh.



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

Re: Diagram Drafts

2006-07-19 Thread Venkata Krishnan


David, this looks a really very nice arial view :-)

I agree that the DAS, SDO and Tools blocks should not overlay the core and
hosting platform blocks.

Now, if you look the diagram, it gives an impression of one huge middleware
that encapsulates all sorts of containers.  The aspect of being able to
'integrate' distributed systems is not so evident.  We need to probably
think about positioning the 'extensions' differently to bring this point
out.  The intention is, when a person sees the picture he must get an idea
of where he is going to be able to use this.  Makes sense?

Thanks.

- Venkat

On 7/20/06, Luciano Resende <[EMAIL PROTECTED]> wrote:


So, If i'm guessing right, the idea is to have this diagram on the main
page, and once a user clicks on a link, let's say DAS, it would go to a DAS
"overview" page ? So we could probably make each component that is listed on
the tuscany web site outline to have an "overview" page and redirect the
user to that page when a component is clicked...As long as that page is not
a text only one :)

I have a proposal for the DAS content on the attached "DAS overview.zip"

I'd need some help on updating the diagram using the same tool David is
using, as it looks like MAC only...

And I'll build the object diagram for DAS to be part of the DAS Overview
as well...

Thanks
- Luciano


On 7/19/06, Jim Marino < [EMAIL PROTECTED]> wrote:
>
> Cool - thanks!
>
> On Jul 19, 2006, at 12:35 PM, David Wheeler wrote:
>
> > oh, ok.
> > Lets try this agian zipped.
> >
> > -David Wheeler
> >
> > On 7/19/06, Jim Marino <[EMAIL PROTECTED] > wrote:I found out
> > yesterday the list strips PDFs but if you zip them it
> > goes through.
> >
> > Jim
> >
> >
> > On Jul 19, 2006, at 12:22 PM, David Wheeler wrote:
> >
> > > Sure thing Jim.
> > >
> > > Should be attached
> > >
> > > On 7/19/06, Jim Marino < [EMAIL PROTECTED]> wrote: Hi David,
> > >
> > > Is there any chance you can pdf it?
> > >
> > > Jim
> > >
> > > On Jul 19, 2006, at 11:56 AM, David Wheeler wrote:
> > >
> > > > The original format is an Omnigraffle document, but I have
> > attached
> > > > a zip that contains the graffle as well as copies in svg and
> > visio.
> > > >
> > > > I modefied it to better reflect the seperation of the Core Runtime
> > > > and SDO / Tools, as well as adding Spring to the list of
> > extensions.
> > > >
> > > >
> > > > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote: Also what is the source
> > > > format... anyway you can upload it ?  send email
> > > > attachment?
> > > >
> > > > David Wheeler wrote:
> > > > > Ah,
> > > > > I was under the impression that the other images posted so far
> > > > were for
> > > > > brain storming more than final drafts, Intented to be replaced.
> > > > >
> > > > > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:
> > > > >>
> > > > >> David,
> > > > >> I just checked in an overview that made it clickable with
> > > > another image
> > > > >> that was already posted.  When you click on a section it takes
> > > > you to
> > > > >> one of the  links on top.  I'm not partial, I can easily switch
>
> > > > out.
> > > > >>
> > > > >> David Wheeler wrote:
> > > > >> > I've come up with a couple possible diagrams for thw website
> > > > >> navigation:
> > > > >> >
> > > > >> > Tuscany Block Diagram-
> > > > >> >
> > > > >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> 
> > > > ClickableImages/attachments/Tuscany-Block.png
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > SCA Diagram-
> > > > >> >
> > > > >> 
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> > > > ClickableImages/attachments/Tusc-SCA-Diagram.png
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > Let me know what you guys think.
> > > > >> >
> > > > >> > -David Wheeler
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> > -
> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > > 
> > > >
> > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---

Re: Queries on certain M2 concepts

2006-07-19 Thread rakesh dash


Jim,

Thanks a lot for your response.

1. In the slide 4, it states to reduce the number of concepts of SCA. How
does composite attains it?

 For example- services are equivalent to entry point, references are
similar to external service.
The added thing is properties.
It keeps similar concepts of modules and adds properties also. How do we
think that it redu ces SCA concept when it is adding more functionality to
it?
Here I would recommend to use the existing module/M1 concept and add things
to it instead of doing things from scratch. Let us reuse the functionality
which is already in M1. Please clarify.

2. In slide 11 there is a list of reasons provided which tries giving us
explanation of why the current M1 architecture requires refactoring?
I would request to provide a one to one mapping of this list to the new
concepts of M2 which resolves the issues of M1 architecture.

Apart from this, I do agree with you that the wiring concept in M2 may be
simplified with all the present functionalities. We should certainly make it
more simplified keeping the existing functionality.

It would be great if you could give me a clear picture on how targetInvoker
works. I understand that the targetInvoker resolves the target instance by
resolving scopeContainer. I think the whole process should have the address
of target instance using which the target invoker may locate the target
instance. I am not sure where this address is provided to the targetInvoker?
Do the ScopeContainer provides the target address/reference to the
targetInvoker?
Can you please clarify? Can you please let me know the packages/classes
which I can go through to get a good idea about it.

cheers,
Rakesh.

Re: How to deal with spec-related issues

The site is not quite public yet (probably next week). If you are  
interested, could you send me your contact information offline and I  
will facilitate looking into this? Also, are you currently employed  
by one of the collaborating companies?


Jim


On Jul 19, 2006, at 10:17 PM, Venkata Krishnan wrote:


Hi... How do you get a membership at http://www.osoa.org.

- Venkat


On 7/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:


Right now Jeremy and I have been doing this as we are members of the
spec group as well. However, there is no reason others can't do this
as well. There will be a new OSOA website (mentioned by Raymond)
where issues can be raised directly so this may facilitate that  
process.


Jim


On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote:

> Is the spec group pulling proposals from Tuscany wiki?
> If not, maybe we need to push the proposals to the spec group and
> we may
> need a process.
>
>
> On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>>
>> On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote:
>>
>> > Hi,
>> >
>> > When we implement Tuscany, once a while we run into issues/ 
holes/
>> > missing features in the SCA spec (SDO in some cases). I'm  
wondering
>> > if we have an open source endorsed process on how to deal  
with such
>> > issues. Because they may impact the programming model (the  
way how

>> > users use SCA or SDO), I think we should be extra cautious on
>> > making decisions.
>> >
>> > Here're a list of things I can see:
>> >
>> > 1) Capture the requirement (problem statement)
>> > 2) Make proposals (could be more than one, maybe with  
prototypes in

>> > sandbox?)
>> > 3) Reach consenus in the community by discussions
>> > 4) Present the proposal to the spec group
>> > 5) Conclude if it will be become an official spec feature (if
>> > accepted by the spec group) or a tuscany-specific extension (we
>> > should use tuscany namespace to model SCDL extensions if  
required)

>> > 5) Make changes in the code base with an agreed solution
>> >
>> > I suggest that we keep track of them on the Tuscany wiki site.
>> >
>> > What do you guys think?
>>
>> Sounds good.
>>
>> I did something like this for the CDI proposal - there is a  
page on

>> the wiki at:
>> http://wiki.apache.org/ws/Tuscany/SpecProposals
>>
>> --
>> Jeremy
>>
>>
>>
>>  
-

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


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





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

Re: Commonality between Axis and Celtix bindings

That seems like a good idea to me. Perhaps we could also introduce a  
mechanism whereby people can choose the binding implementation  
without messing with the classpath as in M1 as well?


Jim

On Jul 13, 2006, at 8:24 AM, Jeremy Boynes wrote:

The Axis2 and Celtix bindings both support the   
definition from the spec. Looking at the celtix one in chianti the  
model object and the loader don't seem to be doing anything Celtix  
specific. What do people think of factoring the common stuff out  
into a separate module (binding.ws?) that can be shared by both?


--
Jeremy


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




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

Re: How to deal with spec-related issues

2006-07-19 Thread Venkata Krishnan


Hi... How do you get a membership at http://www.osoa.org.

- Venkat


On 7/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:


Right now Jeremy and I have been doing this as we are members of the
spec group as well. However, there is no reason others can't do this
as well. There will be a new OSOA website (mentioned by Raymond)
where issues can be raised directly so this may facilitate that process.

Jim


On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote:

> Is the spec group pulling proposals from Tuscany wiki?
> If not, maybe we need to push the proposals to the spec group and
> we may
> need a process.
>
>
> On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>>
>> On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote:
>>
>> > Hi,
>> >
>> > When we implement Tuscany, once a while we run into issues/holes/
>> > missing features in the SCA spec (SDO in some cases). I'm wondering
>> > if we have an open source endorsed process on how to deal with such
>> > issues. Because they may impact the programming model (the way how
>> > users use SCA or SDO), I think we should be extra cautious on
>> > making decisions.
>> >
>> > Here're a list of things I can see:
>> >
>> > 1) Capture the requirement (problem statement)
>> > 2) Make proposals (could be more than one, maybe with prototypes in
>> > sandbox?)
>> > 3) Reach consenus in the community by discussions
>> > 4) Present the proposal to the spec group
>> > 5) Conclude if it will be become an official spec feature (if
>> > accepted by the spec group) or a tuscany-specific extension (we
>> > should use tuscany namespace to model SCDL extensions if required)
>> > 5) Make changes in the code base with an agreed solution
>> >
>> > I suggest that we keep track of them on the Tuscany wiki site.
>> >
>> > What do you guys think?
>>
>> Sounds good.
>>
>> I did something like this for the CDI proposal - there is a page on
>> the wiki at:
>> http://wiki.apache.org/ws/Tuscany/SpecProposals
>>
>> --
>> Jeremy
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
>
> Yang ZHONG


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

Re: [C++] Steps to setup a Tuscany C++ development and build environment

2006-07-19 Thread Pete Robbins


Great stuff! We should add this to the wiki/website.

On 19/07/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


I just finished setting up a Tuscany C++ development and build
environment on my Linux machine and thought it would be useful to share
the steps I went through.

I am using Redhat Linux Enterprise 4, but the same steps should work on
other Linux systems like Fedora Core or Ubuntu for example.
These steps take no more than 15 mns to complete, starting from scratch.
After you complete them you should be all set to build the Tuscany C++
runtime, and start contributing :)

From a shell prompt, create a $HOME/tuscany directory.

Install the following prerequisites:

* Subversion - SVN version 1.3.0 or later is good (most Linux distros
already include SVN).

* Ant and a Java JDK are required by the SCA code generation tool used
to generate proxies and wrappers for C++ components.
Download apache-ant-1.6.5-bin.tar.gz from
http://ant.apache.org/bindownload.cgi.
From $HOME/tuscany do tar xzf apache-ant-1.6.5-bin.tar.gz.
Configure your environment:
export ANT_HOME=$HOME/tuscany/apache-ant-1.6.5
PATH=$ANT_HOME/bin:$PATH

Download jdk-1_5_0_06-linux-i586.bin from
http://java.sun.com/j2se/1.5.0/download.jsp.
From $HOME/tuscany run jdk-1_5_0_06-linux-i586.bin, this will extract
the JDK in $HOME/tuscany/jdk1.5.0_06.
Configure your environment:
export JAVA_HOME=$HOME/tuscany/jdk1.5.0_06
PATH=$JAVA_HOME/bin:$PATH

* Libxml2 2.6.20 or later
Libxml2 is already in most Linux distros, just check that you have
version 2.6.20 or later (my RHEL4 system had an older version and I had
to upgrade it).
To see which version of libxml2 is installed on your system do rpm -aq |
grep libxml2.
Configure your environment:
export LIBXML2_LIB=/usr/lib
export LIBXML2_INCLUDE=/usr/include/libxml2

* Axis2C version 0.92
Download axis2c-bin-0.92-linux.tar.gz from http://ws.apache.org/axis2/c.
From $HOME/Tuscany do tar xzf axis2c-bin-0.92-linux.tar.gz, this will
install Axis2C in $HOME/Tuscany/axis2c-bin-0.92-linux.
Configure your environment:
export AXIS2C_HOME=$HOME/tuscany/axis2c-bin-0.92-linux
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AXIS2C_HOME/lib


Download the Tuscany C++ code:
From $HOME/tuscany, do svn co
http://svn.apache.org/repos/asf/incubator/tuscany/cpp, this will check
out all the source code in $HOME/tuscany/cpp.

Configure your environment:
export TUSCANY_SCACPP=$HOME/tuscany/cpp/sca/deploy
export TUSCANY_SDOCPP=$HOME/tuscany/cpp/sdo/deploy
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$TUSCANY_SDOCPP/lib:$TUSCANY_SCACPP/lib

The builds use the GNU automake + configure tools, which nicely analyze
your environment and generate all the make files you need.

To build the SDO C++ runtime:
cd $HOME/tuscany/cpp/sdo
./autogen.sh
./configure --prefix=$TUSCANY_SDOCPP --enable-static=no
make
make install
cd $HOME/tuscany/cpp/sdo/samples
./autogen.sh
./configure --prefix=$TUSCANY_SDOCPP --enable-static=no
make
make install

Note: Tuscany already has build.sh scripts that do all of this for you,
but I wanted to use the individual commands to understand what was going
on at each step.
Also, when you make code changes in general you just run make and make
install and not the whole set of steps.

To run the the SDO test suite:
cd $HOME/tuscany/cpp/sdo
./sdotest.sh

To build the SCA C++ runtime:
cd $HOME/tuscany/cpp/sca
./autogen.sh
./configure --prefix=$TUSCANY_SCACPP --enable-static=no
make
make install
cd $HOME/tuscany/cpp/sdo/samples
./autogen.sh
./configure --prefix=$TUSCANY_SCACPP --enable-static=no
make
make install

To run the SCA runtime tests:
cd $HOME/tuscany/cpp/sdo
./scatest.sh

To run the SCA calculator sample:
cd $HOME/tuscany/cpp/sca/deploy/samples/Calculator/deploy/bin
./runclient.sh

Overall it was pretty simple. I hope these steps will help people set
their C++ build environment and come help us!

Could other people in the group try these steps in other environments
and see if they work for them?
Do we have similar steps for Windows?

--
Jean-Sebastien


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





--
Pete

Re: Imbedded model


On Jul 19, 2006, at 6:36 PM, Ken Tam wrote:


I'm about to check-in some code to support embedding Tuscany in any
servlet container  -- mostly a servlet listener that launches the
runtime.  It's not a lot of code (if it were, I'd be worried :), but I
could still see moving it out into a separate place in the svn tree &
build, once we figure out the layout/strategy for that.

There's currently a "runtime" dir under "sca" where the equinox OSGi
and "standalone" runtimes live.. but the standalone being just a
packaging thing, and the equinox code isn't active in the build
currently.



In another post I had proposed moving "standalone" into "distribution/ 
sca/standalone" to make it closer to what we had in M1. I was  
thinking that all assembly/packaging stuff would be there.


If we do that, then perhaps your webapp support code and the equinox  
(OSGi support) code become modules under runtime and we put all host- 
integration type stuff there.



I'm building off the core.launcher pkg, which seems flexible enough
with some tweaks.  I haven't thought too hard yet about further
modularization -- I don't grok the code well enough yet to have a
strong opinion..


Looking forward to the tweaks ;-)
--
Jeremy


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

Re: Imbedded model



On Jul 19, 2006, at 6:36 PM, Ken Tam wrote:


I'm about to check-in some code to support embedding Tuscany in any
servlet container  -- mostly a servlet listener that launches the
runtime.  It's not a lot of code (if it were, I'd be worried :), but I
could still see moving it out into a separate place in the svn tree &
build, once we figure out the layout/strategy for that.


That may be good so we're consistent across environments.


There's currently a "runtime" dir under "sca" where the equinox OSGi
and "standalone" runtimes live.. but the standalone being just a
packaging thing, and the equinox code isn't active in the build
currently.

I'm building off the core.launcher pkg, which seems flexible enough
with some tweaks.  I haven't thought too hard yet about further
modularization -- I don't grok the code well enough yet to have a
strong opinion..


4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?


This is a key question IMO.  I've been thinking mostly in terms of
Tuscany embedding in existing server environments, mostly because
those strike me as the most compelling use cases at this point (given
SCA as a technology that purports to ease integration).  But there's
no reason why it can't go the other way around  -- e.g. embedding
server functionality into Tuscany via something like jetty.  Indeed,
the current standalone is a very basic "server" that embeds Tuscany.

Yea I'm working on the Jetty service now.  I got sidetracked because  
I ran across a configuration issue doing this related to annotation  
processing (the ability to have constructor injection work with  
multiple annotation extensions) so I've been spending time on getting  
that working.



On 7/19/06, scabooz <[EMAIL PROTECTED]> wrote:

Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking.  Questions like the following come to mind:
1) Is there a distribution for imbedders?
2) Is the runtime config mechanism extensible enough?
3) Is the build modular enough to only build the pieces you
want to imbed? I saw some posts on modularizing the build
that seemed useful.

...there's many more questions...

Hopefully that's enough to provoke a discussion.


Dave Booz

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




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




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

Re: Imbedded model


Just a few minor comments inline...

On Jul 19, 2006, at 6:33 PM, Jeremy Boynes wrote:


Comments inline ...

On Jul 19, 2006, at 5:20 PM, scabooz wrote:


Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking.  Questions like the following come to mind:
1) Is there a distribution for imbedders?


There might be a more fundamental question here: what's a  
distribution?


For M1, we focused on a end-user distribution, by which I mean  
something someone could download, unpack and everything that they  
needed to run Tuscany would be there. As a result it ended by a bit  
kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,  
etc. and ended up just a tadge under 50MB in size. I don't think  
this will scale as we add more functionality.


I would suggest that we continue to produce distributions aimed at  
end-users but tailor them to particular runtime environments.  
Specific ones that come to mind would be a simple client, one with  
Tomcat, one with Celtix, one with Equinox, one with Geronimo, and  
so on. These may include the environment (like we did with Tomcat  
in M1) or they may packages that can install on top (e.g. as a CAR  
for Geronimo).


Each one of these would be tailored for the runtime - for example,  
the Tomcat one would be web-oriented, the Celtix one message- 
oriented. The baseline distribution could be extended by adding in  
plugins that would be distributed separately. This is a similar  
model to e.g. Eclipse, Maven, etc.


We would also distribute each module from the build through the  
Maven repository system. During incubation, all artifacts would be  
available from the Apache snapshot repository; post-incubation,  
released artifacts would also be available through the mirror  
system (e.g. from ibiblio.org).


Someone looking to embed Tuscany could go about it in a couple of  
ways. One would be to start with one of our distributions, take it  
apart and integrate it into their environment. This would have the  
advantage that all artifacts would have been tested to work with  
each other but may mean that they are dependent on more than they  
need or that they would have to wait for a full release to get  
fixes etc.


Alternatively they could work directly with the artifacts from the  
maven repo. In trunk we are now using the maven assembly plugin to  
build the distribution and it would be trivial for someone to  
assemble a different distribution just be reconfiguring that plugin.
One of the things we've been toying with (alluded to by Jeremy) is  
the (optional) ability for the core to pull down extension  
dependencies from maven repositories. This would be kind of like the  
server equivalent to Eclipse's plugin installation.



2) Is the runtime config mechanism extensible enough?


It's based on the SCA config mechanism so I hope so - otherwise we  
will have valuable feedback for the spec ;-)


The runtime is constructed by deploying a SCA component implemented  
by an SCA composite (which contains other SCA components). Which  
components are present are determined by the content of the  
composite and they can be configured in the same way any component  
can (including via xpath expressions once we get complex properties  
working).
Dave, it would be good if you can also outline some of the use cases  
you have in mind so we can make sure we cover them.


3) Is the build modular enough to only build the pieces you want  
to imbed? I saw some posts on modularizing the build

that seemed useful.


At this point probably not - for example, in order to work around  
the issues building JAXB Meeraj had to hack a couple of the pom  
files and that is not very desirable. As you said there have been a  
couple of posts on making the build more modular and it may be  
better to continue on that thread.



4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?



I consider the "core" to be the bit that is always embedded in some  
host environment, with the core being the bit that provides the  
SPIs and the framework for running system services. The host is  
responsible for bootstrapping the basic runtime and for determining  
which services will be started. Such services will include things  
like programming models, bindings and policies as well as normal  
application components.


Different hosts will start different services depending on what  
type of host they are. Some may just be clients, some may start  
"server" services in Tuscany and some may start "bridge" services  
that transfer function between the host and the Tuscany run

Re: Imbedded model

2006-07-19 Thread Ken Tam


I'm about to check-in some code to support embedding Tuscany in any
servlet container  -- mostly a servlet listener that launches the
runtime.  It's not a lot of code (if it were, I'd be worried :), but I
could still see moving it out into a separate place in the svn tree &
build, once we figure out the layout/strategy for that.

There's currently a "runtime" dir under "sca" where the equinox OSGi
and "standalone" runtimes live.. but the standalone being just a
packaging thing, and the equinox code isn't active in the build
currently.

I'm building off the core.launcher pkg, which seems flexible enough
with some tweaks.  I haven't thought too hard yet about further
modularization -- I don't grok the code well enough yet to have a
strong opinion..


4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?


This is a key question IMO.  I've been thinking mostly in terms of
Tuscany embedding in existing server environments, mostly because
those strike me as the most compelling use cases at this point (given
SCA as a technology that purports to ease integration).  But there's
no reason why it can't go the other way around  -- e.g. embedding
server functionality into Tuscany via something like jetty.  Indeed,
the current standalone is a very basic "server" that embeds Tuscany.

On 7/19/06, scabooz <[EMAIL PROTECTED]> wrote:

Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking.  Questions like the following come to mind:
1) Is there a distribution for imbedders?
2) Is the runtime config mechanism extensible enough?
3) Is the build modular enough to only build the pieces you
want to imbed? I saw some posts on modularizing the build
that seemed useful.

...there's many more questions...

Hopefully that's enough to provoke a discussion.


Dave Booz

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




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

Re: Imbedded model


Comments inline ...

On Jul 19, 2006, at 5:20 PM, scabooz wrote:


Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking.  Questions like the following come to mind:
1) Is there a distribution for imbedders?


There might be a more fundamental question here: what's a distribution?

For M1, we focused on a end-user distribution, by which I mean  
something someone could download, unpack and everything that they  
needed to run Tuscany would be there. As a result it ended by a bit  
kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,  
etc. and ended up just a tadge under 50MB in size. I don't think this  
will scale as we add more functionality.


I would suggest that we continue to produce distributions aimed at  
end-users but tailor them to particular runtime environments.  
Specific ones that come to mind would be a simple client, one with  
Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so  
on. These may include the environment (like we did with Tomcat in M1)  
or they may packages that can install on top (e.g. as a CAR for  
Geronimo).


Each one of these would be tailored for the runtime - for example,  
the Tomcat one would be web-oriented, the Celtix one message- 
oriented. The baseline distribution could be extended by adding in  
plugins that would be distributed separately. This is a similar model  
to e.g. Eclipse, Maven, etc.


We would also distribute each module from the build through the Maven  
repository system. During incubation, all artifacts would be  
available from the Apache snapshot repository; post-incubation,  
released artifacts would also be available through the mirror system  
(e.g. from ibiblio.org).


Someone looking to embed Tuscany could go about it in a couple of  
ways. One would be to start with one of our distributions, take it  
apart and integrate it into their environment. This would have the  
advantage that all artifacts would have been tested to work with each  
other but may mean that they are dependent on more than they need or  
that they would have to wait for a full release to get fixes etc.


Alternatively they could work directly with the artifacts from the  
maven repo. In trunk we are now using the maven assembly plugin to  
build the distribution and it would be trivial for someone to  
assemble a different distribution just be reconfiguring that plugin.



2) Is the runtime config mechanism extensible enough?


It's based on the SCA config mechanism so I hope so - otherwise we  
will have valuable feedback for the spec ;-)


The runtime is constructed by deploying a SCA component implemented  
by an SCA composite (which contains other SCA components). Which  
components are present are determined by the content of the composite  
and they can be configured in the same way any component can  
(including via xpath expressions once we get complex properties  
working).


3) Is the build modular enough to only build the pieces you want to  
imbed? I saw some posts on modularizing the build

that seemed useful.


At this point probably not - for example, in order to work around the  
issues building JAXB Meeraj had to hack a couple of the pom files and  
that is not very desirable. As you said there have been a couple of  
posts on making the build more modular and it may be better to  
continue on that thread.



4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?



I consider the "core" to be the bit that is always embedded in some  
host environment, with the core being the bit that provides the SPIs  
and the framework for running system services. The host is  
responsible for bootstrapping the basic runtime and for determining  
which services will be started. Such services will include things  
like programming models, bindings and policies as well as normal  
application components.


Different hosts will start different services depending on what type  
of host they are. Some may just be clients, some may start "server"  
services in Tuscany and some may start "bridge" services that  
transfer function between the host and the Tuscany runtime.



...there's many more questions...


We probably should work on a guide for embedding Tuscany with more  
information on the bootstrap APIs. So, ask away so we can get the  
right information there and tidy up the JavaDoc.


--
Jeremy


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

Imbedded model

2006-07-19 Thread scabooz


Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking.  Questions like the following come to mind:
1) Is there a distribution for imbedders?
2) Is the runtime config mechanism extensible enough?
3) Is the build modular enough to only build the pieces you 
want to imbed? I saw some posts on modularizing the build

that seemed useful.
4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?

...there's many more questions...

Hopefully that's enough to provoke a discussion.


Dave Booz

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

[C++] Steps to setup a Tuscany C++ development and build environment

2006-07-19 Thread Jean-Sebastien Delfino

I just finished setting up a Tuscany C++ development and build 
environment on my Linux machine and thought it would be useful to share 
the steps I went through.


I am using Redhat Linux Enterprise 4, but the same steps should work on 
other Linux systems like Fedora Core or Ubuntu for example.
These steps take no more than 15 mns to complete, starting from scratch. 
After you complete them you should be all set to build the Tuscany C++ 
runtime, and start contributing :)


From a shell prompt, create a $HOME/tuscany directory.

Install the following prerequisites:

* Subversion - SVN version 1.3.0 or later is good (most Linux distros 
already include SVN).


* Ant and a Java JDK are required by the SCA code generation tool used 
to generate proxies and wrappers for C++ components.
Download apache-ant-1.6.5-bin.tar.gz from 
http://ant.apache.org/bindownload.cgi.

From $HOME/tuscany do tar xzf apache-ant-1.6.5-bin.tar.gz.
Configure your environment:
export ANT_HOME=$HOME/tuscany/apache-ant-1.6.5
PATH=$ANT_HOME/bin:$PATH

Download jdk-1_5_0_06-linux-i586.bin from 
http://java.sun.com/j2se/1.5.0/download.jsp.
From $HOME/tuscany run jdk-1_5_0_06-linux-i586.bin, this will extract 
the JDK in $HOME/tuscany/jdk1.5.0_06.

Configure your environment:
export JAVA_HOME=$HOME/tuscany/jdk1.5.0_06
PATH=$JAVA_HOME/bin:$PATH

* Libxml2 2.6.20 or later
Libxml2 is already in most Linux distros, just check that you have 
version 2.6.20 or later (my RHEL4 system had an older version and I had 
to upgrade it).
To see which version of libxml2 is installed on your system do rpm -aq | 
grep libxml2.

Configure your environment:
export LIBXML2_LIB=/usr/lib
export LIBXML2_INCLUDE=/usr/include/libxml2

* Axis2C version 0.92
Download axis2c-bin-0.92-linux.tar.gz from http://ws.apache.org/axis2/c.
From $HOME/Tuscany do tar xzf axis2c-bin-0.92-linux.tar.gz, this will 
install Axis2C in $HOME/Tuscany/axis2c-bin-0.92-linux.

Configure your environment:
export AXIS2C_HOME=$HOME/tuscany/axis2c-bin-0.92-linux
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AXIS2C_HOME/lib


Download the Tuscany C++ code:
From $HOME/tuscany, do svn co 
http://svn.apache.org/repos/asf/incubator/tuscany/cpp, this will check 
out all the source code in $HOME/tuscany/cpp.


Configure your environment:
export TUSCANY_SCACPP=$HOME/tuscany/cpp/sca/deploy
export TUSCANY_SDOCPP=$HOME/tuscany/cpp/sdo/deploy
export 
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$TUSCANY_SDOCPP/lib:$TUSCANY_SCACPP/lib


The builds use the GNU automake + configure tools, which nicely analyze 
your environment and generate all the make files you need.


To build the SDO C++ runtime:
cd $HOME/tuscany/cpp/sdo
./autogen.sh
./configure --prefix=$TUSCANY_SDOCPP --enable-static=no
make
make install
cd $HOME/tuscany/cpp/sdo/samples
./autogen.sh
./configure --prefix=$TUSCANY_SDOCPP --enable-static=no
make
make install

Note: Tuscany already has build.sh scripts that do all of this for you, 
but I wanted to use the individual commands to understand what was going 
on at each step.
Also, when you make code changes in general you just run make and make 
install and not the whole set of steps.


To run the the SDO test suite:
cd $HOME/tuscany/cpp/sdo
./sdotest.sh

To build the SCA C++ runtime:
cd $HOME/tuscany/cpp/sca
./autogen.sh
./configure --prefix=$TUSCANY_SCACPP --enable-static=no
make
make install
cd $HOME/tuscany/cpp/sdo/samples
./autogen.sh
./configure --prefix=$TUSCANY_SCACPP --enable-static=no
make
make install

To run the SCA runtime tests:
cd $HOME/tuscany/cpp/sdo
./scatest.sh

To run the SCA calculator sample:
cd $HOME/tuscany/cpp/sca/deploy/samples/Calculator/deploy/bin
./runclient.sh

Overall it was pretty simple. I hope these steps will help people set 
their C++ build environment and come help us!


Could other people in the group try these steps in other environments 
and see if they work for them?

Do we have similar steps for Windows?

--
Jean-Sebastien


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

Re: Finally posted: src file header and copyright policy



On Jul 19, 2006, at 11:50 AM, Jeremy Boynes wrote:

Is this is good time to do this to the trunk (thinking that most  
people will not have any work that will conflict)?


I'll see if the tools work and if there are no issues think about  
doing this later this week.


We had a problem with some of the files not having license headers in  
them :-(
so I modified Roy's script to be a little more aggressive and replace  
everything before the "package" statement with the new header.


I ran these on a few files and they seemed to do the right thing but  
additional review would be appreciated.


--
Jeremy


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

[jira] Commented: (TUSCANY-564) BigBank tomcat test integration POM points to BEA jar file download

[ 
http://issues.apache.org/jira/browse/TUSCANY-564?page=comments#action_12422237 
] 

Pete Robbins commented on TUSCANY-564:
--

Gaah!!! So I typed in the wrong Jira number in my log message on a commit. 
Please ignore the svn commits that appear attached to this Jira. Anyone know 
how to move them?

> BigBank tomcat test integration POM points to BEA jar file download
> ---
>
> Key: TUSCANY-564
> URL: http://issues.apache.org/jira/browse/TUSCANY-564
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java BigBank Scenario
>Affects Versions: Java-M1, Java-M2
>Reporter: Luciano Resende
>
> I was trying to run java/testing/tomcat/bigbank 
> When you don't have jsr173 dependency available, you will get the following 
> from the mvn command line
>Missing:
>   --
>   1) javax.xml:jsr173:jar:1.0
>   Try downloading the file manually from:
>  http://ftpna2.bea.com/pub/downloads/jsr173.jar
>Then, install it using the command:
>  mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 
> -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> After some investigation, I found out that the 
> /java/testing/tomcat/readme.htm file have instructions on how to download 
> this dependency from XML Bean Distribution.
> Jeremy also pointed that we could exclude this one and use stax-api 
> dependency already available for other parts of the project.
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05206.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Diagram Drafts


Cool - thanks!

On Jul 19, 2006, at 12:35 PM, David Wheeler wrote:


oh, ok.
Lets try this agian zipped.

-David Wheeler

On 7/19/06, Jim Marino <[EMAIL PROTECTED] > wrote:I found out  
yesterday the list strips PDFs but if you zip them it

goes through.

Jim


On Jul 19, 2006, at 12:22 PM, David Wheeler wrote:

> Sure thing Jim.
>
> Should be attached
>
> On 7/19/06, Jim Marino < [EMAIL PROTECTED]> wrote: Hi David,
>
> Is there any chance you can pdf it?
>
> Jim
>
> On Jul 19, 2006, at 11:56 AM, David Wheeler wrote:
>
> > The original format is an Omnigraffle document, but I have  
attached
> > a zip that contains the graffle as well as copies in svg and  
visio.

> >
> > I modefied it to better reflect the seperation of the Core Runtime
> > and SDO / Tools, as well as adding Spring to the list of  
extensions.

> >
> >
> > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote: Also what is the source
> > format... anyway you can upload it ?  send email
> > attachment?
> >
> > David Wheeler wrote:
> > > Ah,
> > > I was under the impression that the other images posted so far
> > were for
> > > brain storming more than final drafts, Intented to be replaced.
> > >
> > > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:
> > >>
> > >> David,
> > >> I just checked in an overview that made it clickable with
> > another image
> > >> that was already posted.  When you click on a section it takes
> > you to
> > >> one of the  links on top.  I'm not partial, I can easily switch
> > out.
> > >>
> > >> David Wheeler wrote:
> > >> > I've come up with a couple possible diagrams for thw website
> > >> navigation:
> > >> >
> > >> > Tuscany Block Diagram-
> > >> >
> > >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> > ClickableImages/attachments/Tuscany-Block.png
> > >>
> > >> >
> > >> >
> > >> > SCA Diagram-
> > >> >
> > >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> > ClickableImages/attachments/Tusc-SCA-Diagram.png
> > >>
> > >> >
> > >> >
> > >> > Let me know what you guys think.
> > >> >
> > >> > -David Wheeler
> > >> >
> > >>
> > >>
> > >>
> >
>  
-

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

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

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

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

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


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



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



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

Re: Diagram Drafts

I found out yesterday the list strips PDFs but if you zip them it  
goes through.


Jim


On Jul 19, 2006, at 12:22 PM, David Wheeler wrote:


Sure thing Jim.

Should be attached

On 7/19/06, Jim Marino <[EMAIL PROTECTED]> wrote: Hi David,

Is there any chance you can pdf it?

Jim

On Jul 19, 2006, at 11:56 AM, David Wheeler wrote:

> The original format is an Omnigraffle document, but I have attached
> a zip that contains the graffle as well as copies in svg and visio.
>
> I modefied it to better reflect the seperation of the Core Runtime
> and SDO / Tools, as well as adding Spring to the list of extensions.
>
>
> On 7/19/06, Rick <[EMAIL PROTECTED]> wrote: Also what is the source
> format... anyway you can upload it ?  send email
> attachment?
>
> David Wheeler wrote:
> > Ah,
> > I was under the impression that the other images posted so far
> were for
> > brain storming more than final drafts, Intented to be replaced.
> >
> > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:
> >>
> >> David,
> >> I just checked in an overview that made it clickable with
> another image
> >> that was already posted.  When you click on a section it takes
> you to
> >> one of the  links on top.  I'm not partial, I can easily switch
> out.
> >>
> >> David Wheeler wrote:
> >> > I've come up with a couple possible diagrams for thw website
> >> navigation:
> >> >
> >> > Tuscany Block Diagram-
> >> >
> >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> ClickableImages/attachments/Tuscany-Block.png
> >>
> >> >
> >> >
> >> > SCA Diagram-
> >> >
> >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> ClickableImages/attachments/Tusc-SCA-Diagram.png
> >>
> >> >
> >> >
> >> > Let me know what you guys think.
> >> >
> >> > -David Wheeler
> >> >
> >>
> >>
> >>
>  
-

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

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

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


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


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



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

Re: Diagram Drafts

2006-07-19 Thread David Wheeler

Sure thing Jim.Should be attachedOn 7/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi David,Is there any chance you can pdf it?JimOn Jul 19, 2006, at 11:56 AM, David Wheeler wrote:
> The original format is an Omnigraffle document, but I have attached> a zip that contains the graffle as well as copies in svg and visio.>> I modefied it to better reflect the seperation of the Core Runtime
> and SDO / Tools, as well as adding Spring to the list of extensions.>>> On 7/19/06, Rick <[EMAIL PROTECTED]> wrote: Also what is the source> format... anyway you can upload it ?  send email
> attachment?>> David Wheeler wrote:> > Ah,> > I was under the impression that the other images posted so far> were for> > brain storming more than final drafts, Intented to be replaced.
> >> > On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:> >>> >> David,> >> I just checked in an overview that made it clickable with
> another image> >> that was already posted.  When you click on a section it takes> you to> >> one of the  links on top.  I'm not partial, I can easily switch> out.> >>
> >> David Wheeler wrote:> >> > I've come up with a couple possible diagrams for thw website> >> navigation:> >> >> >> > Tuscany Block Diagram-
> >> >> >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)> ClickableImages/attachments/Tuscany-Block.png> >>
> >> >> >> >> >> > SCA Diagram-> >> >> >> http://wiki.apache.org/ws-data/attachments/Tuscany(2f)
> ClickableImages/attachments/Tusc-SCA-Diagram.png> >>> >> >> >> >> >> > Let me know what you guys think.> >> >> >> > -David Wheeler
> >> >> >>> >>> >>> -> >> To unsubscribe, e-mail: 
[EMAIL PROTECTED]> >> For additional commands, e-mail: [EMAIL PROTECTED]> >>> >>> >
>>> -> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]>>> > -
> To unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]
-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: 
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Diagram Drafts


Hi David,

Is there any chance you can pdf it?

Jim

On Jul 19, 2006, at 11:56 AM, David Wheeler wrote:

The original format is an Omnigraffle document, but I have attached  
a zip that contains the graffle as well as copies in svg and visio.


I modefied it to better reflect the seperation of the Core Runtime  
and SDO / Tools, as well as adding Spring to the list of extensions.



On 7/19/06, Rick <[EMAIL PROTECTED]> wrote: Also what is the source  
format... anyway you can upload it ?  send email

attachment?

David Wheeler wrote:
> Ah,
> I was under the impression that the other images posted so far  
were for

> brain storming more than final drafts, Intented to be replaced.
>
> On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:
>>
>> David,
>> I just checked in an overview that made it clickable with  
another image
>> that was already posted.  When you click on a section it takes  
you to
>> one of the  links on top.  I'm not partial, I can easily switch  
out.

>>
>> David Wheeler wrote:
>> > I've come up with a couple possible diagrams for thw website
>> navigation:
>> >
>> > Tuscany Block Diagram-
>> >
>> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
ClickableImages/attachments/Tuscany-Block.png

>>
>> >
>> >
>> > SCA Diagram-
>> >
>> http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
ClickableImages/attachments/Tusc-SCA-Diagram.png

>>
>> >
>> >
>> > Let me know what you guys think.
>> >
>> > -David Wheeler
>> >
>>
>>
>>  
-

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


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



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



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

Re: Finally posted: src file header and copyright policy

Is this is good time to do this to the trunk (thinking that most  
people will not have any work that will conflict)?


I'll see if the tools work and if there are no issues think about  
doing this later this week.

--
Jeremy

On Jul 17, 2006, at 10:32 AM, Jeremy Boynes wrote:

Heads up of an upcoming policy change that means we will need to  
update the license boilerplate in our code.

--
Jeremy

Begin forwarded message:


From: "Cliff Schmidt" <[EMAIL PROTECTED]>
Date: July 16, 2006 11:39:37 PM PDT
To: legal-discuss@apache.org
Subject: Finally posted: src file header and copyright policy

Hey legal-discuss folks,

I've finally posted the "Source Header and Copyright Notice Policy":
http://www.apache.org/legal/src-headers.html.

It's pretty much the same thing I sent to this list a few weeks ago,
plus a FAQ that summarizes the follow-on discussion we had.

As I've mentioned before, my plan is to finish up the other two  
pieces

and send an email to committers@ with links to all three legal pages.
There's a good possibility I'll have these other two done in the next
couple days, but I thought I'd put this out for legal-discuss review
since it is ready now.

Let me know if you see anything in there that doesn't make sense.

Cliff

-
DISCLAIMER: Discussions on this list are informational and  
educational

only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See  for
official ASF policies and documents.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




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




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

Re: Diagram Drafts

2006-07-19 Thread Rick

Also what is the source format... anyway you can upload it ?  send email 
attachment?

David Wheeler wrote:

Ah,
I was under the impression that the other images posted so far were for
brain storming more than final drafts, Intented to be replaced.

On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:

David,
I just checked in an overview that made it clickable with another image
that was already posted.  When you click on a section it takes you to
one of the  links on top.  I'm not partial, I can easily switch out.

David Wheeler wrote:
> I've come up with a couple possible diagrams for thw website 
navigation:

>
> Tuscany Block Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png 

>
>
> SCA Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png 

>
>
> Let me know what you guys think.
>
> -David Wheeler
>

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

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

Re: Tackling build problems



On Jul 19, 2006, at 11:00 AM, Jeremy Boynes wrote:

One thing we ran into with chianti was problems in the build due to  
the availability of dependencies that are only used in a few  
places. For example, there were repeated problems building the JAXB  
databinding due to downtime at java.net. This isn't new - for  
example, I remember in M1 we had problems building SDO due to  
issues with the Eclipse repository.


I like the idea of being able to build everything in one go. That's  
what happens now when you type mvn at the root of a fresh checkout  
and I think that should still work. The problem comes when it  
doesn't and new users end up fighting just to get their first build  
done.


We also have some fairly large areas that are independent of each  
other. For example, I think someone interested in SDO should be  
able to check out just the sdo tree and have that build on its own.


There are some dependencies though between these areas - for  
example, the current sca trunk depends on the sdo trunk  
(specifically the 1.0-SNAPSHOT version). These are not so coupled  
that they need the absolute latest code so one way to handle that  
would be to publish nightly (or other unstable) builds to the  
apache snapshot repository. This is not a release and hence does  
not need a vote etc.


We can tackle the build problems this way as well. For example,  
modules that have dependencies whose availability is flakey could  
be moved to a section of the build that was optional and which  
could be enabled or disabled using maven profiles.


I think it should not just be based on reliability of the download  
although that is a good practical concern. Rather, I would like to  
decouple the various runtime subsystems based on "optionality" and  
have that reflected in the build structure. For example, the Java SCA  
runtime does not require JAXB or SDO, hence they should not be  
required to build the core. Extensions such as the SDO and JAXB data  
transformation service may require those technologies so they should  
be separated out into an extensions area that builds independently of  
the core. The existence of the SPI (as well as potential integration  
testing) should provide assurance that changes to the core  
implementation do not break those extensions.


I think this approach will allow us to better modularize the runtime  
and segment it so that newbies wanting to contribute are not  
confronted with a monolith.  It will also allow us IMO to scale our  
ability to handle extensions better.


Jim



Is this kind of modularization worth tackling?


Yep

--
Jeremy


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




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

Re: Diagram Drafts

These look nice. A couple of comments:

1. For extensions, can we include Spring as that has a lot of  
widespread appeal and is something we are actively working on?
2. Is there a way to make the ancillary technologies such as DAS, SDO  
and Tooling fit outside the core runtime, as they are not embedded?  
Perhaps having something that shows them being plugged in, maybe as  
extensions?

Jim

On Jul 19, 2006, at 11:05 AM, David Wheeler wrote:

Ah,
I was under the impression that the other images posted so far were  
for

brain storming more than final drafts, Intented to be replaced.

On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:

David,
I just checked in an overview that made it clickable with another  
image

that was already posted.  When you click on a section it takes you to
one of the  links on top.  I'm not partial, I can easily switch out.

David Wheeler wrote:
> I've come up with a couple possible diagrams for thw website  
navigation:

>
> Tuscany Block Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
ClickableImages/attachments/Tuscany-Block.png

>
>
> SCA Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f) 
ClickableImages/attachments/Tusc-SCA-Diagram.png

>
>
> Let me know what you guys think.
>
> -David Wheeler
>

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

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

Re: Diagram Drafts

2006-07-19 Thread cr22rc

By the way is this the general idea what people had in mind what this 
overview image ought to do? 
Rick wrote:

David,
I just checked in an overview that made it clickable with another 
image that was already posted.  When you click on a section it takes 
you to one of the  links on top.  I'm not partial, I can easily switch 
out.


David Wheeler wrote:

I've come up with a couple possible diagrams for thw website navigation:

Tuscany Block Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png 



SCA Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png 



Let me know what you guys think.

-David Wheeler




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





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

Re: Diagram Drafts

2006-07-19 Thread David Wheeler

Ah,
I was under the impression that the other images posted so far were for
brain storming more than final drafts, Intented to be replaced.

On 7/19/06, Rick <[EMAIL PROTECTED]> wrote:

David,
I just checked in an overview that made it clickable with another image
that was already posted.  When you click on a section it takes you to
one of the  links on top.  I'm not partial, I can easily switch out.

David Wheeler wrote:
> I've come up with a couple possible diagrams for thw website navigation:
>
> Tuscany Block Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png
>
>
> SCA Diagram-
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png
>
>
> Let me know what you guys think.
>
> -David Wheeler
>

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

Tackling build problems

One thing we ran into with chianti was problems in the build due to  
the availability of dependencies that are only used in a few places.  
For example, there were repeated problems building the JAXB  
databinding due to downtime at java.net. This isn't new - for  
example, I remember in M1 we had problems building SDO due to issues  
with the Eclipse repository.


I like the idea of being able to build everything in one go. That's  
what happens now when you type mvn at the root of a fresh checkout  
and I think that should still work. The problem comes when it doesn't  
and new users end up fighting just to get their first build done.


We also have some fairly large areas that are independent of each  
other. For example, I think someone interested in SDO should be able  
to check out just the sdo tree and have that build on its own.


There are some dependencies though between these areas - for example,  
the current sca trunk depends on the sdo trunk (specifically the 1.0- 
SNAPSHOT version). These are not so coupled that they need the  
absolute latest code so one way to handle that would be to publish  
nightly (or other unstable) builds to the apache snapshot repository.  
This is not a release and hence does not need a vote etc.


We can tackle the build problems this way as well. For example,  
modules that have dependencies whose availability is flakey could be  
moved to a section of the build that was optional and which could be  
enabled or disabled using maven profiles.


Is this kind of modularization worth tackling?
--
Jeremy


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

Re: Diagram Drafts

2006-07-19 Thread Rick


David,
I just checked in an overview that made it clickable with another image 
that was already posted.  When you click on a section it takes you to 
one of the  links on top.  I'm not partial, I can easily switch out.


David Wheeler wrote:

I've come up with a couple possible diagrams for thw website navigation:

Tuscany Block Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png 



SCA Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png 



Let me know what you guys think.

-David Wheeler




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

Diagram Drafts

2006-07-19 Thread David Wheeler


I've come up with a couple possible diagrams for thw website navigation:

Tuscany Block Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png

SCA Diagram-
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png

Let me know what you guys think.

-David Wheeler

Chianti moved to trunk

I have now moved all the code from chianti into the trunk and have  
reset version numbers across the board to 1.0-SNAPSHOT. However, I  
think a little more re-organization could be done to match this  
closer to the old trunk.


Firstly, back to the age-old question of where should the samples go?  
They are currently in ~/sca/samples so I would suggest that they move  
to ~/samples/sca as before.


There are no application level samples yet (e.g. bigbank) so we need  
to work on getting those back in and I would suggest they go in ~/ 
sampleapps as before.


Secondly, we assemble distributions in the ~/sca/runtime module and I  
would suggest these move to ~/distribution/sca


This sound ok?
--
Jeremy


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

Re: How to deal with spec-related issues

Right now Jeremy and I have been doing this as we are members of the  
spec group as well. However, there is no reason others can't do this  
as well. There will be a new OSOA website (mentioned by Raymond)  
where issues can be raised directly so this may facilitate that process.


Jim


On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote:


Is the spec group pulling proposals from Tuscany wiki?
If not, maybe we need to push the proposals to the spec group and  
we may

need a process.


On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote:

> Hi,
>
> When we implement Tuscany, once a while we run into issues/holes/
> missing features in the SCA spec (SDO in some cases). I'm wondering
> if we have an open source endorsed process on how to deal with such
> issues. Because they may impact the programming model (the way how
> users use SCA or SDO), I think we should be extra cautious on
> making decisions.
>
> Here're a list of things I can see:
>
> 1) Capture the requirement (problem statement)
> 2) Make proposals (could be more than one, maybe with prototypes in
> sandbox?)
> 3) Reach consenus in the community by discussions
> 4) Present the proposal to the spec group
> 5) Conclude if it will be become an official spec feature (if
> accepted by the spec group) or a tuscany-specific extension (we
> should use tuscany namespace to model SCDL extensions if required)
> 5) Make changes in the code base with an agreed solution
>
> I suggest that we keep track of them on the Tuscany wiki site.
>
> What do you guys think?

Sounds good.

I did something like this for the CDI proposal - there is a page on
the wiki at:
http://wiki.apache.org/ws/Tuscany/SpecProposals

--
Jeremy



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





--

Yang ZHONG



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

Re: How to deal with spec-related issues


On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote:


Is the spec group pulling proposals from Tuscany wiki?
If not, maybe we need to push the proposals to the spec group and  
we may

need a process.


There is precedent for that - for the CDI proposal I just sent a link  
to the wiki page to the spec mailing list.


--
Jeremy


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

Re: How to deal with spec-related issues

2006-07-19 Thread Yang ZHONG


Is the spec group pulling proposals from Tuscany wiki?
If not, maybe we need to push the proposals to the spec group and we may
need a process.


On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote:

> Hi,
>
> When we implement Tuscany, once a while we run into issues/holes/
> missing features in the SCA spec (SDO in some cases). I'm wondering
> if we have an open source endorsed process on how to deal with such
> issues. Because they may impact the programming model (the way how
> users use SCA or SDO), I think we should be extra cautious on
> making decisions.
>
> Here're a list of things I can see:
>
> 1) Capture the requirement (problem statement)
> 2) Make proposals (could be more than one, maybe with prototypes in
> sandbox?)
> 3) Reach consenus in the community by discussions
> 4) Present the proposal to the spec group
> 5) Conclude if it will be become an official spec feature (if
> accepted by the spec group) or a tuscany-specific extension (we
> should use tuscany namespace to model SCDL extensions if required)
> 5) Make changes in the code base with an agreed solution
>
> I suggest that we keep track of them on the Tuscany wiki site.
>
> What do you guys think?

Sounds good.

I did something like this for the CDI proposal - there is a page on
the wiki at:
http://wiki.apache.org/ws/Tuscany/SpecProposals

--
Jeremy



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





--

Yang ZHONG

Re: Axis binding for chianti

2006-07-19 Thread Raymond Feng


Hi,

Sorry for the late reply. I got it from www.osoa.org. I think Jim's latest 
post can give you the answer.


Thanks,
Raymond

- Original Message - 
From: "Liu, Jervis" <[EMAIL PROTECTED]>

To: ; 
Sent: Friday, July 14, 2006 7:52 PM
Subject: RE: Axis binding for chianti


Hi Raymond, could you point out a place where I can take a look at the 
SCA/WS spec you just mentioned?


Thanks
Jervis


-Original Message-
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: 7/14/2006 (星期五) 11:32 下午
To: tuscany-dev@ws.apache.org
Cc:
Subject: Re: Axis binding for chianti

I would be also interested in the Axis2 integration (and potentially JAX-WS)
. Should we consider to implement the SCA/WS spec draft?

Thanks,
Raymond

- Original Message - 
From: "Liu, Jervis" <[EMAIL PROTECTED]>

To: 
Sent: Friday, July 14, 2006 12:31 AM
Subject: RE: Axis binding for chianti


Hi Jeremy, simply copying M1 to chianti wont build, it needs some tweaks. I
think I can do this, and I will submit a patch later on.

Thanks,
Jervis

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Friday, July 14, 2006 1:16 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Axis binding for chianti


On Jul 13, 2006, at 8:33 PM, Liu, Jervis wrote:


Hi, I would like to work on Axis2 binding. So the initial work
would be migrating privious M1 axis2 binding to Chianti. Also I
think this work is helpful to identify a common base for ws
bindings such as Axis2 and Celtix. BTW, for your information,
Celtix and XFire are under the merging process. A merge proposal
has been submitted to Apache. http://wiki.apache.org/incubator/
CeltiXfireProposal



Jervis, great, thanks. If you're going to work on this, I'll start on
some of the extension stuff.

Should I copy the M1 binding down into chianti to provide a baseline?

--
Jeremy

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


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


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






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

Re: SCA Specs


There are a number of ways to do this:

- If you are employed by one of the collaborators, you already have  
access

- You can become a participant in the collaboration
- The spec group is in the process of constructing a web site with  
access to the documents, which will be available very shortly.


Let me know if you fall under option 2 and I can help out.

Jim

On Jul 19, 2006, at 5:51 AM, Venkata Krishnan wrote:


Hi Jeremy / Jim,

Where can I get hold of the specs in its current version which is  
under

development?  Could you point me to it?

Thanks

- Venkat



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

Re: How to deal with spec-related issues


On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote:


Hi,

When we implement Tuscany, once a while we run into issues/holes/ 
missing features in the SCA spec (SDO in some cases). I'm wondering  
if we have an open source endorsed process on how to deal with such  
issues. Because they may impact the programming model (the way how  
users use SCA or SDO), I think we should be extra cautious on  
making decisions.


Here're a list of things I can see:

1) Capture the requirement (problem statement)
2) Make proposals (could be more than one, maybe with prototypes in  
sandbox?)

3) Reach consenus in the community by discussions
4) Present the proposal to the spec group
5) Conclude if it will be become an official spec feature (if  
accepted by the spec group) or a tuscany-specific extension (we  
should use tuscany namespace to model SCDL extensions if required)

5) Make changes in the code base with an agreed solution

I suggest that we keep track of them on the Tuscany wiki site.

What do you guys think?


Sounds good.

I did something like this for the CDI proposal - there is a page on  
the wiki at:

http://wiki.apache.org/ws/Tuscany/SpecProposals

--
Jeremy



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

How to deal with spec-related issues

2006-07-19 Thread Raymond Feng

Hi,

When we implement Tuscany, once a while we run into issues/holes/missing 
features in the SCA spec (SDO in some cases). I'm wondering if we have an open 
source endorsed process on how to deal with such issues. Because they may 
impact the programming model (the way how users use SCA or SDO), I think we 
should be extra cautious on making decisions.

Here're a list of things I can see:

1) Capture the requirement (problem statement)
2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 
3) Reach consenus in the community by discussions
4) Present the proposal to the spec group 
5) Conclude if it will be become an official spec feature (if accepted by the 
spec group) or a tuscany-specific extension (we should use tuscany namespace to 
model SCDL extensions if required)
5) Make changes in the code base with an agreed solution

I suggest that we keep track of them on the Tuscany wiki site.

What do you guys think?

Thanks,
Raymond

Re: Moving chianti to trunk



On Jul 19, 2006, at 9:19 AM, Simon Nash wrote:


Comments inline below.

  Simon

Jim Marino wrote:


On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:

I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.
And we should. In fact, I would point them at the "new" code now,  
not  just in the future. That is the codebase chosen by the  
community.  That is our code.

Seems like we are in agreement about this.  The short-term
difficulty we have right now is that some things that used to
work in the M1 code don't currently work in chianti.  This would
be an issue for users who want to build applications using Tuscany.

If you believe the decision to adopt chianti as our code to be in   
error, you are free to ask the community to reconsider, although  
I  believe the vote last week accurately expressed the community  
will  (as willful an act as it may have been ;-) ).

I voted in favour of this adoption and I would much prefer us to
continue to move forward and not move backwards.

Of course, people can also resort to M1 if they prefer to  
experiment  with the .9 version of the SCA specification or  
features specific to  that milestone.

This is not what I had in mind.  Right now they would need to revert
to M1 if they wanted to work with Web service bindings or Tomcat
integration.  I think it is undesirable that these features are
currently coupled to the use of the 0.9 spec version.



Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.

I would imagine there is unanimous agreement on this point as we  
are  working hard to add "real-world" functionality that interests  
members  of the community.

Excellent.

Based on your statements, it sounds as if there is functionality  
you  would like to see added. The somewhat, although not  
completely,  flippant response to this is: Thanks for volunteering!
If you would like to see a particular set of functionality in  
Tuscany  you can either request it (preferably in JIRA) or develop  
it and  submit a patch. Depending on the importance of the feature  
to the  community, I suspect the latter approach has a higher  
probability of  success in the short-term. It is also the option I  
would personally  prefer as it expands the active, contributing  
segment of the community.

Sounds good.  I'll probably start with JIRAs and then get deeper into
the codebase so that I can start developing and submitting patches.


Great. Let me know how I can help with any questions.

Jim


Simon



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




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

Re: Moving chianti to trunk



On Jul 19, 2006, at 8:41 AM, Sam Ruby wrote:


Jim Marino wrote:

On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:

I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.
And we should. In fact, I would point them at the "new" code now,  
not just in the future. That is the codebase chosen by the  
community. That is our code.
If you believe the decision to adopt chianti as our code to be in  
error, you are free to ask the community to reconsider, although I  
believe the vote last week accurately expressed the community will  
(as willful an act as it may have been ;-) ).
Of course, people can also resort to M1 if they prefer to  
experiment with the .9 version of the SCA specification or  
features specific to that milestone.


If history is any guide, the path that has been chosen will result  
in another revolution in a year or so's time, reverting a number of  
architectural decisions that have been made with this revolution.  
However, not *all* will be lost as much of the additions will also  
have been retained.  What will have been lost is much time.


The Rules for Revolutionaries was penned in a time when Tomcat 4  
was poised to replace Tomcat 3.  Tomcat 5 was the inevitable result.



Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.
I would imagine there is unanimous agreement on this point as we  
are working hard to add "real-world" functionality that interests  
members of the community.
Based on your statements, it sounds as if there is functionality  
you would like to see added. The somewhat, although not  
completely, flippant response to this is: Thanks for volunteering!


Votes work best when the victors are understanding and gracious.   
This response treads awfully near towards being rather gloating.
Sorry if it sounds gloating but it was not intended that way. First,  
I wouldn't characterize the vote or decision as a matter of "victors"  
or "winners".  More importantly, my point was to reiterate that if  
someone feels a particular piece of functionality important, words  
backed by contributions go further than words alone.


If you would like to see a particular set of functionality in  
Tuscany you can either request it (preferably in JIRA) or develop  
it and submit a patch. Depending on the importance of the feature  
to the community, I suspect the latter approach has a higher  
probability of success in the short-term. It is also the option I  
would personally prefer as it expands the active, contributing  
segment of the community.


Votes in the ASF imply a level of commitment.  They mean "I will  
stand behind this course of action and make it work", not "Hey! I  
won! Deal with it!".


And I think my actions and contributions adding functionality to  
chianti have demonstrated this.


If there are things that used to work in the M1 trunk that aren't  
yet handled completely in Chianti, then I fully expect those that  
participated in this vote to pro-actively and expediently work to  
close those gaps.
That was exactly my point. That's why I've been working on closing  
the gap in areas I deem to be the most pressing (which may receive a  
different priority by others and they may choose to approach it  
differently).


And with an eye towards giving the benefit of the doubt to the  
codebase it replaces (i.e., no: see, it didn't handle this obscure  
edge case, so the entire function wasn't fully implemented in M1,  
and yes, I've been around the block once or twice).


The alternative is for the people who voted to say that the rules  
for voting weren't fully explained to them, in which case, I will  
simply say "my bad", and we can hold the vote again.


- Sam Ruby

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




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

Re: Moving chianti to trunk


Comments inline below.

  Simon

Jim Marino wrote:



On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:


I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.



And we should. In fact, I would point them at the "new" code now, not  
just in the future. That is the codebase chosen by the community.  That 
is our code.



Seems like we are in agreement about this.  The short-term
difficulty we have right now is that some things that used to
work in the M1 code don't currently work in chianti.  This would
be an issue for users who want to build applications using Tuscany.

If you believe the decision to adopt chianti as our code to be in  
error, you are free to ask the community to reconsider, although I  
believe the vote last week accurately expressed the community will  (as 
willful an act as it may have been ;-) ).



I voted in favour of this adoption and I would much prefer us to
continue to move forward and not move backwards.

Of course, people can also resort to M1 if they prefer to experiment  
with the .9 version of the SCA specification or features specific to  
that milestone.



This is not what I had in mind.  Right now they would need to revert
to M1 if they wanted to work with Web service bindings or Tomcat
integration.  I think it is undesirable that these features are
currently coupled to the use of the 0.9 spec version.



Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.



I would imagine there is unanimous agreement on this point as we are  
working hard to add "real-world" functionality that interests members  
of the community.



Excellent.

Based on your statements, it sounds as if there is functionality you  
would like to see added. The somewhat, although not completely,  
flippant response to this is: Thanks for volunteering!


If you would like to see a particular set of functionality in Tuscany  
you can either request it (preferably in JIRA) or develop it and  submit 
a patch. Depending on the importance of the feature to the  community, I 
suspect the latter approach has a higher probability of  success in the 
short-term. It is also the option I would personally  prefer as it 
expands the active, contributing segment of the community.



Sounds good.  I'll probably start with JIRAs and then get deeper into
the codebase so that I can start developing and submitting patches.

Simon



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

Re: Data binding extensions and changes to the SCA spec

2006-07-19 Thread Raymond Feng

I'll give a try.

Thanks,
Raymond

- Original Message - 
From: "Jim Marino" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, July 18, 2006 7:10 PM
Subject: Re: Data binding extensions and changes to the SCA spec

On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote:

Hi,

It should be a good fit to use Transfomation service to present  
property values in a preferred way indicated by the property receiver.

Here're some use cases I can imagine:

1) Parse the XML for a property value to create a DOM  
representation (StAX XMLStreamReader-->DOM Node)

2) Inject the property to the target instance:

For example,

@DataBinding(type="sdo", ...)
@Property
private MyProperty myProperty;

We could support the annotation but I was also thinking we could have  
a Tuscany runtime configuration set per component implementation  
type. I like the configuration approach with an attribute override  
since it allows implementation code to remain agnostic of the  
databinding unless it needs something specific (in which case it  
could use the annotation).

Raymond, do you want to take a stab at separating packages into what  
should go into an SPI and what should go into core?

Jim

Then DOM Node --> SDO DataObject can be applied.

Thanks,
Raymond

- Original Message - From: "Jim Marino"  
<[EMAIL PROTECTED]>

To: 
Sent: Tuesday, July 18, 2006 2:12 PM
Subject: Data binding extensions and changes to the SCA spec

I would like to get started on support for for XPath in SCDL as it  
is  part of the recent SCA spec changes. This will likely require   
changes  to the loader infrastructure and in particular   
StringParserPropertyFactory. Instead of having a PropertyFactory   
create an ObjectFactory responsible for returning a value that is   
injected into a component implementation instance, we will need  
to  have a more flexible approach as property values may now be  
based off  of XPath expressions to composite properties.

What I would like to propose is that we have creation of the  
ObjectFactory for the property handled by the builder in much the   
same way as it handles wires. I think we can leverage the data   
transformation service for this. In this case, the builder will  
be  given a representation of the parsed XML, probably DOM. If  
the  property value was an XPath expression, the builder will have  
to use  an XPath engine to evaluate and retrieve this actual value  
(Jaxen?)  represented as a Node. The builder will then in turn use  
the  transformation service to create a "bound type". The builder  
will  subsequently create an ObjectFactory for the bound type  
responsible  for injecting on the target component implementation  
instance. The  specific kind of ObjectFactory will depend on the  
kind of property it  is:

- If it is immutable, the builder will use a SingletonObjectFactory

- If it is mutable, but the property is configured as  
"safe" (i.e.  the component does not mutate it), the builder will  
use a SingletonObjectFactory). We can also assume by default  
values are  "safe" unless explicitly marked.

- If it is mutable, marked "not safe," and Cloneable, a  
CloningObjectFactory is used which clones on getInstance()

-If it is mutable, marked "not safe" and is not Cloneable, the   
builder avoids the call to the transformation service and instead   
uses an ObjectFactory which calls out the to transformation  
service  on every getInstance() invoke.

For some implementation types, a builder may not want to use  
ObjectFactory (perhaps the implementation just takes a DOM or  
some  other format). In that case, the builder would be free to  
use the transformation service or not.

Raymond, does this sound like it would fit with the transformation  
service? If so, I think we need to look at incorporating the base   
data transformation framework into SPI and core.

I'd also be willing to work on an XStream binding extension which   
would enable handling of basic POJO binding.

Jim

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

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

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

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

[jira] Commented: (TUSCANY-490) DataObjectPtr::getByte returns incorrect data

2006-07-19 Thread Geoff Winn (JIRA)

[ 
http://issues.apache.org/jira/browse/TUSCANY-490?page=comments#action_12422174 
] 

Geoff Winn commented on TUSCANY-490:


I have a fix for this, but it depends on the contents of the patch for 
TUSCANY-539, so I will post the patch for this one once that fix has been 
applied to the repository.

> DataObjectPtr::getByte returns incorrect data
> -
>
> Key: TUSCANY-490
> URL: http://issues.apache.org/jira/browse/TUSCANY-490
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-current
>Reporter: Andrew Borley
>Priority: Minor
>
> Some xml like 123 where the byte element contains an xsd:byte 
> type, is converted into a DataObject and then queried. 
> // returns the correct data: "123"
> const char* cs = myDataObjectPtr->getCString("byte");
> // Returns incorrect data: '1'  (Ox31) - looks like it's just taking the 
> first character, rather than converting 123 to the character '{' (Ox7B)
> char c = myDataObjectPtr->getByte("byte");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll

 [ http://issues.apache.org/jira/browse/TUSCANY-567?page=all ]

Pete Robbins reassigned TUSCANY-567:


Assignee: Pete Robbins

> SCA Calculator Sample build.cmd cannot find mspdb71.dll
> ---
>
> Key: TUSCANY-567
> URL: http://issues.apache.org/jira/browse/TUSCANY-567
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ Build, C++ SCA
>Affects Versions: Cpp-current, Cpp-M1
> Environment: Windows
>Reporter: Andrew Borley
> Assigned To: Pete Robbins
> Attachments: TUSCANY-567.patch
>
>
> SCA Calculator Sample build.cmd throws an error saying it can't find 
> mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). 
> Need to add the line:
> call vcvars32
> to the build.cmd file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-565) Windows Debug build of Calculator sample incorrect

 [ http://issues.apache.org/jira/browse/TUSCANY-565?page=all ]

Pete Robbins reassigned TUSCANY-565:


Assignee: Pete Robbins

> Windows Debug build of Calculator sample incorrect
> --
>
> Key: TUSCANY-565
> URL: http://issues.apache.org/jira/browse/TUSCANY-565
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
>Affects Versions: Cpp-M1
>Reporter: Pete Robbins
> Assigned To: Pete Robbins
> Fix For: Cpp-M1
>
>
> 1. Debug build on VC6 builds Calc.exe instead of Client.exe
> 2. deploy.cmd and wsdeploy.cmd copy Release versions of exes
> 3. VC7 debug builds Client.exe bu Calc.pdb

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Test coverage tool

2006-07-19 Thread Daniel Kulp


Point of note: for UNIT TEST code coverage, you can use the cobertura stuff 
built into maven.   Just run:

mvn cobertura:cobertura  

and it will generate a HTML coverage report for the maven module in 
target/site/cobertura


There are also some nice dependency reports that we can generate from maven:
http://mojo.codehaus.org/jdepend-maven-plugin/

Cross reference report:
http://maven.apache.org/plugins/maven-jxr-plugin/


Dan


On Tuesday July 18 2006 2:27 pm, Jim Marino wrote:
> I've been using Clover as a test coverage tool and have found it
> quite useful (http://www.cenqua.com/clover/) Licensing is free for
> open source projects and it has plugins for popular IDEs so it can be
> run as part of a standard code-test cycle (it can be toggled on and
> off).
>
> Although it is a bit indiscriminate (e.g. it flags getters and
> setters), I find it particularly helpful when writing test cases
> since it highlights untested code in the IDE. I have attached a
> sample report I just ran that shows the high level statistics from a
> run.
>
> When we get around to creating integration build infrastructure I
> would like us to examine using this and generating reports that are
> posted to a project status page since it is a good indication of
> areas that need work.
>
> It would also been nice to run a dependency analyzer periodically
> over the codebase to avoid cycles in our package structures. I've
> seen people use JDepend or SonarJ. Does anyone have experience with
> either of these two or an alternative?
>
> Jim

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

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

Re: Moving chianti to trunk

2006-07-19 Thread Sam Ruby


Jim Marino wrote:


On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:


I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.


And we should. In fact, I would point them at the "new" code now, not 
just in the future. That is the codebase chosen by the community. That 
is our code.


If you believe the decision to adopt chianti as our code to be in error, 
you are free to ask the community to reconsider, although I believe the 
vote last week accurately expressed the community will (as willful an 
act as it may have been ;-) ).


Of course, people can also resort to M1 if they prefer to experiment 
with the .9 version of the SCA specification or features specific to 
that milestone.


If history is any guide, the path that has been chosen will result in 
another revolution in a year or so's time, reverting a number of 
architectural decisions that have been made with this revolution. 
However, not *all* will be lost as much of the additions will also have 
been retained.  What will have been lost is much time.


The Rules for Revolutionaries was penned in a time when Tomcat 4 was 
poised to replace Tomcat 3.  Tomcat 5 was the inevitable result.



Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.


I would imagine there is unanimous agreement on this point as we are 
working hard to add "real-world" functionality that interests members of 
the community.


Based on your statements, it sounds as if there is functionality you 
would like to see added. The somewhat, although not completely, flippant 
response to this is: Thanks for volunteering!


Votes work best when the victors are understanding and gracious.  This 
response treads awfully near towards being rather gloating.


If you would like to see a particular set of functionality in Tuscany 
you can either request it (preferably in JIRA) or develop it and submit 
a patch. Depending on the importance of the feature to the community, I 
suspect the latter approach has a higher probability of success in the 
short-term. It is also the option I would personally prefer as it 
expands the active, contributing segment of the community.


Votes in the ASF imply a level of commitment.  They mean "I will stand 
behind this course of action and make it work", not "Hey! I won! Deal 
with it!".


If there are things that used to work in the M1 trunk that aren't yet 
handled completely in Chianti, then I fully expect those that 
participated in this vote to pro-actively and expediently work to close 
those gaps.  And with an eye towards giving the benefit of the doubt to 
the codebase it replaces (i.e., no: see, it didn't handle this obscure 
edge case, so the entire function wasn't fully implemented in M1, and 
yes, I've been around the block once or twice).


The alternative is for the people who voted to say that the rules for 
voting weren't fully explained to them, in which case, I will simply say 
"my bad", and we can hold the vote again.


- Sam Ruby

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

Re: svn commit: r423492 - /incubator/tuscany/branches/java-post-M1/

I copied the entire java tree to "java-post-M1" so that we will have  
a copy of the current trunk after the chianti switchover.


The SCA part has dependencies on a SNAPSHOT version of SDO so I  
included that in the copy so that this tree will continue to build  
even when SDO's trunk evolves.


I did not change any version information so if anyone wishes to pick  
up this branch then the changes would need to be made at that point.


--
Jeremy

On Jul 19, 2006, at 8:28 AM, [EMAIL PROTECTED] wrote:


Author: jboynes
Date: Wed Jul 19 08:28:55 2006
New Revision: 423492

URL: http://svn.apache.org/viewvc?rev=423492&view=rev
Log:
copy java trunk in preparation for chianti switch

Added:
incubator/tuscany/branches/java-post-M1/
  - copied from r423491, incubator/tuscany/java/


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




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

Re: Moving chianti to trunk

On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:

I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.

And we should. In fact, I would point them at the "new" code now, not  
just in the future. That is the codebase chosen by the community.  
That is our code.

If you believe the decision to adopt chianti as our code to be in  
error, you are free to ask the community to reconsider, although I  
believe the vote last week accurately expressed the community will  
(as willful an act as it may have been ;-) ).

Of course, people can also resort to M1 if they prefer to experiment  
with the .9 version of the SCA specification or features specific to  
that milestone.

Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.

I would imagine there is unanimous agreement on this point as we are  
working hard to add "real-world" functionality that interests members  
of the community.

Based on your statements, it sounds as if there is functionality you  
would like to see added. The somewhat, although not completely,  
flippant response to this is: Thanks for volunteering!

If you would like to see a particular set of functionality in Tuscany  
you can either request it (preferably in JIRA) or develop it and  
submit a patch. Depending on the importance of the feature to the  
community, I suspect the latter approach has a higher probability of  
success in the short-term. It is also the option I would personally  
prefer as it expands the active, contributing segment of the community.

Jim

Simon

Kenneth Tam wrote:

-0 on ordaining some kind of "official" priority for functional
equivalency with M1 -- my opinion is that at this stage in the  
project

(ie, incubation), developer community is significantly more important
than user community.  I'd rather we take a more free form stance with
respect to encouraging development in areas people find compelling
(including of course, the porting of functionality from M1).
On 7/18/06, Simon Nash <[EMAIL PROTECTED]> wrote:

It is true that users who just want a working binary download
have the M1 release to work with.  However, the Tuscany community
itself will benefit from being able to run end to end scenarios
to exercise code that they contribute to the new trunk.  So if we
do make this switch now, I believe that we need to focus as a
community on getting the new trunk into a state where it can run
end to end scenarios with comparable functionality to what we had
previously in M1.  I'd feel more comfortable if I saw comments on
this list agreeing that this should be the priority immediately
following the switch.

   Simon

Rick wrote:

> For me the vote said it all; its good to go to switch.  I think  
I can
> understand your position and probably would side with you if it  
wasn't
> for two things:  We have a release so users just wanting to  
understand
> SCA and the basics of Tuscany have something stable to work  
with.  Also
> this is just a switch,  the head of the trunk should be  
preserved in a
> branch.  Just before the switch I would recommend both have  
tags too.

> Doing this doesn't stop any discussion, it doesn't stop bringing
> function/code from the current head back in to Chianti; it even  
doesn't

> prevent in the case community decides we prefer to switch back.
>
> Simon Nash wrote:
>
>> Jeremy,
>> Before you do this, I'd prefer to see some discussion about the
>> functional differences between chianti and the current trunk code
>> and how we would see these being addressed, as I said in my
>> previous email on this subject.  What do you (or others) think
>> about this?
>>
>>   Simon
>>
>> Jeremy Boynes wrote:
>>
>>> With the vote in favour of switching, I am about to start moving
>>> chianti into trunk. I will move the current sca parts into a  
branch
>>> (branches/pre-chianti) and move the chianti code into trunk.  
I will

>>> make the version in the poms 1.0-SNAPSHOT like the SDO tree.
>>>
>>> I expect to complete this tomorrow or possibly Wed if there are
>>> build  issues. If anyone has a bunch of uncommi

Re: [jira] Updated: (TUSCANY-467) Java RMI Binding Extension

Venkat,
For solving the issue of interfaces needing to extend java.RMI.Remote
and needing to throw exceptions that extend java.RMI.RemoteException,
would it be possible to code-generate interfaces that are based on
the original POJO interfaces but conform to the RMI rules?

I would expect that EJB 3 has solved a similar problem arising from
its introduction of business interfaces. Somewhere under the covers
of an EJB3 there must be an RMI-IIOP remote interface that conforms
to the RMI rules and has the same methods as the business interface.
I am guessing that this RMI remote interface is generated from the
business interface, wither as source code or bytecode. Does anyone
happen to know more about how this works?

Simon

Venkatakrishnan (JIRA) wrote:

[ http://issues.apache.org/jira/browse/TUSCANY-467?page=all ]

Venkatakrishnan updated TUSCANY-467:

Attachment: binding.rmi.zip
hellworld-rmi-server.zip
hellworld-rmi-client.zip

This is my first shot at developing extensions. I have created a simple RMI
Binding extension. Though it works, there are some issues which had to be
worked around. I hope to resolve them with the help of the community as my
induvidual attempts have failed. Since this is still open for improvments I am
not attaching the codes for this as a patch. I have rather attached them as
project zip files that can be extracted and tried out. So play around with
them and suggest if this is useful to have and the areas that need to be taken
care of. The issues that I faced have been stated in the sub-heading 'Issues'.

Installation

You may extract the zip binding.rmi.zip into the java/sca/bindings folder and
helloworld-rmi-server.zip and helloworld-rmi-client.zip into java/samples/sca
folders in the Tuscany codebase local to your machine. These three zips
contain three projects that have been built locally and hence contain the
compiled class files. The eclipse projects have also been generated for these.
Hence you my even import these projects into your Eclipse IDE.

sample-helloworld-rmi
--
This is a sample to demonstrate rmi bindings for entry points.

1) Go to the sample-helloworld-rmi project directory. Go to the target/classes
sub directory within and start the rmiregistry. Alternatively you may start
the rmiregistry elsewhere provided the remote interfaces are in the classpath.
2) Run the class helloworld.HelloWorldServer from the helloworld-rmi project

Issues

- This is not complete in the sense that the interface
helloworld.HelloWorldService has been modified to extend from java.rmi.Remote
and the method 'getGreetings' has been modified to throw
java.rmi.RemoteException. It is essential for the remote interfaces to have
this sort of signature.

In real applications I don't think we can ask the application assemblers / developers to modify the service interfaces this way. I have tried several options in trying to maintain the HelloWorldSevice interface as it and generating a Remote interface dynamically using asm and cglib libraries, but none of them allow me to create a java interface that extends from java.rmi.Remote. I hope to be able to achieve this with some help from the community.

sample-helloworldrmiclient
--
This is a sample to demonstrate rmi bindings for external services.

1) Ensure that the HelloWorldServer under sample-helloworld-rmi is up and
running.
2) Go to the sample-helloworldrmiclient project and run the class
helloworld.HelloWorldClient with the following JVM arguments
-Djava.security.manager -Djava.security.policy=

There is a sample java.policy file in the target/classes directory of this project.

Issues
-
- Is it a good idea to load the Security Manger programmatically in the
'bindings' code or should that be left to application developers to decide.
- Should we also draw a schema for including policy statements in the sca.module file when external services are defined.

Java RMI Binding Extension
--

Key: TUSCANY-467
URL: http://issues.apache.org/jira/browse/TUSCANY-467
Project: Tuscany
Type: New Feature

Components: Java SCA Samples
Reporter: Venkatakrishnan
Priority: Minor
Attachments: binding.rmi.zip, hellworld-rmi-client.zip, hellworld-rmi-server.zip

Create Java RMI bindings for Tuscany to enable components to connect to
external RMI services and also allow components to be exposted as RM services.

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

Re: CurrentCompositeContext.getContext() in chianti?


On Jul 19, 2006, at 6:02 AM, Scott Kurz wrote:

Would you agree it would make sense for Tuscany to provide this  
function

rather than the host env?

If this is the host env's job then it must get a notification every  
time a

Composite boundary is crossed in the case of recursively nested
composites.   True it may be easy enough for the host env to set up
CurrentCompositeContext for the outermost, deployable composite  
(there's
likely a more correct term).  But it seems simpler to consistently  
have
Tuscany set up this context as a step in the invocation chain  
rather than to
have the host to have to set up the context correctly for both  
outer-level

and nested composites.

Or is there already such a notification mechanism for crossing  
Composite

boundary in effect?  (I apologize that I haven't studied the code
extensively to understand this; I'm mostly relying on learning via  
running

samples and stepping through the debugger).


The host env is responsible for setting this up for unmanaged code  
i.e. code that is running that is not managed by the Tuscany runtime.  
By definition, the runtime can't do this (I'm classifying launcher a  
host code not runtime code).


Once we have entered managed code then the runtime takes over. It is  
responsible for creating the invocation chains and would handle the  
context switch as appropriate - I was thinking this would be in the  
code that supports Services exposed by a Composite; I don't think  
it's there yet. It may well need to set the Thread context  
ClassLoader at the same time.


All this switching makes me worried, especially when we have closely  
coupled composites. Having to intercept every call to a component  
implemented by a composite just to reset context that is never used  
seems like a lot of overhead. In addition, references to services  
obtained this way bypass all the context associated with a component  
(for example, policy information defined on a reference). I would  
like to see this API go away do that it cannot be used from within  
managed code, with us finding a simpler solution for unmanaged code.


--
Jeremy


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

[jira] Updated: (TUSCANY-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll

2006-07-19 Thread Andrew Borley (JIRA)

 [ http://issues.apache.org/jira/browse/TUSCANY-567?page=all ]

Andrew Borley updated TUSCANY-567:
--

Attachment: TUSCANY-567.patch

Patch adds the vcvars32 call

> SCA Calculator Sample build.cmd cannot find mspdb71.dll
> ---
>
> Key: TUSCANY-567
> URL: http://issues.apache.org/jira/browse/TUSCANY-567
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ Build, C++ SCA
>Affects Versions: Cpp-current, Cpp-M1
> Environment: Windows
>Reporter: Andrew Borley
> Attachments: TUSCANY-567.patch
>
>
> SCA Calculator Sample build.cmd throws an error saying it can't find 
> mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). 
> Need to add the line:
> call vcvars32
> to the build.cmd file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll

2006-07-19 Thread Andrew Borley (JIRA)

SCA Calculator Sample build.cmd cannot find mspdb71.dll
---

 Key: TUSCANY-567
 URL: http://issues.apache.org/jira/browse/TUSCANY-567
 Project: Tuscany
  Issue Type: Bug
  Components: C++ Build, C++ SCA
Affects Versions: Cpp-current, Cpp-M1
 Environment: Windows
Reporter: Andrew Borley


SCA Calculator Sample build.cmd throws an error saying it can't find 
mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). 
Need to add the line:
call vcvars32
to the build.cmd file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Off Topic - Subclipse observation

2006-07-19 Thread Simon Laws


I have just worked out why I have observed confusing behaviour with
subclipse. I am playing with Jeremy's new web site layout in the sandbox so
wanted to update to his latest files.

I have the tuscany project checked out in my workspace so I navigated to
sandbox/site, right clicked to team/synchronize with repository
This poped up the team synchronize view with something like the following
tree view on the left hand side

tuscany
  sandbox/site
  sandbox/site/site-author
 some files
  sandbox/site/site-deploy
 some more files

I wanted all this stuff so I clicked at the top level and selected update.

What this appears to do is update to whole of the tuscany project not just
the subset of files shown to be different in the synchronize view. This
leads to a VERY long update which invariably fails. As it fails for me so
often before it actually starts downloading anything this took me a few goes
to work out what was going on.
What I have to do is select each directory in this view and ask it to be
updated individually.

I have a slightly old version so I'm going to upgrade to see if that changes
the behaviour.

Re: CurrentCompositeContext.getContext() in chianti?

2006-07-19 Thread Scott Kurz

Would you agree it would make sense for Tuscany to provide this function
rather than the host env?

If this is the host env's job then it must get a notification every time a
Composite boundary is crossed in the case of recursively nested
composites.   True it may be easy enough for the host env to set up
CurrentCompositeContext for the outermost, deployable composite (there's
likely a more correct term).  But it seems simpler to consistently have
Tuscany set up this context as a step in the invocation chain rather than to
have the host to have to set up the context correctly for both outer-level
and nested composites.

Or is there already such a notification mechanism for crossing Composite
boundary in effect?  (I apologize that I haven't studied the code
extensively to understand this; I'm mostly relying on learning via running
samples and stepping through the debugger).

Scott

On 7/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

Responsibility still lies with the host environment.

In the launcher's case, it is the J2SE (command line) host
environment so it sets up the context before calling the application
code; it is kind of similar to a J2EE application client container.

We do a similar thing in SCATestCase to set up the environment before
calling the user's TestCase (we do it in setUp).

--
Jeremy

On Jul 18, 2006, at 6:52 PM, Scott Kurz wrote:

> Does Tuscany, now with Chianti, take responsibility for setting up the
> CurrentCompositeContext?
>
> When I last understood the relevant code, at M1, Tuscany was more
> or less
> requiring the host environment to set this up (then
> CurrentModuleContext).
> This was done with Tomcat via the TuscanyValve, for example, (which
> I'm not
> counting as part of Tuscany proper).
>
> I see in chianti that
> org.apache.tuscany.core.launcher.CompositeContextImplis setting up
> CurrentCompositeContext but I'm not sure what to make of
> this.   Is Tuscany already setting up CurrentCompositeContext or
> might this
> be an area in which to propose an improvement?
>
> Thanks
> Scott Kurz

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

SCA Specs

2006-07-19 Thread Venkata Krishnan


Hi Jeremy / Jim,

Where can I get hold of the specs in its current version which is under
development?  Could you point me to it?

Thanks

- Venkat

Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)

2006-07-19 Thread Geoffrey Winn


Looking at the GettingStarted page for the Tuscany SDO C++ Samples, I'd like
to suggest the following

In the section "Building the Samples on Windows"

The TUSCANY_SDOCPP environment variable should be set to \deploy

Bullet point 3 should start with

"Build the source, either via the Visual Studio 6 project at
\samples\ides\devstudio6\projects\misc\misc.dsw ...

In the section "Running the Samples on Windows"

The first sentence might be better as

"Ensure that \bin is included in the PATH
environment variable before launching the IDE."

Geoff.

Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)

2006-07-19 Thread Pete Robbins


+1 from me

--
Pete

Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)

2006-07-19 Thread Geoffrey Winn

I've downloaded the RC-3b Windows SDO source distribution. The SDO runtime
and test projects build and run just fine, and as others have said, the
documentation is much clearer now. Thanks.

I give this candidate a +1 as well.

I went on to try the samples project and in that case there are a couple of
places where the documentation is a bit misleading. I'll post a separate
note with some suggestions for how I think it could be improved but I don't
think that has any bearing on this release.

Geoff.

On 19/07/06, Edward Slattery <[EMAIL PROTECTED]> wrote:

Ive tested the vc7 and vc6 builds in debug and release modes. All works
fine
except three minor points which have been raised as JIRAs:

1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe
2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be
Client.pdb
3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need
a
dot moved in the line: "if .Debug == %1."   to "if Debug. ==
%1."  Otherwise
the deploy always copies the
Release Dll, not the Debug dll.

I think these are all trivial problems with easy solutions and the JIRAs
describe the solutions,
so I give this candidate  a +1

On 19/07/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> Just tested the binaries on WinXP and Fedora Core1. All happy.
> +1 for release
> Andy
>
>
> On 7/18/06, David Wheeler <[EMAIL PROTECTED]> wrote:
> >
> > I just installed the linux binary version onto ubuntu 6.
> > Calculator sample works fine.
> >
> > -David Wheeler
> >
> > On 7/18/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > > I have refreshed the distros. Please vote on the release candidate
> > > available
> > > here: http://people.apache.org/~robbinspg/RC-3b
> > >
> > > Apologies for any inconvenience.
> > >
> > > Cheers,
> > >
> > > --
> > > Pete
> > >
> > >
> >
> >
>
>

Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)

2006-07-19 Thread Edward Slattery

Ive tested the vc7 and vc6 builds in debug and release modes. All works fine
except three minor points which have been raised as JIRAs:

1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe
2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be
Client.pdb
3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need a
dot moved in the line: "if .Debug == %1."   to "if Debug. == %1."  Otherwise
the deploy always copies the
Release Dll, not the Debug dll.

I think these are all trivial problems with easy solutions and the JIRAs
describe the solutions,
so I give this candidate  a +1

On 19/07/06, Andrew Borley <[EMAIL PROTECTED]> wrote:

Just tested the binaries on WinXP and Fedora Core1. All happy.
+1 for release
Andy

On 7/18/06, David Wheeler <[EMAIL PROTECTED]> wrote:
>
> I just installed the linux binary version onto ubuntu 6.
> Calculator sample works fine.
>
> -David Wheeler
>
> On 7/18/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > I have refreshed the distros. Please vote on the release candidate
> > available
> > here: http://people.apache.org/~robbinspg/RC-3b
> >
> > Apologies for any inconvenience.
> >
> > Cheers,
> >
> > --
> > Pete
> >
> >
>
>

[jira] Created: (TUSCANY-566) Debug mode deploy and wsdeploy command files need altering

2006-07-19 Thread Ed Slattery (JIRA)

Debug mode deploy and wsdeploy command files need altering
--

 Key: TUSCANY-566
 URL: http://issues.apache.org/jira/browse/TUSCANY-566
 Project: Tuscany
  Issue Type: Bug
Reporter: Ed Slattery
Priority: Minor


The wsdeploy and deploy command files located in the Calculator directory under 
samples/ides/devstudio6 and samples/ides/devstudio7 are always copying the 
Release dll rather than selecting the Debug or Release based on active 
configuration.

This:

set buildMode=Release
if .Debug == %1. (
set buildMode=Debug
)

should be this:

set buildMode=Release
if Debug. == %1. (
set buildMode=Debug
)

(The dot has moved from before Debug to after).





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Moving chianti to trunk

I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.

Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.

Simon

Kenneth Tam wrote:

-0 on ordaining some kind of "official" priority for functional
equivalency with M1 -- my opinion is that at this stage in the project
(ie, incubation), developer community is significantly more important
than user community.  I'd rather we take a more free form stance with
respect to encouraging development in areas people find compelling
(including of course, the porting of functionality from M1).

On 7/18/06, Simon Nash <[EMAIL PROTECTED]> wrote:

It is true that users who just want a working binary download
have the M1 release to work with.  However, the Tuscany community
itself will benefit from being able to run end to end scenarios
to exercise code that they contribute to the new trunk.  So if we
do make this switch now, I believe that we need to focus as a
community on getting the new trunk into a state where it can run
end to end scenarios with comparable functionality to what we had
previously in M1.  I'd feel more comfortable if I saw comments on
this list agreeing that this should be the priority immediately
following the switch.

   Simon

Rick wrote:

> For me the vote said it all; its good to go to switch.  I think I can
> understand your position and probably would side with you if it wasn't
> for two things:  We have a release so users just wanting to understand
> SCA and the basics of Tuscany have something stable to work with.  Also
> this is just a switch,  the head of the trunk should be preserved in a
> branch.  Just before the switch I would recommend both have tags too.
> Doing this doesn't stop any discussion, it doesn't stop bringing
> function/code from the current head back in to Chianti; it even doesn't
> prevent in the case community decides we prefer to switch back.
>
> Simon Nash wrote:
>
>> Jeremy,
>> Before you do this, I'd prefer to see some discussion about the
>> functional differences between chianti and the current trunk code
>> and how we would see these being addressed, as I said in my
>> previous email on this subject.  What do you (or others) think
>> about this?
>>
>>   Simon
>>
>> Jeremy Boynes wrote:
>>
>>> With the vote in favour of switching, I am about to start moving
>>> chianti into trunk. I will move the current sca parts into a branch
>>> (branches/pre-chianti) and move the chianti code into trunk. I will
>>> make the version in the poms 1.0-SNAPSHOT like the SDO tree.
>>>
>>> I expect to complete this tomorrow or possibly Wed if there are
>>> build  issues. If anyone has a bunch of uncommitted changes or a big
>>> patch  for submission please speak up soon to avoid merge issues.
>>>
>>> Thanks
>>> --
>>> Jeremy
>>>

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

[jira] Created: (TUSCANY-565) Windows Debug build of Calculator sample incorrect

Windows Debug build of Calculator sample incorrect
--

 Key: TUSCANY-565
 URL: http://issues.apache.org/jira/browse/TUSCANY-565
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SCA
Affects Versions: Cpp-M1
Reporter: Pete Robbins
 Fix For: Cpp-M1


1. Debug build on VC6 builds Calc.exe instead of Client.exe
2. deploy.cmd and wsdeploy.cmd copy Release versions of exes
3. VC7 debug builds Client.exe bu Calc.pdb

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Proprietary BEA Dependency in Tuscany ?