Re: Graduation Checklist, was: Graduation

[Jeremy Boynes]

One issue I see is diversity. The proposed PMC seems very dominated  
by a single vendor as, if I understand the affiliations correctly, we  
have:

Andrew Borley (IBM)
Andy Grove (RogueWave)
ant elder (IBM)
Ignacio Silva-Lepe (IBM)
Jean-Sebastien Delfino (IBM)
kelvin goodson (IBM)
Luciano Resende (IBM)
Mike Edwards (IBM)
Pete Robbins (IBM)
Raymond Feng (IBM)
Simon Laws (IBM)
Venkata Krishnan (IBM)

Of the other committers, how many are active in the project?

On Oct 3, 2007, at 1:19 AM, Jean-Sebastien Delfino wrote:


[snip]
Simon Laws wrote:

How about we put a check list up on the wiki so
we all get a view of what's going on and what needs to be done by  
when. I've

started one here by copying the checklist from the graduation guide (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany 
+Graduation+Checklist)
but we need to work out what we need to do specifically for  
Tuscany and, of

course by, when.

Simon



I looked at the Tuscany Graduation Checklist Wiki page and it looks  
like we're making good progress. I have a few comments.


Bullet #1 points to http://incubator.apache.org/projects/ 
tuscany.html, 2 new committers are missing on that page.

Brady Johnson
Simon Nash

Bullet #3 - Are there three or more independent committers? says  
"The project committers are drawn from 6 independent  
organizations." Status says "Needs Checking".
I count 8 independent organizations, more than the requirement of  
3. Can we mark it "Done" or clarify what else needs checking?


Bullet #9 - Ensure that mentors and IPMC have no remaining issues.
Let's start with our mentors, could our mentors please list any  
remaining issues?


Row #11 - A  draft resolution is available at  http:// 
cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution
After discussing the draft on the mailing list, people seem to be  
OK with this text: http://www.mail-archive.com/tuscany- 
[EMAIL PROTECTED]/msg24387.html


Row #13 - Openness of specification process.
Looks like there is consensus in this thread: http://www.mail- 
archive.com/tuscany-dev@ws.apache.org/msg24282.html. I think we can  
mark this one "Done".


Thoughts?

--
Jean-Sebastien


-
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: [VOTE] Use single version for all Java/SCA modules and enable building all modules together

[Jeremy Boynes]

On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote:


Hi Jeremy,

Here is a problem that most of us are facing with the Trunk and is  
hindering
us to effectively contribute to the trunk.  I see there is one  
solution that
has been proposed to making this simpler with some compromises.  If  
this is
not agreeable what is the alternative for those of us who are  
waiting for a
solution to this.  Whats the simple way for any of us - including  
somebody
getting in afresh - to quickly jump in and start contributing  
without having
to worry about the build intricacies.  Should we consider Bert's  
suggestion?


At the moment, this is a straight up/down binary vote on a fairly  
vague proposal, one that some people have specific technical concerns  
over. There are other proposals out there but we seem to have lost  
sight of that. IMO, yes, we should consider Bert's proposal, and mine  
for assemblies, and anything else anyone can think of that is less  
divisive.


Theres been may a time when you have helped us out of various  
technical
difficulties.  Here is yet another time I request for help from you  
for a

way out of this.


Thanks. My suggestion is, keep talking. The important thing here is  
about seeing if we can work together to reach consensus. What the  
technical outcome is really doesn't matter.


--
Jeremy


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

Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together

[Jeremy Boynes]

This is an indication that the vote was initiated prematurely, before  
agreement was reached. I would suggest withdrawing it until  
individuals' concerns have been addressed unless we think this issue  
is irreconcilable and that a decision should be forced.


--
Jeremy

On Mar 28, 2007, at 3:24 PM, Davanum Srinivas wrote:


Jim, Meeraj,

If the stream of -1's contnue, am afraid there isn't going to be a
single release at all.

thx,
dims

On 3/28/07, Jim Marino <[EMAIL PROTECTED]> wrote:


On Mar 28, 2007, at 12:51 AM, ant elder wrote:

> Here's the vote on this I said [1] I'd start to get closure on this
> issue.
>
> The proposal is to have top-level pom for the Java SCA project that
> enables
> building all the modules together - kernel, services, runtimes,
> extensions
> etc, and for that to work all those modules need to use the same
> version
> name.
>
> Here's my +1.
>
>   ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> msg16024.html



There has been no proposal for how to resolve the issue about
building extensions using multiple versions of kernel and how modules
on different release schedules requiring different levels of kernel
or plugins will be handled.

Until we can come up with a solution for these issues, I feel I have
to vote against the proposal.

-1

Jim

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





--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services  
Developers


-
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: [Discussion] Tuscany kernel modulization

[Jeremy Boynes]

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15991.html

r522186
r521957

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15318.html
in relation to
r517804

And, of course, the code in SVN.

Lastly, we've been here before - r419320

--
Jeremy

On Mar 27, 2007, at 2:35 PM, Davanum Srinivas wrote:


"the wholesale, revolutionary rewrite of the kernel"...Pointers please
to exact emails.

thanks,
dims

On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

Nice diagram, Raymond, thanks for putting this together.

What I'm struggling with is that this seems fairly similar to the way
the code is organized now. Most of the boxes there already exist and
have interfaces to abstract away their implementation. Everything in
"Cross-cutting system services" is that way and the same for
"Container/Binding/Databinding/IDL Extensions" and "Pluggable
Federations."

These are all components implemented using the Tuscany "system"
programming model - basically, a simplified, POJO based IoC model
decorated (to the least extent possible) with SCA annotations. Each
of those components already has an interface to define the function
it provides.

We assemble those components using SCA assembly. That makes sense to
me because as an SCA runtime we have to support SCA assembly - so not
only will we need the code to do that, it makes things familiar to
users as there is a common language. We could assemble the runtime
another way, for example using Spring XML or Java code, but then
users need to be familiar with two assembly mechanisms and that seems
like confusing and unnecessary complexity.

One reason the SPI module is so large is that it does define many the
interfaces for the components in you diagram. I think there is room
for a reorganization there to clarify the usage of those interfaces.
I would propose we start with that rather than the wholesale,
revolutionary rewrite of the kernel that has been suggested.

--
Jeremy


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





--  
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services  
Developers


-
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: [Discussion] Tuscany kernel modulization

[Jeremy Boynes]

Nice diagram, Raymond, thanks for putting this together.

What I'm struggling with is that this seems fairly similar to the way  
the code is organized now. Most of the boxes there already exist and  
have interfaces to abstract away their implementation. Everything in  
"Cross-cutting system services" is that way and the same for  
"Container/Binding/Databinding/IDL Extensions" and "Pluggable  
Federations."


These are all components implemented using the Tuscany "system"  
programming model - basically, a simplified, POJO based IoC model  
decorated (to the least extent possible) with SCA annotations. Each  
of those components already has an interface to define the function  
it provides.


We assemble those components using SCA assembly. That makes sense to  
me because as an SCA runtime we have to support SCA assembly - so not  
only will we need the code to do that, it makes things familiar to  
users as there is a common language. We could assemble the runtime  
another way, for example using Spring XML or Java code, but then  
users need to be familiar with two assembly mechanisms and that seems  
like confusing and unnecessary complexity.


One reason the SPI module is so large is that it does define many the  
interfaces for the components in you diagram. I think there is room  
for a reorganization there to clarify the usage of those interfaces.  
I would propose we start with that rather than the wholesale,  
revolutionary rewrite of the kernel that has been suggested.


--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 24, 2007, at 6:30 AM, Davanum Srinivas wrote:

Using assemblies is ok. It does not have to be published. Once
everyone is in the same bandwagon, then it's ok to publish. Till then,
please find a way to work with assemblies w/o having to rely on
published artifacts. If this is a maven problem, then find another way
to solve the problem or ask at least raise an issue with maven folks.


Dims

Our build to date relies on the ability to reuse stable, common  
definitions such as this:


  https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ 
sca/1.0-incubating/pom.xml


What we are talking about publishing here is one parent pom, in line  
with mvn best practice. I don't think anyone has any issue with  
what's in it.


There are several ways in which this can "work" without publishing  
things, but all of them have technical disadvantages.


For example, you can use  in the parent element of your  
pom, but that ties the logical project structure to the physical  
directory structure. That precludes you from reusing unstable modules  
via svn externals or copy, and means that if you want to refer to  
stable modules users would need to check out from the root *INCLUDING  
ALL TAGS, BRANCHES AND C++ CODE.* This is not SVN best practice. We  
can fix that by restructuring the project so that tags live alongside  
modules but that is a fairly radical change in layout.


Alternatively, we can remove the dependency on a parent and repeat  
the plugin definitions that it contains in the pom for every module.  
The disadvantage of course is that there is a lot of repetition of  
common definitions. This is not Maven best practice.


A third option is simply not to use Maven, or perhaps to use a hybrid  
of Maven and something else (e.g. Ant).


Finally, I understand the stick here, but there is a difference  
between waving the stick and beating people with it. Changing the  
rules on publication requires broad technical changes in the project  
going against best practice for the tools we use - I ask that you  
actively involve yourself in the discussions around those rather than  
just telling others to find a way to make it work.



As for myself, am putting my foot down on publishing till everyone
shares. This is getting more and more like 3-4 year olds in the
sandbox not sharing their toys and saying hey you did not talk to me
when i talked to you. So shut up now. Everyone has a life, everyone
has priorities. When folks come to the table, the conversation should
begin again. Again, Please figure out a way everyone can work.


At the start of this thread, I thought we /were/ making progress with  
good discussion between myself, Raymond, Meeraj, Simon and Jim and  
general agreement on a compromise solution. Then Luciano throws his  
toys out the pram and we are back to square one.


I am at the table and willing to keep talking. Maybe we should change  
the subject, perhaps "are independently versioned modules worth it?"


--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote:


Jeremy

  So, having these assemblies modules sounded interesting to me  
until the
moment you said you want to base them on deployed artifacts... we  
have never
had a habit of publishing SNAPSHOTS for all possible artifacts, and  
even the
members of the community that are proposing this approach are  
failing to

deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this.


Ideally the deployed artifacts they would depend on would be stable  
released ones - this is directly inline with the stability goals  
expressed by the likes of Dave Booz. In general, aggregations should  
not depend on SNAPSHOTs or a head revision except where absolutely  
necessary.


Mario's pain was caused because we had not put together an assembly  
of the modules needed for the demo. It was the wee hours of the  
morning, I hope you understand. Once the dust settled, the modular,  
independent nature of what we had allowed us to put together a very  
simple assembly for building exactly that (independent of any other  
activity in trunk). You can see this here:
  https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- 
demo




  You also mentioned before that we have M2 experience of a top  
down build
not working, I'm not sure about all the details that comes to your  
mind when

you say that, but I remember some build brakes (and I think this is
acceptable in trunk, right ?)


No, not really.


and we could set some conventions like,
modules that are "unstable at the moment" would be removed from the  
maven
profile (and maybe a JIRA would be created)... later on, when the  
module is
back to it's stability, whoever fixed the issue would close the  
JIRA (if

any) and put the module back to the stable profile.


The problem of this approach is that it couples everything together  
through the parent pom. Even if a separate parent is used, the  
reactor will attempt to use common dependency versions across the  
modules. This means that modules get coupled together based on the  
versions of their dependencies and so we lose the independence  
between them.


Basically, unless they all use the same version then they won't all  
build.




  Also, this is not about MAVEN PROFILE versus ASSEMBLY.  I'm sure  
both can
co-exist together in perfect harmony, and it would definitely be a  
good
solution for members of the community that are interested only in a  
subset
of Tuscany (e.g some embedder that only requires the kernel, and a  
Spring

extension for example), and these assembly modules could be created as
needed

  These profiles would probably make the user experience of someone  
that
comes to evaluate Tuscany trunk much easier, as already mentioned  
by Mario
[1], and help others to be more productive as already expressed on  
various

other threads [2][3].


This is where we disagree. Doing what you suggest couples all modules  
at a single monolithic version level. That may be desirable in a  
commercial product but is not a way to scale an open source community.


One of the problems we have is that the documentation on the build  
and the pom structure is misleading and confusing users. I wanted to  
clean that up by removing bad poms such as java/pom.xml but was  
overruled.




  If I understand your concerns, having the convention of moving  
unstable
modules out of the maven profile should help, but maybe you could  
explain
what worries you, that you are fighting so hard not to allow people  
to build

different modules with a simple mvn command. Nevertheless, it's good
practice to build before committ, right ?


Please can we not make this personal - I am not fighting hard not to  
allow anything. I am trying to find a middle ground that allows  
people who need to build groups of modules to do so and at the same  
time preserve the independence between the modules.


I do not know of a way to make what you want work with independently  
versioned modules. I have proposed something that people seemed to be  
able to live with and which I believe works. Let's hear technically  
viable alternatives.


--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote:


Hi Jeremy

  For the assembly proposal, are you suggesting something like :

https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ 
sca/distribution/tss-sample/


Something like that, yeah.

You want to rely on things that are as stable as possible, preferably  
things that have been released. I would not have included pom/parent  
and buildtools as those are available from the release repo.  
Generally you want to include as few unstable dependencies as possible.


Also, I noticed you have a assembly descriptor in your project but  
you also include distribution/sca/demo.


--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

OK.

If we're going to hold the vote, I'll pull the candidate artifacts.  
We can republish them later.


That does mean that everyone will need to install the sca parent pom  
from the tag in SVN before any of the modules in trunk will build.


--
Jeremy

On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote:


Jeremy,

I'd like to see some progress on the community front! Let's see this
approach agreed upon and fleshed out a bit more.

thanks,
dims

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> Jeremy. This sounds like a simpler approach than what is there now.
> I like
> the idea but a question.
>
> 1) move everything that does not logical depend on
> org.apache.tuscany:sca:1.0-incubating to contrib
>
> from your previous definition do you mean those things that are not
> considered to be independent. Or do you mean things that could be
> independent but just aren't packaged that way now. I assume that
> you mean
> the latter as your next point is to go ahead and make them
> independent.

Yes things aren't really independent due to the intermediate poms in
the physical directory tree.

>
> Also is the global parent version 1.0-incubating or 1.0-incubating-
> SNAPSHOT.
> I note that now you have it without SNAPSHOT but its children with
> SNAPSHOT.
> Are you just saying that the global parent doesn't get packaged/
> released
> per-se SNAPSHOT or not.

This is the pom defined in the tag here:
   https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
sca/1.0-incubating

which is a stable artifact - one we have voted to release but are
waiting for the IPMC to approve. It will not move.

[[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
THREAD]]
   http://mail-archives.apache.org/mod_mbox/incubator-general/
200703.mbox/[EMAIL PROTECTED]

The things in trunk are not stable and so have a SNAPSHOT version.
--
Jeremy


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





--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services  
Developers


-
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: Planning kernel release 2.0

[Jeremy Boynes]

I have some cleanup work to do on work and on scopes but I would  
expect to get that done in the next day or so (ready for the next  
alpha).


On the physical model, I would like to get the bytecode based IFP  
going to simplify the PCD message. We also need to get complex  
properties working.


From the end-user experience, we need to finish implementing the  
Java C&I APIs - stuff like support for the Conversation interface and  
casting for ServiceReference etc. We should also look at the JavaEE  
integration spec. I think our  impl type may be close.


We also need to beef up the console with more management function,  
support for displaying the state of the assembly and federation, and  
support for contributing artifacts and managing them afterwards.


Plus all the stuff you mention of course :-)

I don't think the SPI is quite as stable as Dave would like but we  
should be able to improve things after alpha2. I think we should  
target an SPI freeze for the beta (June you were suggesting), at  
least for incompatible changes. To do that we need to have built a  
couple of bindings/containers on top of it.


--
Jeremy

On Mar 22, 2007, at 4:01 AM, Meeraj Kunnumpurath wrote:


Hi,

Now that the SPI is getting stable and we have the initial end-to-end
story for federation working, I would suggest we plan for the final
release for kernel 2.0, with emphasis on federation and user  
experience.

I was thinking about aiming for a beta in June in time for TSSJS
Barcelona and the final release for August. Maybe we can have  
couple of

alpha releases from now and June as well. These are the features, I
would like to see in 2.0.

1. Tidy up anything required in physical model, now that it is  
starting

to take good shape.
2. Tidy up generators from logical to physical model.
3. Fix the JXTA discovery issues, also investigate other discovery
protocols.
4. Federation end-to-end fully completed, this would include, maybe,
profiles advertising their capabilities and the information being used
in intent-based autowiring etc.
5. Intent-based auto wiring
6. Emphasis on end user experience in terms of ease of use.
7. Assembly service, this kind of now related to the generators that
have been introduced in the last week or so
8. Artifact management, especially mobile code when we target  
components

to remote profiles.

Also, now the SPI has started settling in, we need to start looking at
binding and container extensions as well. Some of the bindings I would
be interested in are,

1. JMS
2. AMQP
3. Hessian

Ta
Meeraj


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

-
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: ServerSide Presentation and Demo

[Jeremy Boynes]

Well, Meeraj and Jim did the real work.
OK, the circle is now complete :)

On Mar 22, 2007, at 2:33 PM, Meeraj Kunnumpurath wrote:



Ta, Actually Jeremy and Jim did most of it.


-Original Message-
From: Kevin Williams [mailto:[EMAIL PROTECTED]
Sent: 22 March 2007 20:44
To: tuscany-dev@ws.apache.org
Subject: Re: ServerSide Presentation and Demo

Jim and Meeraj,
Congratulations!  Any chance the presentation was taped?
--Kevin


Jim Marino wrote:


Hi,

We just finished the ServerSide demo and I figured I send

a mail to

the list outlining how it went...

We had the slot following the opening keynote and were up

against Rod

(Spring) and Patrick (OpenJPA) as the other  two talks. I was
surprised to find that the ballroom was pretty full. I

gave the talk

and the demo showing end-to-end federated deployment and reaction
seemed very positive.  Meeraj gets the "hero" award for

staying up to

an obscene hour in the morning to implement a JMS-based discovery
service as we encountered last-minute hiccups with JXTA.

My observations are:

- After speaking with people after the presentation,

feedback on the

value of SCA was consistent. Specifically, they thought the
programming model was nice but not a differentiator. What

people got

excited about was being able to dynamically provision services to
remote nodes and have a representation of their service

network.  In

this respect, I think the demo worked well. Two people

said they need

what the demo showed for projects they currently have underway.

- People asked how SCA is different than Spring.  They reacted
positively when I said "federation" and "distributed

wiring". Related

to this, people get dependency injection (i.e. it's

old-hat) and just

seem to assume that is the way local components obtain references.

- People seemed to react positively when I compared SCA to

Microsoft

WCF

- People liked the idea of heterogeneous service networks

and support

for components written in different languages, particularly C++.

- People didn't ask about web services. People were nodding their
heads (in agreement) when I talked about having the runtime select
alternative bindings such as AMQP and JMS.

- People want modularity and choice. Two areas they wanted

choice in

was databinding and persistence. They liked the fact that

we are not

locked into one databinding solution and that we have JPA

integration.

(as an aside, they also liked that SDO can be used without SCA).
Spring integration was also popular.

- People also liked the idea of a 2MB kernel download. One person
mentioned they only want to download what they intend to

use and not a

lot of extra "clutter".

- People wanted to know how SCA is different than an ESB.

I basically

described it using the switch vs. router metaphor and how

a component

implementation type can be a proxy for an ESB. Related to this and
point-to-point wires, people thought wire optimization by the
Controller was cool.

- People seemed to be more interested in running Tuscany as a
standalone edge server or embedded in an OSGi container. I

didn't get

any questions about running Tuscany in a Servlet container or J2EE
application server. This seems to be consistent with there being a
number of talks on server-side OSGi.

My big takeway is that we need to make the demo a reality.

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]


This message has been checked for all email viruses by MessageLabs


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

-
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]

Maven info

[Jeremy Boynes]

For those not really familiar with Maven there is a lot of good  
information in this book:

  http://www.mergere.com/m2book_download.jsp

--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
Jeremy. This sounds like a simpler approach than what is there now.  
I like

the idea but a question.

1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib

from your previous definition do you mean those things that are not
considered to be independent. Or do you mean things that could be
independent but just aren't packaged that way now. I assume that  
you mean
the latter as your next point is to go ahead and make them  
independent.


Yes things aren't really independent due to the intermediate poms in  
the physical directory tree.




Also is the global parent version 1.0-incubating or 1.0-incubating- 
SNAPSHOT.
I note that now you have it without SNAPSHOT but its children with  
SNAPSHOT.
Are you just saying that the global parent doesn't get packaged/ 
released

per-se SNAPSHOT or not.


This is the pom defined in the tag here:
  https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ 
sca/1.0-incubating


which is a stable artifact - one we have voted to release but are  
waiting for the IPMC to approve. It will not move.


[[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS  
THREAD]]
  http://mail-archives.apache.org/mod_mbox/incubator-general/ 
200703.mbox/[EMAIL PROTECTED]


The things in trunk are not stable and so have a SNAPSHOT version.
--
Jeremy


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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 22, 2007, at 11:19 AM, Simon Laws wrote:


When you talk about flattening the module hierarchy do you mean this
literally in svn (which I like the sound of as I can never find  
anything in

all the nested dirs - my inexperience showing) or is this some virtual
flattening?



Not a  at all. We can do either or both ...

The logical/virtual tree here is the  structure in the pom.  
Maven projects can inherit project definitions (stuff like  
dependencies, repo locations, plugins to use) from another project by  
specifying it in their  element - this can be used to avoid  
repetition of stuff like dependency versions, plugin configurations  
and so on.


This is actually independent of the physical directory structure,  
although often the pom in one directory is used as the parent for  
 that it builds. This is actually conflating physical  
structure and logical structure together and although it seemed like  
a good idea at the time I don't think that it is working any more.



I think we should first flatten the logical hierarchy so that all  
independent module groups inherit from a global parent. This would be  
org.apache.tuscany:sca:1.0-incubating.  By "independent" I mean  
things that could be released independently - these could be groups  
of tightly coupled modules (such the current "kernel" or "runtime")  
or individual modules such as "http.jetty"


I started on this for the modules that were part of 2.0-alpha but  
have not done it yet for the modules in extensions or services that  
were not. I think we should do this now for the others - I'll make a  
start on the ones used in the demo.


An orthogonal issue is how we lay out the physical directory tree. It  
is probably simpler to get rid of midlevel parents like "extensions"  
and "services" all together and just have a flat structure under  
"sca" - I think that would help make things easier to find.


We started doing that with a gradual migration of stuff from  
"services" to "extensions" but I think doing this gradually has  
probably just added to the confusion. I'd suggest we give up on the  
gradual approach and move everything under "contrib" until we can fix  
the logical structure as above.


To summarize:
1) move everything that does not logical depend on  
org.apache.tuscany:sca:1.0-incubating to contrib

2) update each module or group in contrib to be logically independent
3) once the module is independent move it to the flat structure under  
sca so it is easy to find


I'm going to get started with the modules used in the demo.
--
Jeremy

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

Re: Build structure - having cake and still eating

[Jeremy Boynes]

On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:


+1.

I think it's in line with the proposal in my response to Meeraj.

One question: For a bundle to reference a module in the Tuscany  
source tree, do we really have to copy (or use svn:externals  
property) if it points to a location (under trunk, tags, or  
branches) in the Tuscany tree? I think a relative path for the  
 will work.


It will.

The difference would be that with a ../.. type relative path someone  
can't just check out the assembly module, they need to check out the  
whole tree from some common root. With an external they could just  
check out the assembly module and the source for the dependency would  
be checked out as well. Of course, then they might have multiple  
copies of the dependency source to manage.


Either works and it would up to the users of the assembly module to  
choose which style they prefer.


--
Jeremy


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

Re: A question of federation - was: Planning kernel release 2.0

[Jeremy Boynes]

On Mar 22, 2007, at 8:47 AM, Simon Laws wrote:
Ok, cool, so I can run a simple app in a single VM. Let me try it  
out.


Just to set expectations, I don't think the system configuration in  
the default runtime has been switched over to the federated deployer  
yet. So if you run the calc sample on that runtime then it will still  
be using the old stuff.


If you want to experiment with the federated stuff, you would need to  
use the scdl from the master profile in the demo.


--
Jeremy


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

Build structure - having cake and still eating

[Jeremy Boynes]

We know from M2 experience and the number of "profiles" in the  
integration branch that a top-down, build-everything approach does  
not work.


We also know from practical experience that people struggle building  
modules.


I believe there is a middle ground that supports both approaches;
* have a flat module structure that allows any module to be built on  
its own

  using dependencies from the mvn repos
* have particular assemblies that pull modules together into whatever  
bundles
  people want. The assemblies can use released modules from mvn,  
snapshot

  modules from mvn, a copy of any revision of that module, or can track
  trunk using svn externals

An example of this is the assembly I used for the tag for the TSSS  
demo code which uses a combination of released artifacts and known  
revisions.


This gives module developers their own space to work in, and allows  
people consuming those modules to choose how stable the code they  
want to use is (from released through to head).


Hopefully this will provide a middle ground we are all comfortable with.
--
Jeremy


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

Tag for TSSS demo code

[Jeremy Boynes]

I've created a tag corresponding to the code used to build the demo  
(r520715) and added a trivial pom to build the lot. To build:
  $ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/tsss-demo

  $ mvn install

I did not change the versions in the poms so they are using the same  
ones as trunk. To avoid conflict in the snapshot repo we should not  
deploy jars built from this.


--
Jeremy

On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:


Jeremy,

This is the definitve list, thanks to Mario.

java/spec/commonj/
java/spec/sca-api-r1.0/
java/sca/kernel/
java/sca/runtime/
java/sca/services/
java/sca/contrib/discovery/
java/sca/contrib/discovery/jms
java/sca/console/
java/sca/core-samples/
java/distribution/sca/demo.app
java/distribution/sca/demo/

Ta
Meeraj

-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 1:52 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Compilation status

I think we should tag and deploy SNAPSHOTs of the revision used for  
the

demo - that way people can build as much or as little as they wish. If
you can post the list, I get those modules tagged and deployed later
today.

--
Jeremy

On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:


Mario,

AFAIK extensions in trunk is still in a bit of a flux. If you want to
run the demo, you don't need to run the extensions (the demo uses  
Java



container with local bindings), I will try to post a dfeinitive list
of tasks to build and run the demo later in the day, which will be
useful to Simon as well.

Ta
Meeraj

-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 12:29 PM
To: tuscany-dev@ws.apache.org
Subject: Compilation status

Meeraj,



I just wanted you to know that I am still not able to compile the  
code



I checked out from SVN. The main problem is located in the
*extensions* project. I have been modifying the pom files within this
project but I did not manage to get it compiled yet.



Basically, the main problems are related to inconsistencies between
parent references (e.g.; axis2's root project is using groupId
*org.apache.tuscany.sca.axis2* while the plugin subproject states  
that



its parent is *org.apache.tuscany.sca.extensions.axis2*).



Any tips about this?



Thanks,

Mario


This message has been checked for all email viruses by MessageLabs.


*

You can find us at www.voca.com

*
This communication is confidential and intended for the exclusive use
of the addressee only. You should not disclose its contents to any
other person.
If you are not the intended recipient please notify the sender named
above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

-
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]


This message has been checked for all email viruses by MessageLabs.

This message has been checked for all email viruses by MessageLabs.

-
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: Compilation status

[Jeremy Boynes]

I think we should tag and deploy SNAPSHOTs of the revision used for  
the demo - that way people can build as much or as little as they  
wish. If you can post the list, I get those modules tagged and  
deployed later today.


--
Jeremy

On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:


Mario,

AFAIK extensions in trunk is still in a bit of a flux. If you want to
run the demo, you don't need to run the extensions (the demo uses Java
container with local bindings), I will try to post a dfeinitive  
list of

tasks to build and run the demo later in the day, which will be useful
to Simon as well.

Ta
Meeraj

-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 12:29 PM
To: tuscany-dev@ws.apache.org
Subject: Compilation status

Meeraj,



I just wanted you to know that I am still not able to compile the  
code I

checked out from SVN. The main problem is located in the *extensions*
project. I have been modifying the pom files within this project but I
did not manage to get it compiled yet.



Basically, the main problems are related to inconsistencies between
parent references (e.g.; axis2's root project is using groupId
*org.apache.tuscany.sca.axis2* while the plugin subproject states that
its parent is *org.apache.tuscany.sca.extensions.axis2*).



Any tips about this?



Thanks,

Mario


This message has been checked for all email viruses by MessageLabs.


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

-
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: svn commit: r520639 - in /incubator/tuscany/java/distribution/sca/demo/src/main/profiles: master/system.scdl slave1/system.scdl slave2/system.scdl

[Jeremy Boynes]

On Mar 20, 2007, at 4:09 PM, Raymond Feng wrote:


Hi,

Interestingly I just hit the same issue independent of your work. I  
got two instances of the ComponentManager and the one contributed  
from the system.scdl shadows the primordial one.


Which actually the correct behaviour, just not the desired one here :-)



Does it mean the primordial components are not replaceable?


Depends on what you mean by replaceable.

The way AbstractRuntime boots it:
* creates a primordial fabric (ComponentManager, Connector, about 4  
other components)

* creates a primordial deployer runtime
* uses the deployer runtime to deploy the system scdl into the  
primordial fabric creating the local runtime

  (the remaining 100 or so components)
* uses the freshly booted system to load applications

The primordial components are those needed to wire the composite in  
the system scdl. For example, the components it contains need to be  
registered with a ComponentManager as they are deployed, so the  
ComponentManager can't be in the system scdl.


Instead, they are created by the createBootstrapper() call and  
registered in registerBaselineSystemComponents(), both of which are  
overridable allowing the implementations to be replaced. If that  
doesn't go far enough, the entire AbstractRuntime class can be  
replaced with something that boots the local runtime in a completely  
different way. For someone considering swapping out the fabric,  
that's a trivial change.


--
Jeremy


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

Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:


Jeremy, I don't understand your last comment:


I can't ack this for the ASF - that has to be done by an Officer as
described in the IP Clearance process. They would probably want
something official from IBM (Software Grant).


By attaching the two files to the JIRA, and selecting the "Grant  
license
to ASF ..." button, I (on behalf of IBM) am contributing the  
classes. If I
didn't have the right to do that, I would obviously be personally  
liable.

How is this contribution different from any other contributed source
files?


It isn't. And Apache has a IP Clearance process for handling them.
Please don't shoot the messenger.



What I was specifically asking is whether there is some stringent  
timeline
issue that I still need to deal with? The code had been in SVN  
before the

license was officially granted.


The big one is that we can't release this code until this resolved.
--
Jeremy


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

Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:

I've confirmed that IBM, the copyright holder, gives permission to  
Apache

to reuse the two EMF files in question.


Thanks for confirming this.



I've opened TUSCANY-1185 to contribute the two base classes,  
provided in

an attachment.

Jeremy, let me know if this is good enough for you, or if you still  
want

me to remove the Tuscany subclasses and resubmit them.


I can't ack this for the ASF - that has to be done by an Officer as  
described in the IP Clearance process. They would probably want  
something official from IBM (Software Grant).


--
Jeremy




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

Re: [DISCUSS] Rewrite kernel model to be based on interfaces

[Jeremy Boynes]

On Mar 20, 2007, at 12:43 PM, Matt Hogstrom wrote:

Was there a separate DISCUSS thread on this.  Looks like an  
interesting idea but I'm having trouble digging through the volumes  
of e-mail and the two sentences below don't help me understand the  
depth of the issues.   Is there one thread I can look at or is it  
really a mosaic of different threads?  Sounds more like a revolution.


There was a lot of discussion on the interface/POJO issue around this  
time last year when we switched from an interface model generated by  
SDO from XSD to the current POJO one. I share Meeraj's reluctance  
about rehashing the same issues especially when there is so much new  
stuff to do.


Most of the recent discussion has been about "componentization" which  
I think is a very different issue and applies irrespective of how our  
model is written or deserialized. I tried to separate that and keep  
the VOTE thread focused on the interface issue but wasn't very  
successful :-(


Dave made some good points on API stability that again apply  
irrespective of the interface/POJO issue - changing interfaces are  
just as much of a stability problem as changing POJOs.


These probably warrant threads of their own.
--
Jeremy


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

Re: [WITHDRAWN] Rewrite kernel model to be based on interfaces

[Jeremy Boynes]

Consider it withdrawn.

On Mar 20, 2007, at 8:36 PM, Davanum Srinivas wrote:


Jeremy,

Please allow time for discussion. Please withdraw this vote as it is
getting hijacked because discussion is not over yet.

thanks,
dims

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

Raymond Feng wrote:
> Hi,
>
> Here's my vote.
>
> [X] +1 we should do this
> [ ] -1 keep things as they are
>
> The vote is based on my understanding of the benefits of
> interface-based models as follows.
>
> 1) Better pluggability for the model implementation and loading: We
> can easily generate the model and loading code using Java/XML  
binding

> frameworks such as JAXB, SDO and XMLBeans.
>
> 2) Better relationship between model objects: One java class can
> implement multiple interfaces, for example, we can use "Extensible"
> interface to represent the SCDL extensibilities and "Promotable" to
> represent models eligible for promotion.
>
> 3) Better isolation for dependencies: Other modules only have to
> depend on the model interfaces for compilation. We don't have to
> release the model interfaces if we just have to fix issues in the
> implementation classes without breaking the contract.
>
> 4) Simpler interface-based mocking for unit tests
>
> 5) Other projects use interface-based modeling such as Axiom, DOM,
> WSDL4J and Woden
>
> Thanks,
> Raymond
>
> - Original Message - From: "Jeremy Boynes"  
<[EMAIL PROTECTED]>

> To: 
> Sent: Tuesday, March 20, 2007 7:23 AM
> Subject: [VOTE] Rewrite kernel model to be based on interfaces
>
>
>> The current model is based on simple POJOs. Sebastien has proposed
>> rewriting the configuration model to be based on interfaces with
>> separate implementation and factory classes. This will have a  
major
>> impact on the kernel code and all extensions. This vote is not  
about
>> what is in the model, it's is about how the model itself is  
implemented.

>>
>> [ ] +1 we should do this
>> [ ] -1 keep things as they are
>>
>>

If I was going to vote I would probably vote +1 since I'm doing this
work :) but I'm not ready to vote on it yet, as I'm not sure why a  
vote

thread popped up so quickly, independent of the thread I started
yesterday to get input from our community and have a technical
discussion on the subject:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html

--
Jean-Sebastien


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





--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services  
Developers


-
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: svn commit: r520468 - in /incubator/tuscany/java/sca/core-samples: common/calculator/pom.xml common/pom.xml pom.xml

[Jeremy Boynes]

You also need to update the poms for the individual samples and and  
 elements in their SCDL.

--
Jeremy

On Mar 20, 2007, at 9:43 AM, [EMAIL PROTECTED] wrote:


Author: meerajk
Date: Tue Mar 20 09:43:37 2007
New Revision: 520468

URL: http://svn.apache.org/viewvc?view=rev&rev=520468
Log:
upgraded pom

Modified:
incubator/tuscany/java/sca/core-samples/common/calculator/pom.xml
incubator/tuscany/java/sca/core-samples/common/pom.xml
incubator/tuscany/java/sca/core-samples/pom.xml

Modified: incubator/tuscany/java/sca/core-samples/common/calculator/ 
pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core- 
samples/common/calculator/pom.xml? 
view=diff&rev=520468&r1=520467&r2=520468
== 

--- incubator/tuscany/java/sca/core-samples/common/calculator/ 
pom.xml (original)
+++ incubator/tuscany/java/sca/core-samples/common/calculator/ 
pom.xml Tue Mar 20 09:43:37 2007

@@ -21,7 +21,7 @@
 
 org.apache.tuscany.sca.core-samples
 common
-2.0-alpha-incubating-SNAPSHOT
+2.0-alpha2-incubating-SNAPSHOT
 
 4.0.0
 org.apache.tuscany.sca.core-samples.common

Modified: incubator/tuscany/java/sca/core-samples/common/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core- 
samples/common/pom.xml?view=diff&rev=520468&r1=520467&r2=520468
== 


--- incubator/tuscany/java/sca/core-samples/common/pom.xml (original)
+++ incubator/tuscany/java/sca/core-samples/common/pom.xml Tue Mar  
20 09:43:37 2007

@@ -21,7 +21,7 @@
 
 org.apache.tuscany.sca
 core-samples
-2.0-alpha-incubating-SNAPSHOT
+2.0-alpha2-incubating-SNAPSHOT
 
 4.0.0
 org.apache.tuscany.sca.core-samples

Modified: incubator/tuscany/java/sca/core-samples/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core- 
samples/pom.xml?view=diff&rev=520468&r1=520467&r2=520468
== 


--- incubator/tuscany/java/sca/core-samples/pom.xml (original)
+++ incubator/tuscany/java/sca/core-samples/pom.xml Tue Mar 20  
09:43:37 2007

@@ -26,7 +26,7 @@
 4.0.0
 org.apache.tuscany.sca
 core-samples
-2.0-alpha-incubating-SNAPSHOT
+2.0-alpha2-incubating-SNAPSHOT
 pom
 Apache Tuscany Core Samples
 Sample projects that illustrate core concepts for  
SCA and Tuscany.




-
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: [VOTE] Rewrite kernel model to be based on interfaces

[Jeremy Boynes]

On Mar 20, 2007, at 9:26 AM, Venkata Krishnan wrote:


Hi Jeremy,

As part of this discussion and vote could we also summarize the  
technical
reasons for each of us to be going one way or the other.  Since  
this is a
major decision point it would be good for everybody to know why we  
as a
community are taking a specific direction and helps us to get back  
to these

design decisions in the future whenever in doubt.  I am really keen on
understanding each of our technical perspectives in this regard and  
not

necessary in the context of weighing opinions for this vote.


I would too. We have actually had this discussion before, around this  
time last year, and went with simple POJOs because they were easier  
to use and did not require people to write several classes to wrap a  
single field. The responsibility of conversion to/from XML was  
treated as a problem for an XML binding and, at the time, the SDO  
folk said they would look at a mechanism for loading user-supplied  
POJOs (much like JAXB already allows).




Here is my attempt at this...

[X] +1 we should do this
[  ] -1 keep things as they are

My Reasons : (from whatever little I have been thro)
- I see that the interfaces will help us align better with the  
assembly

model stated in the specs.


I agree we need to evolve the current model in line with the spec but  
that is about model content and not about whether the model is  
implemented as POJOs or interfaces. I wanted to keep discussion of  
what we need to do to evolve the model separate from this discussion.



What is publicly available out of the model is
just about what is published in the interfaces and that is just  
about what
the core (or extensions) should be using.  Otherwise we might  
encapsulate
into the model all that our core implementation would ideally need.  
Also
basing the model on interfaces us flexibility in that while the  
model's
implementation undergoes change the core that uses it continues  
unaffected.


Thing is, there is no implementation in the model - it is a bunch of  
simple POJO beans, structs with accessors (I consider set/get methods  
as a syntactic convention). Interfaces have a role in abstracting  
implementation but here there is no implementation to abstract.


But then we've been here before ...
--
Jeremy




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

Re: Discovery update

[Jeremy Boynes]

On Mar 20, 2007, at 7:26 AM, Antollini, Mario wrote:


Meeraj,

I am willing to help you. However, keep in mind that I am neither a
Tuscany developer nor a committer. Therefore you must give me a task I
can actually work on.

In case you do write to me, please be very specific since I do not  
have

much experience with Tuscany's code.

Looking forward to your reply.


I'll leave technical details to Meeraj as he's the one fighting the  
transport issue, but any contribution is welcome.  For code changes,  
the best way is to send a patch generated with "svn diff" once you  
have the change working - either sent as a text attachment to this  
list, or for larger changes attached to a JIRA.


Welcome aboard!
Jeremy


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

Re: [VOTE] Rewrite kernel model to be based on interfaces

[Jeremy Boynes]

On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:

The current model is based on simple POJOs. Sebastien has proposed  
rewriting the configuration model to be based on interfaces with  
separate implementation and factory classes. This will have a major  
impact on the kernel code and all extensions. This vote is not  
about what is in the model, it's is about how the model itself is  
implemented.


[ ] +1 we should do this
[X] -1 keep things as they are


My opinion.
--
Jeremy


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

[VOTE] Rewrite kernel model to be based on interfaces

[Jeremy Boynes]

The current model is based on simple POJOs. Sebastien has proposed  
rewriting the configuration model to be based on interfaces with  
separate implementation and factory classes. This will have a major  
impact on the kernel code and all extensions. This vote is not about  
what is in the model, it's is about how the model itself is implemented.


[ ] +1 we should do this
[ ] -1 keep things as they are



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

Re: svn commit: r520115 - in /incubator/tuscany/sandbox/isilval/notification/samples/local/src: main/java/org/apache/tuscany/notification/local/ test/java/org/apache/tuscany/notification/local/

[Jeremy Boynes]

Sorry about that - STATELESS should be working again.
--
Jeremy

On Mar 19, 2007, at 2:41 PM, [EMAIL PROTECTED] wrote:


Author: isilval
Date: Mon Mar 19 14:41:39 2007
New Revision: 520115

URL: http://svn.apache.org/viewvc?view=rev&rev=520115
Log:
Avoid problems with other scopes

Modified:
incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryConsumer.java
incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryProducer.java
incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/test/java/org/apache/tuscany/notification/local/ 
LocalNotificationITestComponent.java


Modified: incubator/tuscany/sandbox/isilval/notification/samples/ 
local/src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryConsumer.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/isilval/ 
notification/samples/local/src/main/java/org/apache/tuscany/ 
notification/local/TrafficAdvisoryConsumer.java? 
view=diff&rev=520115&r1=520114&r2=520115
== 

--- incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryConsumer.java (original)
+++ incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryConsumer.java Mon Mar 19 14:41:39 2007

@@ -23,7 +23,7 @@
 import org.osoa.sca.annotations.Service;

 @Service(TrafficAdvisory.class)
[EMAIL PROTECTED]("STATELESS")
[EMAIL PROTECTED]("COMPOSITE")
 public class TrafficAdvisoryConsumer implements TrafficAdvisory {

 @Property

Modified: incubator/tuscany/sandbox/isilval/notification/samples/ 
local/src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryProducer.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/isilval/ 
notification/samples/local/src/main/java/org/apache/tuscany/ 
notification/local/TrafficAdvisoryProducer.java? 
view=diff&rev=520115&r1=520114&r2=520115
== 

--- incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryProducer.java (original)
+++ incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/main/java/org/apache/tuscany/notification/local/ 
TrafficAdvisoryProducer.java Mon Mar 19 14:41:39 2007

@@ -19,9 +19,11 @@
 package org.apache.tuscany.notification.local;

 import org.osoa.sca.annotations.Reference;
+import org.osoa.sca.annotations.Scope;
 import org.osoa.sca.annotations.Service;

 @Service(TestCaseProducer.class)
[EMAIL PROTECTED]("COMPOSITE")
 public class TrafficAdvisoryProducer implements TestCaseProducer {

 @Reference

Modified: incubator/tuscany/sandbox/isilval/notification/samples/ 
local/src/test/java/org/apache/tuscany/notification/local/ 
LocalNotificationITestComponent.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/isilval/ 
notification/samples/local/src/test/java/org/apache/tuscany/ 
notification/local/LocalNotificationITestComponent.java? 
view=diff&rev=520115&r1=520114&r2=520115
== 

--- incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/test/java/org/apache/tuscany/notification/local/ 
LocalNotificationITestComponent.java (original)
+++ incubator/tuscany/sandbox/isilval/notification/samples/local/ 
src/test/java/org/apache/tuscany/notification/local/ 
LocalNotificationITestComponent.java Mon Mar 19 14:41:39 2007

@@ -19,9 +19,11 @@
 package org.apache.tuscany.notification.local;

 import org.osoa.sca.annotations.Reference;
+import org.osoa.sca.annotations.Scope;

 import junit.framework.TestCase;

[EMAIL PROTECTED]("COMPOSITE")
 public class LocalNotificationITestComponent extends TestCase {

 @Reference



-
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: Does the itest plugin support extensions?

[Jeremy Boynes]

On Mar 19, 2007, at 4:17 PM, Raymond Feng wrote:


Hi,

I'm trying to bring up a databinding integration test with itest  
plugin. But it seems that the MavenEmbeddedRuntime doesn't support  
deployment of extensions, neither does the standalone runtime.  
What's the plan to add this feature back? Or are we waiting for the  
contribution service to handle extensions?


We're waiting for the contrib service. The short-term hack for the  
standalone is to add the jars to boot and edit the system.scdl file  
to  the extension's scdl. I don't believe thought that works  
for the itest plugin as there's no classpath extension.


--
Jeremy


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

SDO IP Issues, was: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote:

Hmm, this seems like an example of where "legal red tape" may be  
getting

in the way of the "spirit of reuse".


One man's "spirit of reuse" is another's copyright infringement. This  
is not something to take lightly.


EPL is very specific:
  When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of  
the Program.


Distributing EPL code in source form under the Apache License is a  
violation of these EPL terms. Period.


To distribute this code under the Apache License it needs to be  
relicensed by the copyright owner. This is not an ongoing  
contribution as covered by a CCLA but a grant of software written  
elsewhere to the Foundation. There is a process for this, handled by  
the Incubator:

  http://incubator.apache.org/ip-clearance/index.html

Another alternative might be to distribute the code in binary form.  
This would involve making the "necessary change" elsewhere (say at  
Eclipse), releasing that derivative under the EPL in binary form.  
Tuscany would then be able to redistribute that code in its binary  
form. That's a suggestion - you probably want to talk to a lawyer and  
I would suggest running it past [EMAIL PROTECTED]



Here's the general problem:

1) We need to override a base class' behavior to do something  
"slightly

different".
2) Looking at the base class, we notice that it requires a tiny  
change in

the middle of a medium to large sized method. We request a slight
refactoring of the base (EMF) code, which they agree to fix in  
their next

version.
3) We can't move to the next version yet, so we add a copy of the  
method
(with the change) in our subclass and then proceed as if it was  
already in

the base class.

Note that we really don't want to do this in the first place  
because if we
later forget to remove the override and EMF fixes some other bug in  
the

same method, we won't ever pick up the fix. Unfortunately, however, we
have no choice in the short term other than to rewrite the whole  
method,

but since it's intricately tied to the rest of the base class
implementation it really couldn't be much different. We could  
rewrite the

entire class, but that completely defeats the purpose of reuse.

Does anybody know how this kind of "necessary copying" is addressed? I
also wonder where is the fine line between providing a "changed  
method" vs
"a copied method with a change" in a subclass? For example, what if  
one of
the copied methods was only 3 lines and we changed one of them? Is  
that

still a copy?

Thanks,
Frank.

Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 10:27:52 AM:


The original code here is EPL (I assume), which Apache projects can
include in binary form but not in source form. See here for details:
   http://www.apache.org/legal/3party.html

We need to remove the original code from the repo. After that, there
are two options:
* Have the IP owner (I presume this is IBM code) relicense it under
AL and contribute
   via the IP Clearance process
* Do an alternative implementation, best done by someone who has not
seen the Eclipse code

--
Jeremy

On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:


We may be talking about two different things here.

Regarding the two EMF classes: BasicExtendedMetaData and
XSDEcoreBuilder,
here's what we did.

Both of these classes (in EMF) create metadata (Types and  
Properties)

scattered in various places in the classes. Unfortunately, for us,
it does
it using those evil singletons: EcoreFactory.eINSTANCE.createXXX 
(). We
asked the EMF team if they could switch this to the IOC pattern,  
so we

could inject our SDO specific metadata factories. They said they
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since
we won't
(can't) move to EMF 2.3, our interim solution was to create
subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain
copies
of the base method, only using a factory instance variable instead
of the
singleton. For example:

class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;

void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}

... etc.

}

So, the question is, what kind of license do we need in these two
Tuscany
classes?

1. Apache.
2. Apache + Eclipse
3. Other?

Currently, I think we just have #1. If anyone can provide  
guidance on

this, it would be much appreciated.

Thanks,
Frank.


Jeremy Boynes <[EMAIL

target attach needs the source information

[Jeremy Boynes]

In WireAttacher, I think we need to pass the source component in the  
target attach operation because:
* for callbacks the target may need to know source information (e.g.  
for routing)

* for optimized wires it may be able to do nothing

I'll make this change. Given the signatures will be so close, I'm  
also going to rename the methods to attachToSource and attachToTarget.


--
Jeremy


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

Re: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

The original code here is EPL (I assume), which Apache projects can  
include in binary form but not in source form. See here for details:

  http://www.apache.org/legal/3party.html

We need to remove the original code from the repo. After that, there  
are two options:
* Have the IP owner (I presume this is IBM code) relicense it under  
AL and contribute

  via the IP Clearance process
* Do an alternative implementation, best done by someone who has not  
seen the Eclipse code


--
Jeremy

On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:


We may be talking about two different things here.

Regarding the two EMF classes: BasicExtendedMetaData and  
XSDEcoreBuilder,

here's what we did.

Both of these classes (in EMF) create metadata (Types and Properties)
scattered in various places in the classes. Unfortunately, for us,  
it does

it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they  
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since  
we won't
(can't) move to EMF 2.3, our interim solution was to create  
subclasses in

Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain  
copies
of the base method, only using a factory instance variable instead  
of the

singleton. For example:

class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;

void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}

... etc.

}

So, the question is, what kind of license do we need in these two  
Tuscany

classes?

1. Apache.
2. Apache + Eclipse
3. Other?

Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.

Thanks,
Frank.


Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/18/2007 12:33:25 PM:


Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.

What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:

+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $

and

+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $

which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.

--
Jeremy

On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:


I think you are freferring to commit r513560 .* *There was no code
copied
from eclipse.  The EMF generator puts an eclipse header in to
generated code
by default. That code was simply the result of using that generator
against
our own schemas.

Regards, Kelvin.




On 17/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy

On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:


I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/

~robbinspg/M3-RC1/>



Please take a look at this and try it out, so that I can pick up
any errors
quickly and move towards a vote on a proper release in the short

term.


Thanks, Kelvin.



--- 
--

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: Component group

[Jeremy Boynes]

+1 it was there for type safety in runtime but if it makes it hard to  
marshall no problem removing it


I removed a couple of leftover references to  in the JavaDoc  
as well

--
Jeremy

On Mar 18, 2007, at 1:46 PM, Meeraj Kunnumpurath wrote:


Hi,

I have been looking at the type parameter GROUP that has been added  
to PCD, which is not formalized anywhere down the inheritance tree.  
This means, the marshallers and unmarshallers won't be able to work  
against a static type that can be reflectively introspected at  
runtime, becuase of erasure. I was thinking if it is just an  
idenifier for the group to which a component belongs, can we just  
define it as a URI rather than a type parameter?


Ta
Meeraj

_
Txt a lot? Get Messenger FREE on your mobile.  https:// 
livemessenger.mobile.uk.msn.com/



-
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: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

Those are the ones. You said before that you thought this might be  
generated but that you were sure Frank would confirm. He has not done  
so.


What seems odd to me is that if this was generated then I would have  
expected consistent text to have been produced by the generator.  
Instead we have things like:


+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks  
Exp $


and

+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $

which correlate directly to headers found in files in the Eclipse  
repo. This makes the provenance of the code uncertain which is why we  
need clarification of what happened.


--
Jeremy

On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:

I think you are freferring to commit r513560 .* *There was no code  
copied
from eclipse.  The EMF generator puts an eclipse header in to  
generated code
by default. That code was simply the result of using that generator  
against

our own schemas.

Regards, Kelvin.




On 17/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy

On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:

> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ > people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/ 
~robbinspg/M3-RC1/>

>
>
> Please take a look at this and try it out, so that I can pick up
> any errors
> quickly and move towards a vote on a proper release in the short  
term.

>
> Thanks, Kelvin.


-
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]

WorkContext, was: Federating ScopeContainer

[Jeremy Boynes]

On Mar 17, 2007, at 2:49 PM, Jeremy Boynes wrote:
Instead, I'm going to move the work context into the invocation  
message so that is available as part of the invocation chain and  
make it the responsibility of the invoker to tunnel that through  
the user component if necessary. That will also make it easier for  
the async processing as the context would automatically be  
associated with the work being enqueued.


This is now done. There is a pairing between the TargetInvoker and  
the InvocationHandlers to tunnel context through calls to user POJOs  
using a ThreadLocal. Messages between components now carry the  
WorkContext in the payload.


I have updated the edge invokers for standalone and itest runtimes to  
bind a SimpleWorkContext to the thread before calling launched and  
junit components, starting off the invocation chain.


I have not updated the web implementation yet as it is using  
JDKInvocationHandlers for the references it stores in the  
ServletContext and they require the WorkContext on the thread. This  
would mean exposing the tunnel to user code and I think that is a / 
bad idea./ Instead, I think we should change the handlers it uses so  
that the work context is created there when the user calls the  
reference and then passed down the chain.


--
Jeremy


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

Re: SDO Java M3 Release Candidate RC1

[Jeremy Boynes]

Not to be a party-pooper, but what was the outcome with the code  
copied from Eclipse?

--
Jeremy

On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:


I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/people.apache.org/%7Erobbinspg/M3-RC1/>


Please take a look at this and try it out, so that I can pick up  
any errors

quickly and move towards a vote on a proper release in the short term.

Thanks, Kelvin.



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

Re: Federating ScopeContainer, was: Change to PhysicalComponentDefinition

[Jeremy Boynes]

First big chunk of this in r519446. Added groups and refactored the  
CompositeScopeContainer


I ran into a problem with the way we are associating IDs with the  
thread in a central WorkContext. This makes it necessary for an awful  
lot of components to reference the work context just so that can pass  
it to other things e.g. all the builders need to reference it so that  
they can inject into the components just to they can inject it to the  
target invoker so it can get the context id. This seems dumb.


Instead, I'm going to move the work context into the invocation  
message so that is available as part of the invocation chain and make  
it the responsibility of the invoker to tunnel that through the user  
component if necessary. That will also make it easier for the async  
processing as the context would automatically be associated with the  
work being enqueued.


For now I have temporarily commented out scopes other than composite  
- normal service will be resume shortly.

--
Jeremy

On Mar 13, 2007, at 1:55 PM, Jeremy Boynes wrote:


On Mar 12, 2007, at 11:47 AM, Jeremy Boynes wrote:


On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:

Firstly, transporting Scope is not enough on its own as there is  
more than one COMPOSITE scope. The builders used to get this from  
the deployment context but with federation it will need to be  
passed to in the PCD. I think instead we should treat  
ScopeContainers as resources and give them IDs like ClassLoaders.  
For COMPOSITE scope the ID can be the URI of the component  
implemented by the composite; for others we can use well known  
IDs. Every component has a scope so I think we can put  
scopeContainerID down in to PCD itself.


Following on with this I'm going to make the following changes to  
the ScopeContainer SPI to externalize the idea of a instance of a  
scope i.e a ScopeContext:

* add methods startContext(Object id) and stopContext(Object id)
  this will place external code in control of the lifecycle of the  
scope context so that it can be initiated
  by the code that dictates the lifecycle. This will allow us to  
avoid having the container register for and

  receive events just to detect context lifetime.
* change get and return wrapper to also pass the contextId
* add a Map to the WorkContext to associate scope  
context ids with the current work
* update the target invoker to get wrappers based on the current  
work context and the component's scope


Taking this a little further I think we need an additional mapping  
here - a component group. This allows us to partition a Scope into  
groups of component that support a common lifetime. The obvious  
application for this is with COMPOSITE scope where there are a  
group of components whose lifetime is tied to that of a composite;  
a more subtle application would be in conjunction with an EAR  
deployment where we want to relate HttpSession scoped components in  
different web applications. This would also allow us to support  
eagerInit semantics for scope types over and above COMPOSITE.


To support this I'm going to add another two method to  
ScopeContainer: createComponentGroup(Object) and  
removeComponentGroup(Object) and change the register/unregister  
methods to add a component group id so that the container can  
associate the component with the group.


--
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: Understanding Service Discovery

[Jeremy Boynes]

On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote:


Hello Meeraj,

I have read several emails and I got to know that you are working  
on the
Discovery service. I am very interested in this topic and I will  
like to

get a better understanding about it.


Great to have you involved.



I have seen that you have also mentioned the Federated Deployer,
Federated Assembly and Marshaling Framework throughout your posts. I
think all these components are somewhat connected to the Service
Discovery mechanism, aren't they? I will really appreciate if you can
give me some details on how they all interact, if they do so at all.
And, I will also like to understand the big picture here; i.e. what is
the main goal you are trying to achieve with all that. In addition to
that I will like to understand the role JXTA plays here and how it  
also

interacts with these components.


Their interaction is only indirect - they are more just using it as a  
transport.


The discovery layer is responsible for determining which runtime  
processes are participating in the federation at any time. We're  
using JXTA for that as it is a standard peer-to-peer protocol and is  
available in many different languages, specifically both Java and C++  
which are the two runtime implementations we have in Tuscany. We also  
want other protocols to work as well (for example, Bonjour or JINI)  
but want to get one working first.


As well as tracking the available processes it also provides a  
mechanism for allowing those processes to exchange messages and we  
are using that to send management operations across the system fabric.


Some of those management operations are associated with federated  
deployment. SCA's deployment model is based on the concept of changes  
to the domain assembly (e.g. include composite). Our implementation  
of that routes those changes to the controller nodes (at first one,  
next replicated, finally distributed) which take those logical  
changes and convert them to the physical ones that need to be made on  
participating runtimes. With the JXTA-based fabric, those are XML  
encoded JXTA messages; the marshalling framework is all about  
converting between those messages and the internal data structures  
(physical model) used by the Java runtime (C++ does not support this  
yet).


The federated deployer is a runtime node service that receives  
demarshalled change set messages from the fabric and applies the  
changes they contain to the local runtime - basically creating,  
removing resources, components and wires.


At the moment there's no interaction between JXTA and user components  
but if that was useful then we would just need to create a transport  
component implementation and wire attacher on the physical side and  
the binding support on the controller side.





Finally, I would like to know which is its is (i.e.; what it is  
already

able to do, what parts are missing, if you are willing to receive any
help, you are planning to get it ready for M3, etc).


We are in heavy development right now planning to show it working  
next week at TSSS - any help would be appreciated, both now and  
ongoing. All of this is happening in trunk for the 2.0-alpha2 release.




As you saw I am asking way too many things, however I will be really
glad if you can answer at least some of these questions.


Hope I covered the key points.
--
Jeremy


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

Re: IncompatibleClassChangeError with Maven Assembly plugin

[Jeremy Boynes]

On Mar 16, 2007, at 5:55 PM, Daniel Kulp wrote:



The snapshot that was deployed today seems to be very broken.   I  
haven't

had a chance to look into it at all.   The "quick fix" is to use the
last snapshot or last relase.  If you require the 2.2 features, set  
the

version to:



IIRC we do


2.2-20070112.063452-32



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

Re: svn commit: r519138

[Jeremy Boynes]

On Mar 16, 2007, at 4:50 PM, Jim Marino wrote:

On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
After thinking about it, I'm starting to think that a better place  
for it is

under /java/sca/services.Thoughts ?


That was exactly why I asked :-) I think it should be under  
services and modularizing kernel is a different topic.


sca/runtime/services is probably better as this is likely to be  
primordial.


--
Jeremy


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

Re: Add generic builders to support SCDL extensibility elements

[Jeremy Boynes]

Raymond

There are two sets of issues here:
* How to support SCDL extensibility elements
* How to support import.sdo as an instance of that

As seed for discussion of the second, I don't think @Reference is the  
right way to declare access to a HelperContext - this seems more like  
a resource. Specifically, I think using @Reference or  in  
the component type will result in SCDL that is not semantically valid  
by SCA rules even if it happens to work in Tuscany and I think that's  
a problem. This is probably a big enough issue that it warrants its  
own thread.


In terms of extension, I think we need to look at the protocol  
between the controller and the runtime. That is based on a concept of  
a PhysicalChangeSet (PCS) contaning:
* resource definitions (e.g. for scopes, classloaders, or other  
runtime-specific things)

* component definitions
* wire definitions

So the question really is about how does a SCDL extension map to one  
of those definitions and I think there are a couple of patterns for  
that:

1) the element extends the function of the containing model object
   in that case it is not really generic and would be handled by the  
Generator for the container
2) the element creates one of the definitions above independent of  
the containing model object
   this is just a regular Generator acting on the extension object  
and adding a definition to a PCS
3) the element does something in the context of the containing model  
object

   again just a Generator, but one that needs to be passed the parent

With that in mind, I think we end up with a API more like:

  interface Generator {
void generate(M modelObject, P parent, GenerationContext  
context) throws Something;

  }

  class GenerationContext {
property Map changeSets;
  }

Generator implementation may also need access to a physical model  
that tracks the state of each physical runtime so that they can  
determine what the current runtime context is. This would be updated  
based on change events sent back from the runtime as it applied  
various PCS messages. That though is getting off topic :-)


--
Jeremy

On Mar 16, 2007, at 10:16 AM, Raymond Feng wrote:


Hi,

We had discussions on this ML before on how to support SCDL  
extensibility elements which are not part of the base SCDL model  
and are used in SCDL for .


Let's use  as an example to illustrate my proposal.

1) ImportSDOLoader is a StAXElementLoader to load   
element into ImportSDO model object.


2) The model object is attached to the parent model object which is  
CompositeComponentType in this case. We can use  
ModeObject.getExtensions() to keep the models loaded from the  
extensibility elements.


3) Add a GenericBuilder interface and GenericBuidlerExtension in  
SPI as follows:


public interface GenericBuilderModelObject> {
   S build(SCAObject parent, M modelObject, DeploymentContext  
deploymentContext) throws BuilderException;

}

4) Change the Buidler and BuilderRegistry interface to support  
GenericBuilder.


5) Create an ImportSDOBuilder which will create HelperContext from  
the ImportSDO model.


6) When the BuilderRegistery builds Component/Service/Reference, we  
look at the extensions for the corresponding model objects and try  
to run the GenericBuilders against the objects in  
ModelObject.getExtensions().


7) The ImportSDOBuilder creates a AtomicComponent to wrap  
HelperContext. and register it in the composite so that the  
component impl can use @Reference (autowire=true) to get access to  
this HelperContext.


If we agree I'm on track with the overall direction, I'll work on it.

Thanks,
Raymond


-
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]

ArtifactResolver questions

[Jeremy Boynes]

On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:


Hi,

Contribution is the model object that hosts the metadata and  
introspected result for the contribution. Logically, you can use  
the URI of the contribution to look up the ContributionService to  
get the Contribution. I found it simpler for ArtifactResolver  
extensions to receive Contribution directly.


Doesn't this just move the responsibility for lookup to the caller of  
this SPI? And given the caller should not know about the  
implementation, it has to be passed every time even if the resolver  
does not need that information?


Actually, why is this a parameter at all? What makes Contribution  
different from any other attribute passed in the Map?


Finally, why is DeploymentContext passed - can't I use this outside  
the load phase?


--
Jeremy


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

Re: svn commit: r519040 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/deployer/ArtifactResolver.java

[Jeremy Boynes]

Why?

On Mar 16, 2007, at 9:26 AM, [EMAIL PROTECTED] wrote:


Author: rfeng
Date: Fri Mar 16 09:26:05 2007
New Revision: 519040

URL: http://svn.apache.org/viewvc?view=rev&rev=519040
Log:
Change the ArtifactResolver interface to take Contribution instead  
of URI


Modified:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java


Modified: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/ 
apache/tuscany/spi/deployer/ArtifactResolver.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ 
spi/src/main/java/org/apache/tuscany/spi/deployer/ 
ArtifactResolver.java?view=diff&rev=519040&r1=519039&r2=519040
== 

--- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java (original)
+++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/ 
tuscany/spi/deployer/ArtifactResolver.java Fri Mar 16 09:26:05 2007

@@ -19,10 +19,11 @@

 package org.apache.tuscany.spi.deployer;

-import java.net.URI;
 import java.net.URL;
 import java.util.Map;

+import org.apache.tuscany.spi.model.Contribution;
+

 /**
  * SCA Assemblies reference many artifacts of a wide variety of  
types. These

@@ -46,7 +47,7 @@
 /**
  * Resolve an artifact by the qualified name
  *
- * @param contribution the URI of the contribution
+ * @param contribution the model of the contribution
  * @param modelClass The java type of the artifact
  * @param namespace The namespace of the artifact
  * @param name The name of the artifact
@@ -55,7 +56,7 @@
  * @param context The deployment context
  * @return The resolved artifact
  */
- T resolve(URI contribution,
+ T resolve(Contribution contribution,
   Class modelClass,
   String namespace,
   String name,
@@ -78,6 +79,6 @@
  *
  * @return The URI of the resolved artifact
  */
-URL resolve(URI contribution, String targetNamespace, String  
location, String baseURI);
+URL resolve(Contribution contribution, String targetNamespace,  
String location, String baseURI);


 }



-
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: svn move, was: Databinding itest reorg proposal

[Jeremy Boynes]

Ah, apollogies for that. I have to admit that I'm a cvs person at  
heart so
just getting to grips with svn. I ljust ooked up svn move and got  
that "why
didn't I look there first" feeling, so I'll remember that for next  
time.

Thanks for taking the time to explain.


If you're new to Subversion I highly recommend reading this:
  http://svnbook.red-bean.com/

There's an Appendix on "Subversion for CVS Users" :-)
--
Jeremy


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

Re: How to associate some context with a composite?

[Jeremy Boynes]

On Mar 15, 2007, at 10:35 PM, Raymond Feng wrote:


Hi,

When I try to register a HelperContext component for the composite  
from databinding-sdo extension, I found that I need to access the  
ComponentManager which is in the core. Can we promote it to SPI?


Makes sense.



BTW, do we still have the distinction of system component or  
regular component?


No. Just components, some of which have a system implementation at  
the logical level and a different PCD type at the physical level, but  
by the time they get registered with the ComponentManager they are  
all just Components.


I hope we can actually merge Component and AtomicComponent together  
as well.

--
Jeremy


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

Assembly service, was: Kernel Alpha2 Release

[Jeremy Boynes]

As Meeraj just said:
2. Assembly service on the controller
:-)

We'll need it for the demo next so we'll need to get it done soon.
--
Jeremy

On Mar 15, 2007, at 5:05 PM, Luciano Resende wrote:


I can continue to contribute on the following items, as I have already
started them:

  * contribution store (and maybe artifact redistribution)
  * contribution tool (command line and plugin?)

BTW, we will need the assembly services for the contribution  
piece ? You had

started some work on that area, are you still going to work on that ?
Otherwise I might take a look on that too..

--
Luciano Resende
http://people.apache.org/~lresende

On 3/15/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I like the timing - about a month, 6 weeks at the most is a good
window between releases in early stages like we are.

I agree federation is the big delta between now and then - we should
have by then
* federated classloading (with multi-classloader support)
* federated scope
* the changes done for separating controller and physical runtime
* contribution store and artifact redistribution

It would be good to increase the spec coverage e.g.
* support for casting between proxies and service references
* support the new Conversation API
* clean up around complex properties - specifically being able to use
an external file to configure the server runtime
* some more integration tests

Also, user support such as:
* the composite plugin (i.e. pick an archive type)
* JUnit4/TestNG support in the itest plugin
* contribution tool (command line and plugin?)
* a start on some form of console
* some more samples
* doco for all the above

The Guice idea is intriguing - support for their PM and annotations
would be good. I also would like to take a look at using their EDSL
for assembly - perhaps for hooking up the runtime as an alternative
to SCDL.

--
Jeremy

On Mar 15, 2007, at 2:38 AM, Meeraj Kunnumpurath wrote:

> +1
>
> We should get the federation story implemented for the next kernel
> release. I think the development for federation is looking in good
> shape, and we should most probably have an end to end story, for  
the

> TSSS demo with couple of transports. In terms of extensions we also
> need
> to look at porting some of the existing extensions to the new  
model in
> addition to adding new ones like Hessian. Also, we need to to  
look at

> the management side of things. I started on it a while ago, it
> currently
> supports only read-only props on components. We need to start  
thinking
> about how to take it further forward. Some of the other things  
we can

> look at (maybe not in this release) is support for non-XML wiring,
> maybe
> start looking at things like Guice?
>
> Ta
> Meeraj
>
> -Original Message-
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 13, 2007 8:54 PM
> To: tuscany-dev@ws.apache.org
> Subject: Kernel Alpha2 Release
>
> I would like to start thinking about the next release of kernel.
> Based on the work being done around federation, it seems that
> multi- VM
> support is the key feature we should look to enable.  This will
> allow us
> to demonstrate the high-value areas of SCA, particularly around
> distributed assembly. In addition, we should have a simplified
> extension
> model and classloader isolation in place.
>
> In terms of timing, I thought sometime around the first or  
second week

> in April would be ideal, as a few of us will be demonstrating these
> features at the ServerSide Symposium next week.
>
> I think we may also be able to get some bindings and extensions out
> around the same time or shortly after. I was thinking: Spring,  
Groovy,

> JPA, and Hessian to start.
>
> Thoughts?
>
> Jim
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for
> the exclusive use of the addressee only. You should
> not disclose its contents to any other person.
> If you are not the intended recipient please notify
> the sender named above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX. United Kingdom
>
> VAT No. 226 6112 87
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>  
-

> To u

Re: [VOTE] Approve release of SCA specification APIs by Tuscany project

[Jeremy Boynes]

On Mar 15, 2007, at 3:49 PM, robert burrell donkin wrote:


On 3/13/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

The Tuscany community recently voted to release version 1.0-
incubating of our implementation of the API classes for the OSOA
specification V1.0:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/%
[EMAIL PROTECTED]

The source archives and RAT reports can be found at:
   http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating
and the binary in the Maven repo at:
   http://people.apache.org/repo/m2-incubating-repository/org/osoa/
sca-api-r1.0/1.0-incubating


ok except for the signature issue

major issues
==

gpg --verify sca-api-r1.0-1.0-incubating.jar.asc sca-api-r1.0-1.0- 
incubating.jar
gpg: Signature made Sun Mar  4 01:53:25 2007 GMT using DSA key ID  
11007026

gpg: BAD signature from "Jeremy Boynes <[EMAIL PROTECTED]>"

MD5 sums look right


There appears to be a bug in the gpg plugin for mvn. When I did this  
release I used gpg:sign as a goal on the command line and that  
consistently generates invalid keys for all except the last artifact  
(in this case the JavaDoc) even in the local repo. When I did the  
kernel modules I added a profile to the build which includes gpg:sign  
and for those all artifacts seem to have valid signatures.


Rather than resign the deployed artifacts (just in case there is  
something squiffy going on), I'll pull them down, add a profile to  
the pom and then redeploy them.


--
Jeremy


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

svn move, was: Databinding itest reorg proposal

[Jeremy Boynes]

On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
I forgot to mention that the reason that so many XML files have  
suddenly
appeared is that I've take the files that currently live in / 
interop and

renamed and refactored them.


Thanks for explaining as this did look a bit odd.

One way to avoid that is to use "svn move" to move the files rather  
than adding them again. When you do that, SVN shows that the file was  
copied from somewhere else in the repo and so it is fairly clear that  
it isn't a new work but just a derivative. This also has the  
advantage that the history of the file is maintained so users can  
track changes even across the move. It has an even bigger benefit in  
that it makes life easier for the lawyers, and a happy lawyer is much  
nicer to have than a grumpy one :-)


Some IDEs which grew up with CVS don't seem to realize that SVN  
allows them to just move things rather than delete old and add new  
(losing history in the process). If that's the case, then you can  
still get the benefits of moving through the svn command.


--
Jeremy
 


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

Re: Using extensions with the current trunk code

[Jeremy Boynes]

It's not going right now as we were planning to integrate with the  
contribution service (i.e. you would contribute the extension just  
like any other composite, either through the contribution API or by  
doing something like dropping it into a directory the contribution  
service was scanning).


What we did as an interim measure was externalize the system scdl  
into the profile in the form of a system.scdl file. That would allow  
you to add an extension in by adding an  element to that  
file referencing the extension's composite. Not ideal but ...


For 2.0-alpha2 I'd like to get the contribution service working (in a  
persistent way) and hook the extension mechanism to it. It looks like  
there were quite a few additions to the service in the branch but I  
don't know if Luciano or anyone is planning to port them to trunk any  
time soon - if not, I'll have a look but it won't be for a couple of  
weeks.


--
Jeremy

On Mar 15, 2007, at 2:44 PM, ant elder wrote:


Is it possible to have extensions picked up by the launchers with the
current trunk code? If i try dropping an extension jar in the launcher
extensions dir I get an UnsupportedOperationException from
AbstractExtensionDeployer.deployExtension. I guess this isn't going  
right

now or is it not how you use extensions these days?

  ...ant



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

Re: Kernel Alpha2 Release

[Jeremy Boynes]

I like the timing - about a month, 6 weeks at the most is a good  
window between releases in early stages like we are.


I agree federation is the big delta between now and then - we should  
have by then

* federated classloading (with multi-classloader support)
* federated scope
* the changes done for separating controller and physical runtime
* contribution store and artifact redistribution

It would be good to increase the spec coverage e.g.
* support for casting between proxies and service references
* support the new Conversation API
* clean up around complex properties - specifically being able to use  
an external file to configure the server runtime

* some more integration tests

Also, user support such as:
* the composite plugin (i.e. pick an archive type)
* JUnit4/TestNG support in the itest plugin
* contribution tool (command line and plugin?)
* a start on some form of console
* some more samples
* doco for all the above

The Guice idea is intriguing - support for their PM and annotations  
would be good. I also would like to take a look at using their EDSL  
for assembly - perhaps for hooking up the runtime as an alternative  
to SCDL.


--
Jeremy

On Mar 15, 2007, at 2:38 AM, Meeraj Kunnumpurath wrote:


+1

We should get the federation story implemented for the next kernel
release. I think the development for federation is looking in good
shape, and we should most probably have an end to end story, for the
TSSS demo with couple of transports. In terms of extensions we also  
need

to look at porting some of the existing extensions to the new model in
addition to adding new ones like Hessian. Also, we need to to look at
the management side of things. I started on it a while ago, it  
currently

supports only read-only props on components. We need to start thinking
about how to take it further forward. Some of the other things we can
look at (maybe not in this release) is support for non-XML wiring,  
maybe

start looking at things like Guice?

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 13, 2007 8:54 PM
To: tuscany-dev@ws.apache.org
Subject: Kernel Alpha2 Release

I would like to start thinking about the next release of kernel.
Based on the work being done around federation, it seems that  
multi- VM
support is the key feature we should look to enable.  This will  
allow us

to demonstrate the high-value areas of SCA, particularly around
distributed assembly. In addition, we should have a simplified  
extension

model and classloader isolation in place.

In terms of timing, I thought sometime around the first or second week
in April would be ideal, as a few of us will be demonstrating these
features at the ServerSide Symposium next week.

I think we may also be able to get some bindings and extensions out
around the same time or shortly after. I was thinking: Spring, Groovy,
JPA, and Hessian to start.

Thoughts?

Jim

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


This message has been checked for all email viruses by MessageLabs.


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

-
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: svn commit: r518245 - /incubator/tuscany/java/sca/core-samples/standalone/calculator/readme.html

[Jeremy Boynes]

Hmm, it does for me:

jeremy-boynes-computer:~/tuscany/java/sca/core-samples/standalone/ 
calculator jboynes$ ls -1 target

calc.jar
classes
surefire-reports
test-classes


On Mar 14, 2007, at 11:12 AM, Ignacio Silva-Lepe wrote:


Hmm, I think it's supposed to be calc.jar but that's not what
shows up in my build ...


On 3/14/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Thanks for catching the launcher name.
The application jar though is "calc.jar"

--
Jeremy

On Mar 14, 2007, at 11:03 AM, [EMAIL PROTECTED] wrote:

> Author: isilval
> Date: Wed Mar 14 11:03:12 2007
> New Revision: 518245
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=518245
> Log:
> use correct file names
>
> Modified:
> incubator/tuscany/java/sca/core-samples/standalone/calculator/
> readme.html
>
> Modified: incubator/tuscany/java/sca/core-samples/standalone/
> calculator/readme.html
> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core-
> samples/standalone/calculator/readme.html?
> view=diff&rev=518245&r1=518244&r2=518245
>  
= 
=

> 
> --- incubator/tuscany/java/sca/core-samples/standalone/calculator/
> readme.html (original)
> +++ incubator/tuscany/java/sca/core-samples/standalone/calculator/
> readme.html Wed Mar 14 11:03:12 2007
> @@ -53,7 +53,7 @@
>  To run the client, use the launcher command from
> the standalone distribution:
>  
>  
> -$ java -jar {tuscany.installDir}/bin/launcher target/calc.jar  
{add|

> subtract|multiply|divide} {param} {param}
> +$ java -jar {tuscany.installDir}/bin/launcher.jar target/
> calculator.jar {add|subtract|multiply|divide} {param} {param}
>  
>
>  where tuscany.installDir is the path where you
> installed the standalone distribution.
> @@ -62,7 +62,7 @@
>  The sample when run will display to the standard output:
>  
>  
> -$ java -jar {tuscany.installDir}/bin/launcher target/calc.jar  
add 2 5

> +$ java -jar {tuscany.installDir}/bin/launcher.jar target/
> calculator.jar add 2 5
>  result = 7.0
>  
>  
>
>
>
>  
-

> 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: svn commit: r518245 - /incubator/tuscany/java/sca/core-samples/standalone/calculator/readme.html

[Jeremy Boynes]

Thanks for catching the launcher name.
The application jar though is "calc.jar"

--
Jeremy

On Mar 14, 2007, at 11:03 AM, [EMAIL PROTECTED] wrote:


Author: isilval
Date: Wed Mar 14 11:03:12 2007
New Revision: 518245

URL: http://svn.apache.org/viewvc?view=rev&rev=518245
Log:
use correct file names

Modified:
incubator/tuscany/java/sca/core-samples/standalone/calculator/ 
readme.html


Modified: incubator/tuscany/java/sca/core-samples/standalone/ 
calculator/readme.html
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core- 
samples/standalone/calculator/readme.html? 
view=diff&rev=518245&r1=518244&r2=518245
== 

--- incubator/tuscany/java/sca/core-samples/standalone/calculator/ 
readme.html (original)
+++ incubator/tuscany/java/sca/core-samples/standalone/calculator/ 
readme.html Wed Mar 14 11:03:12 2007

@@ -53,7 +53,7 @@
 To run the client, use the launcher command from  
the standalone distribution:

 
 
-$ java -jar {tuscany.installDir}/bin/launcher target/calc.jar {add| 
subtract|multiply|divide} {param} {param}
+$ java -jar {tuscany.installDir}/bin/launcher.jar target/ 
calculator.jar {add|subtract|multiply|divide} {param} {param}

 

 where tuscany.installDir is the path where you  
installed the standalone distribution.

@@ -62,7 +62,7 @@
 The sample when run will display to the standard output:
 
 
-$ java -jar {tuscany.installDir}/bin/launcher target/calc.jar add 2 5
+$ java -jar {tuscany.installDir}/bin/launcher.jar target/ 
calculator.jar add 2 5

 result = 7.0
 
 



-
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: Trying to run core-samples/standalone/calculator

[Jeremy Boynes]

I cleaned up the doco a little - can you take a look and see if it  
makes sense (and if not fix it :-) )

--
Jeremy

On Mar 14, 2007, at 10:01 AM, Ignacio Silva-Lepe wrote:


Hmm, yeah, I remember doing something like that earlier with the
distribution, but I thought things had changed. In any case, if this
really is the procedure to follow, it should be documented accor-
dingly in the standalone calculator readme.


On 3/14/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Are you just trying to run from the launcher project ? You need to  
get a
standalone runtime from the assembly, that will have the launcher  
and more

stuff as well.

Try unzipping the assembly from :
java\sca\runtime\standalone\assembly\target\assembly-
2.0-alpha2-incubating-SNAPSHOT-bin.zip

And then trying to run as :

java -jar {path-to-launcher.jar} target/calc.jar
{add|subtract|multiply|divide} {param} {param}

--
Luciano Resende
http://people.apache.org/~lresende

On 3/14/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
>
> I'm probably missing something, but according to the readme for  
the core

> samples standalone calculator, I should be able to:
>
> java -jar {path-to-launcher.jar} target/calc.jar
> {add|subtract|multiply|divide} {param} {param}
>
> but when I try it I get NoClassDefFoundError as follows:
>
>
>
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\core-samples 
\standalone\calculat

> or>java -jar
> c:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\standalone\
> launcher\target\launcher-
> 2.0-alpha2-incubating-SNAPSHOT.jartarget\calculator.ja
> r add 2 3
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/tuscany/ru
> ntime/standalone/DirectoryHelper
> at org.apache.tuscany.launcher.Main.main(Main.java:68)
>
> btw, notice that the calculator jar is not named calc.jar
>
> Any ideas about what else I need to specify to get this to run?
>
> Thanks
>




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

Re: svn commit: r517891 - /incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/tuscany/core/model/physical/instancefactory/InjectionSiteMapping.java

[Jeremy Boynes]

Meeraj asked me offline what I meant by using ElementType so I added  
this strawman for a mapping from something in SCA land (a callback,  
reference or property value) to a Java injection site (field, method,  
ctrArg). In the end it doesn't use ElementType at all...


Meeraj, I hope this makes sense :-)
--
Jeremy


On Mar 13, 2007, at 2:50 PM, [EMAIL PROTECTED] wrote:


Author: jboynes
Date: Tue Mar 13 14:50:31 2007
New Revision: 517891

URL: http://svn.apache.org/viewvc?view=rev&rev=517891
Log:
strawman for mapping values to injection sites for the injection  
provider


Added:
incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/ 
tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java   (with props)


Added: incubator/tuscany/java/sca/kernel/core/src/main/java/org/ 
apache/tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ 
core/src/main/java/org/apache/tuscany/core/model/physical/ 
instancefactory/InjectionSiteMapping.java?view=auto&rev=517891
== 

--- incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/ 
tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java (added)
+++ incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/ 
tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java Tue Mar 13 14:50:31 2007

@@ -0,0 +1,115 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tuscany.core.model.physical.instancefactory;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public class InjectionSiteMapping {
+/**
+ * Identifier in SCA terms of the source of the value that  
will be injected.

+ */
+public static class ValueSource {
+public static enum ValueSourceType {
+CALLBACK,
+REFERENCE,
+PROPERTY
+}
+
+private ValueSourceType valueType;
+private String name;
+
+public ValueSourceType getValueType() {
+return valueType;
+}
+
+public void setValueType(ValueSourceType valueType) {
+this.valueType = valueType;
+}
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+/**
+ * Abstraction for a site where a value can be injected.
+ */
+public static abstract class Site {
+}
+
+public static class FieldSite extends Site {
+private String name;
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+public static class MethodSite {
+private String name;
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+public static class ConstructorSite extends Site {
+private int paramIndex;
+
+public int getParamIndex() {
+return paramIndex;
+}
+
+public void setParamIndex(int paramIndex) {
+this.paramIndex = paramIndex;
+}
+}
+
+private ValueSource source;
+private Site site;
+
+public ValueSource getSource() {
+return source;
+}
+
+public void setSource(ValueSource source) {
+this.source = source;
+}
+
+public Site getSite() {
+return site;
+}
+
+public void setSite(Site site) {
+this.site = site;
+}
+}

Propchange: incubator/tuscany/java/sca/kernel/core/src/main/java/ 
org/apache/tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java
-- 


svn:eol-style = native

Propchange: incubator/tuscany/java/sca/kernel/core/src/main/java/ 
org/apache/tuscany/core/model/physical/instancefactory/ 
InjectionSiteMapping.java
-- 


svn:keywords = Rev Date



-

Re: Federating ScopeContainer, was: Change to PhysicalComponentDefinition

[Jeremy Boynes]

On Mar 12, 2007, at 11:47 AM, Jeremy Boynes wrote:


On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:

Firstly, transporting Scope is not enough on its own as there is  
more than one COMPOSITE scope. The builders used to get this from  
the deployment context but with federation it will need to be  
passed to in the PCD. I think instead we should treat  
ScopeContainers as resources and give them IDs like ClassLoaders.  
For COMPOSITE scope the ID can be the URI of the component  
implemented by the composite; for others we can use well known  
IDs. Every component has a scope so I think we can put  
scopeContainerID down in to PCD itself.


Following on with this I'm going to make the following changes to  
the ScopeContainer SPI to externalize the idea of a instance of a  
scope i.e a ScopeContext:

* add methods startContext(Object id) and stopContext(Object id)
  this will place external code in control of the lifecycle of the  
scope context so that it can be initiated
  by the code that dictates the lifecycle. This will allow us to  
avoid having the container register for and

  receive events just to detect context lifetime.
* change get and return wrapper to also pass the contextId
* add a Map to the WorkContext to associate scope  
context ids with the current work
* update the target invoker to get wrappers based on the current  
work context and the component's scope


Taking this a little further I think we need an additional mapping  
here - a component group. This allows us to partition a Scope into  
groups of component that support a common lifetime. The obvious  
application for this is with COMPOSITE scope where there are a group  
of components whose lifetime is tied to that of a composite; a more  
subtle application would be in conjunction with an EAR deployment  
where we want to relate HttpSession scoped components in different  
web applications. This would also allow us to support eagerInit  
semantics for scope types over and above COMPOSITE.


To support this I'm going to add another two method to  
ScopeContainer: createComponentGroup(Object) and removeComponentGroup 
(Object) and change the register/unregister methods to add a  
component group id so that the container can associate the component  
with the group.


--
Jeremy


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

Re: svn commit: r517376 - in /incubator/tuscany/java/sca/kernel/core/src: main/java/org/apache/tuscany/core/marshaller/extensions/ main/java/org/apache/tuscany/core/marshaller/extensions/instancefacto

[Jeremy Boynes]

On Mar 12, 2007, at 1:28 PM, [EMAIL PROTECTED] wrote:
incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/ 
tuscany/core/model/physical/instancefactory/ 
InjectionSiteType.java   (with props)


How about using j.l.annotation.ElementType?
--
Jeremy

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

Re: handling of callbacks with physical wires

[Jeremy Boynes]

On Mar 13, 2007, at 4:55 AM, Jim Marino wrote:


Hi Meeraj,

I've been working on getting the WireAttachers going for  
PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added  
PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for  
callbacks, as they will be used to attach the callback side of a wire.


Instead, how about have the PWSD and PWTD with two interceptor chains  
(forward and callback)? Then WA would just have two methods #attach 
(PWSD) and #attach(PWTD) for the source (reference) side and target  
(service) side respectively. Each one would handle attaching both  
forward and callback chains as needed.


--
Jeremy



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

Re: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception

[Jeremy Boynes]

I have a delete link next to the comment - it may be because I have  
Jira admin rights.

However, I couldn't resolve INFRA-1193 so please could you close that.

--
Jeremy

On Mar 13, 2007, at 9:11 AM, ant elder wrote:

Thanks. Could you say where you go to delete existing comments, i  
couldn't

see how to get to a place in JIRA that allows that?

   ...ant

On 3/13/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I deleted the comments.
--
Jeremy

On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote:

> I have spoken to ant, who has deleted the user.  Ant has raised a
> JIRA,
> https://issues.apache.org/jira/browse/INFRA-1193, to clean up these
> 2 JIRAs.
>
> Kelvin.
>
> On 13/03/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>>
>> Does anybody know what's the Apache process for dealing with
>> stupidity
>> like the referenced comment?
>>
>> Thanks,
>> Frank.
>>
>>  
-

>> 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: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception

[Jeremy Boynes]

I deleted the comments.
--
Jeremy

On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote:

I have spoken to ant, who has deleted the user.  Ant has raised a  
JIRA,
https://issues.apache.org/jira/browse/INFRA-1193, to clean up these  
2 JIRAs.


Kelvin.

On 13/03/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Does anybody know what's the Apache process for dealing with  
stupidity

like the referenced comment?

Thanks,
Frank.

-
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] Updated: (TUSCANY-826) Containment cycle should result in Exception

[Jeremy Boynes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Boynes updated TUSCANY-826:
--

Comment: was deleted

> Containment cycle should result in Exception
> 
>
> Key: TUSCANY-826
> URL: https://issues.apache.org/jira/browse/TUSCANY-826
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
> Environment: Windows XP, both Sun and IBM JVMs
>Reporter: Brian Murray
> Fix For: Java-SDO-Mx
>
> Attachments: ContainmentCycle.patch, ContainmentCycleError.java, 
> ContainmentTest.zip
>
>
> Near the bottom of page 19 in the 2.0.1 specification it is stated that 
> "Containment cannot have cycles.  If a set or add would create a containment 
> cycle an exception is thrown."
> However, I have found that no such exception is thrown.  I will attach a test 
> case showing the creation of (and the potential to infinitely loop through) a 
> containment cycle.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1002) When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded

[Jeremy Boynes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Boynes updated TUSCANY-1002:
---

Comment: was deleted

> When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must 
> be preloaded
> --
>
> Key: TUSCANY-1002
> URL: https://issues.apache.org/jira/browse/TUSCANY-1002
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
>Reporter: Frank Budinsky
>Priority: Minor
> Fix For: Java-SDO-Mx
>
>
> Currently there is a temporary hack in datagraph.xsd (in sdo-api project) to 
> allow us to regenerate sdoModel.xsd with the proper ChangeSummaryType 
> behavior. We need to:
> 1. Remove the temporary hack in datagraph.xsd which is redefining 
> ChangeSummaryType to be a simple type - i.e., put it back to the way it was 
> defined in the spec.
> 2. Add code in XSDHelperImpl ctor to preload the special ChangeSummaryType 
> (which is defined in impl/src/main/resources/xml/sdoModelChangeSummary.xsd) 
> when redefineBuiltIn.equals(ModelFactoryImpl,NAMESPACE_URI).
> With these changes, we will be working as the spec says: The definition of 
> ChangeSummaryType is a complex type in XML (datagraph.xsd), but is treated as 
> a simple data type at the model level.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

[Jeremy Boynes]

On Mar 12, 2007, at 4:05 PM, ant elder wrote:



He didn't give much detail, and hasn't replied when i asked for  
more about

what he was proposing (unless I missed the email?)


Got better things to do - most people understood it which was enough  
for me. You might want to read up on the maven-assembly-plugin.


--
Jeremy


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

Federating ScopeContainer, was: Change to PhysicalComponentDefinition

[Jeremy Boynes]

On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:

Firstly, transporting Scope is not enough on its own as there is  
more than one COMPOSITE scope. The builders used to get this from  
the deployment context but with federation it will need to be  
passed to in the PCD. I think instead we should treat  
ScopeContainers as resources and give them IDs like ClassLoaders.  
For COMPOSITE scope the ID can be the URI of the component  
implemented by the composite; for others we can use well known IDs.  
Every component has a scope so I think we can put scopeContainerID  
down in to PCD itself.


Following on with this I'm going to make the following changes to the  
ScopeContainer SPI to externalize the idea of a instance of a scope  
i.e a ScopeContext:

* add methods startContext(Object id) and stopContext(Object id)
  this will place external code in control of the lifecycle of the  
scope context so that it can be initiated
  by the code that dictates the lifecycle. This will allow us to  
avoid having the container register for and

  receive events just to detect context lifetime.
* change get and return wrapper to also pass the contextId
* add a Map to the WorkContext to associate scope  
context ids with the current work
* update the target invoker to get wrappers based on the current work  
context and the component's scope


--
Jeremy


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

Federating ScopeContainer, was: Change to PhysicalComponentDefinition

[Jeremy Boynes]

This message seems to have been lost - sorry for any dups

From: [EMAIL PROTECTED]
Subject:Federating ScopeContainer, was: Change to 
PhysicalComponentDefinition
Date:   March 12, 2007 11:47:18 AM PDT
To:   tuscany-dev@ws.apache.org

On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:

Firstly, transporting Scope is not enough on its own as there is more
than one COMPOSITE scope. The builders used to get this from the
deployment context but with federation it will need to be passed to in
the PCD. I think instead we should treat ScopeContainers as resources
and give them IDs like ClassLoaders. For COMPOSITE scope the ID can be
the URI of the component implemented by the composite; for others we
can use well known IDs. Every component has a scope so I think we can
put scopeContainerID down in to PCD itself.

Following on with this I'm going to make the following changes to the
ScopeContainer SPI to externalize the idea of a instance of a scope
i.e a ScopeContext:
* add methods startContext(Object id) and stopContext(Object id)
 this will place external code in control of the lifecycle of the
scope context so that it can be initiated
 by the code that dictates the lifecycle. This will allow us to avoid
having the container register for and
 receive events just to detect context lifetime.
* change get and return wrapper to also pass the contextId
* add a Map to the WorkContext to associate scope
context ids with the current work
* update the target invoker to get wrappers based on the current work
context and the component's scope

--
Jeremy

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

Change to PhysicalComponentDefinition

[Jeremy Boynes]

atm, the PCD contains the URI of the component and the definitions  
for all its services and references. The Java sub-class of this adds  
the scope, classloader id, and room for the bytecode for the  
InstanceFactory. I'd like to suggest a couple of changes to this:


Firstly, transporting Scope is not enough on its own as there is more  
than one COMPOSITE scope. The builders used to get this from the  
deployment context but with federation it will need to be passed to  
in the PCD. I think instead we should treat ScopeContainers as  
resources and give them IDs like ClassLoaders. For COMPOSITE scope  
the ID can be the URI of the component implemented by the composite;  
for others we can use well known IDs. Every component has a scope so  
I think we can put scopeContainerID down in to PCD itself.


Secondly, I don't think the PCD needs the service and reference  
definitions. Instead we can replace those with PWDs that connect the  
component either to other local application components or to the  
components provided by the transport implementations. In other words,  
bindings aren't special any more. This will simplify both component  
builders and binding implementations as the former won't need to deal  
with them and the latter simply become transport components with  
wires attached.


Finally, rather than jamming the bytecode directly into the JavaPCD,  
I think it should contain a InstanceFactoryProvider. This will allow  
us to plug providers (e.g. reflective vs. code-genned).


I'm going to start making this last change and integrate the Java and  
System PCDs and builders.

--
Jeremy


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

Re: Simplifying component lifecycle handling

[Jeremy Boynes]

Following on from this, I have deprecated the methods in  
AtomicComponent and Component that should not be needed once we  
transition to the physical builders. Currently, the primary user of  
them is the Connector and that will be transitioning to use the  
PhysicalWireDefinition and will not need to determine the information  
from the live component instance. The remaining usage is virtually  
all test cases for the component implementations and their  
corresponding builders.


--
Jeremy

On Mar 10, 2007, at 9:24 PM, Jeremy Boynes wrote:

I've made a few changes today to simplify the lifecycle handling  
for component instances. Previously, responsibility for this was  
shared between the AtomicComponent implementation, the  
ScopeContainer implementation and the TargetInvoker implementation.  
I have change this to essentially remove the Component  
implementation from the loop so that the majority of the lifecycle  
is controlled purely by the ScopeContainer with a simple  
notification from the TargetInvoker that an invocation has  
completed (needed for STATELESS scoped components).


This has meant one change to the semantic of the conversational  
store in that it is now responsible for persisting  
InstanceWrapper's rather than pure instances.


It has also led to simplification of the AtomicComponent SPI with  
the removal of the init and destroy callbacks. We should also be  
able to remove the get*Instance methods and the flags for  
"optimizable" and "destroyable"


Once this is done then the Component will basically just be  
responsible for instance creation (via the InstanceFactory),  
creating a TargetInvoker (again probably via the InstanceFactory),  
and supporting ComponentContext. This should be generic to most  
component implementation types and so should mean that container  
extensions will not need to provide their own Component  
implementation.


--
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]

Simplifying component lifecycle handling

[Jeremy Boynes]

I've made a few changes today to simplify the lifecycle handling for  
component instances. Previously, responsibility for this was shared  
between the AtomicComponent implementation, the ScopeContainer  
implementation and the TargetInvoker implementation. I have change  
this to essentially remove the Component implementation from the loop  
so that the majority of the lifecycle is controlled purely by the  
ScopeContainer with a simple notification from the TargetInvoker that  
an invocation has completed (needed for STATELESS scoped components).


This has meant one change to the semantic of the conversational store  
in that it is now responsible for persisting InstanceWrapper's rather  
than pure instances.


It has also led to simplification of the AtomicComponent SPI with the  
removal of the init and destroy callbacks. We should also be able to  
remove the get*Instance methods and the flags for "optimizable" and  
"destroyable"


Once this is done then the Component will basically just be  
responsible for instance creation (via the InstanceFactory), creating  
a TargetInvoker (again probably via the InstanceFactory), and  
supporting ComponentContext. This should be generic to most component  
implementation types and so should mean that container extensions  
will not need to provide their own Component implementation.


--
Jeremy


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

[RESULT] Release core-samples for 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

On Mar 9, 2007, at 8:35 AM, Jeremy Boynes wrote:


We had +1's from jmarino, meerajk, isilval, lresende, jboynes
   -0 from jsdelfino

No technical issues were made related to the Parent POM, Kernel and  
Runtime so they are passed.


There was confusion over the use of the composite plugin and the  
archive type so I think that should be withdrawn until resolved.  
The core-samples have been updated not to use it and have since  
been run on OSX and Tomcat but I think we should extend the vote  
for the samples another 24 hours for people to confirm.


I have tested the core-samples on OSX, Luciano has tested them on  
Windows and no-one else has reported any issues so I think we have  
addressed the issues with them. I'll take these three results (spec  
apis, kernel, core-samples) to the IPMC.


Thanks everyone
--
Jeremy


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

Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

[Jeremy Boynes]

Thanks

Perhaps we could set up a side tree with a number of projects that  
built different assemblies (including all the dependencies people  
wanted for them). That way the "build-it-all" approach could be used  
for those assemblies and we wouldn't hit the version skew problems  
doing it naively from the root would cause?


That would also allow people to develop in a modular way, with others  
managing the aggregation of those modules into different assemblies  
(a bit like people assemble Linux distros out of many (hundreds of  
modules).


--
Jeremy

On Mar 9, 2007, at 3:31 PM, [EMAIL PROTECTED] wrote:


Author: lresende
Date: Fri Mar  9 15:31:10 2007
New Revision: 516600

URL: http://svn.apache.org/viewvc?view=rev&rev=516600
Log:
Reverting 516588

Modified:
incubator/tuscany/java/pom.xml

Modified: incubator/tuscany/java/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom.xml? 
view=diff&rev=516600&r1=516599&r2=516600
== 


--- incubator/tuscany/java/pom.xml (original)
+++ incubator/tuscany/java/pom.xml Fri Mar  9 15:31:10 2007
@@ -37,35 +37,9 @@
 

 
-

-
-stable
-
-   true
-
-
-pom/parent
-buildtools
-spec/commonj
-spec/sdo-api
-spec/sca-api-r0.95
-spec/sca-api-r1.0
-sdo
-das
-sca/composite-plugin
-sca/kernel
-sca/runtime
-sca/core-samples
-sca/integration-test
-sca/extensions\spring
-sca/services/transaction/ 
transaction.geronimo

-sca/services/persistence/common
-
-
-
 
 
-all-integration
+all
 
 pom/parent
 buildtools



-
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: svn commit: r516588 - /incubator/tuscany/java/pom.xml

[Jeremy Boynes]

-1
This is contrary to our modularity policy and includes a bunch of  
modules that are not relevant. There are modules in here that are at  
different version levels and merging them in a single reactor build  
will cause problems as mvn adjusts versions to those the reactor.  
This will cause more problems for users.


--
Jeremy

On Mar 9, 2007, at 2:34 PM, [EMAIL PROTECTED] wrote:


Author: lresende
Date: Fri Mar  9 14:34:22 2007
New Revision: 516588

URL: http://svn.apache.org/viewvc?view=rev&rev=516588
Log:
Creating a stable build profile and making it default to avoid  
confusion when people try to build trunk from the root.


Modified:
incubator/tuscany/java/pom.xml

Modified: incubator/tuscany/java/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom.xml? 
view=diff&rev=516588&r1=516587&r2=516588
== 


--- incubator/tuscany/java/pom.xml (original)
+++ incubator/tuscany/java/pom.xml Fri Mar  9 14:34:22 2007
@@ -37,9 +37,35 @@
 

 
+

+
+stable
+
+   true
+
+
+pom/parent
+buildtools
+spec/commonj
+spec/sdo-api
+spec/sca-api-r0.95
+spec/sca-api-r1.0
+sdo
+das
+sca/composite-plugin
+sca/kernel
+sca/runtime
+sca/core-samples
+sca/integration-test
+sca/extensions\spring
+sca/services/transaction/ 
transaction.geronimo

+sca/services/persistence/common
+
+
+
 
 
-all
+all-integration
 
 pom/parent
 buildtools



-
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: requires and policySets attribute support

[Jeremy Boynes]

On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:

What happens in a single node case? Will the controller always be  
present?


Yes - just co-located with its sole runtime.
--
Jeremy


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

Re: [RESULT] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

On Mar 9, 2007, at 9:01 AM, Luciano Resende wrote:


Jeremy

  As for the samples, I'm still seeing the issue/exceptions on tomcat
5.5.20 and tomcat 6.0.10 in windows, did you change anything on the  
samples

to address them ?


Yes - Maven's WAR plugin only adds certain dependency types to the  
WEB-INF/lib directory and "composite" was not recognized. Reverting  
to a JAR to avoid the type confusion means common/calculator gets  
included in the lib directory and the resource is then present.


Did you rebuild the webcalc sample? On mine I now have WEB-INF/lib/ 
calculator-2.0-alpha-incubating.jar in the jar and it works fine.


--
Jeremy


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

[RESULT] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

We had +1's from jmarino, meerajk, isilval, lresende, jboynes
   -0 from jsdelfino

No technical issues were made related to the Parent POM, Kernel and  
Runtime so they are passed.


There was confusion over the use of the composite plugin and the  
archive type so I think that should be withdrawn until resolved. The  
core-samples have been updated not to use it and have since been run  
on OSX and Tomcat but I think we should extend the vote for the  
samples another 24 hours for people to confirm.


Thanks everyone
--
Jeremy

On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:

I have posted release candidates of the 2.0-alpha kernel release on  
my home directory at people.apache.org and uploaded the artifacts  
to the maven repo for:

SCA Parent POM   1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel   2.0-alpha
SCA Runtime  2.0-alpha
SCA Core Samples 2.0-alpha

Please review and then vote on whether we should release them.

These are dependent on the vote for the sca-api's. Also, the JXTA  
module which had a problematic dependency on Bouncy Castle is not  
included in these releases.


Thanks
--
Jeremy

SCA Parent POM
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/pom/sca/1.0-incubating
[pom]http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/1.0-incubating/sca-1.0-incubating.pom
[rat]http://people.apache.org/~jboynes/sca-pom-1.0-incubating/ 
sca-pom-1.0-incubating.rat


SCA Composite Plugin
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/composite-plugin/1.0-incubating
[src]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.tgz
 http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.zip
[rat]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-composite-plugin/1.0-incubating/


SCA Kernel
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/kernel/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-host-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-spi/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-core/2.0-alpha-incubating/


SCA Runtime Environments
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/runtime/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/management/management-jmx/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/maven/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-api/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-host/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/launcher/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.start/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.shutdown/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/assembly/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-host/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-

Re: [VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

And as I forgot to vote, +1
--
Jeremy

On Mar 9, 2007, at 7:57 AM, Jeremy Boynes wrote:

I have uploaded a second amendment of core-samples that reverts to  
using a plain "jar" type for the common composite (r516441) to  
avoid the confusion over a "composite" type. I ran the calc and  
webcalc samples on OSX with Tomcat.


--
Jeremy

On Mar 8, 2007, at 10:32 PM, Jeremy Boynes wrote:

I have uploaded amended versions of the archives for core samples  
with two fixes:
* included the location of the incubator repo containing the  
parent pom (r516312)

* fixed type for webcalc (r516314)

The location for these is still:
  http://people.apache.org/~jboynes/core-samples-2.0-alpha- 
incubating/


--
Jeremy

On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:

I have posted release candidates of the 2.0-alpha kernel release  
on my home directory at people.apache.org and uploaded the  
artifacts to the maven repo for:

SCA Parent POM   1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel   2.0-alpha
SCA Runtime  2.0-alpha
SCA Core Samples 2.0-alpha

Please review and then vote on whether we should release them.

These are dependent on the vote for the sca-api's. Also, the JXTA  
module which had a problematic dependency on Bouncy Castle is not  
included in these releases.


Thanks
--
Jeremy

SCA Parent POM
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/pom/sca/1.0-incubating
[pom]http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/1.0-incubating/sca-1.0-incubating.pom
[rat]http://people.apache.org/~jboynes/sca-pom-1.0-incubating/ 
sca-pom-1.0-incubating.rat


SCA Composite Plugin
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/composite-plugin/1.0-incubating
[src]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.tgz
 http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.zip
[rat]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/tuscany-composite-plugin/1.0-incubating/


SCA Kernel
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/kernel/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-host-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-spi/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-core/2.0-alpha-incubating/


SCA Runtime Environments
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/runtime/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/services/management/management-jmx/ 
2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/services/maven/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/standalone-api/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/standalone-host/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/launcher/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/server.start/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/server.shutdown/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/assembly/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/webapp/webapp-api/2.0-alpha- 

Re: requires and policySets attribute support

[Jeremy Boynes]

Subclassing in the model makes sense to me.

I don't think anything would need to be added to AbstractSCAObject -  
by the time we get to the runtime all of the intents and policySets  
should have been processed and converted into wires with the  
necessary interceptors.


--
Jeremy

On Mar 9, 2007, at 7:26 AM, Mark I. Dinges wrote:

Another person and I are starting to add support for requires and  
policySets attributes to the various elements in the model. One  
possible direction we are considering is to have those model  
objects  that support requires and policySets attributes extend the  
PolicyAttachableModel object. To this object a method would be  
added to handle extracting the requires and policySets attributes  
and would save them. Another option would be to have an instance of  
a PolicyAttachableModel object in each of the model objects that  
support the requires and policySets attributes. Does the community  
have a preference for either of these options or have a suggestion  
for another option?  During the build phase the attributes would be  
processed from the model. This is where the reduction and checking  
for conflicts would take place. Methods would be added to  
AbstractSCAObject to add/get intents and policsySets.This would  
make it so that the  various implementations of the model would  
inherit them.


-
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: [VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

I have uploaded a second amendment of core-samples that reverts to  
using a plain "jar" type for the common composite (r516441) to avoid  
the confusion over a "composite" type. I ran the calc and webcalc  
samples on OSX with Tomcat.


--
Jeremy

On Mar 8, 2007, at 10:32 PM, Jeremy Boynes wrote:

I have uploaded amended versions of the archives for core samples  
with two fixes:
* included the location of the incubator repo containing the parent  
pom (r516312)

* fixed type for webcalc (r516314)

The location for these is still:
  http://people.apache.org/~jboynes/core-samples-2.0-alpha-incubating/

--
Jeremy

On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:

I have posted release candidates of the 2.0-alpha kernel release  
on my home directory at people.apache.org and uploaded the  
artifacts to the maven repo for:

SCA Parent POM   1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel   2.0-alpha
SCA Runtime  2.0-alpha
SCA Core Samples 2.0-alpha

Please review and then vote on whether we should release them.

These are dependent on the vote for the sca-api's. Also, the JXTA  
module which had a problematic dependency on Bouncy Castle is not  
included in these releases.


Thanks
--
Jeremy

SCA Parent POM
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/pom/sca/1.0-incubating
[pom]http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/1.0-incubating/sca-1.0-incubating.pom
[rat]http://people.apache.org/~jboynes/sca-pom-1.0-incubating/ 
sca-pom-1.0-incubating.rat


SCA Composite Plugin
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/composite-plugin/1.0-incubating
[src]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.tgz
 http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.zip
[rat]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/tuscany-composite-plugin/1.0-incubating/


SCA Kernel
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/kernel/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-host-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-spi/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/kernel/tuscany-core/2.0-alpha-incubating/


SCA Runtime Environments
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/runtime/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/services/management/management-jmx/ 
2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/services/maven/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/standalone-api/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/standalone-host/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/launcher/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/server.start/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/server.shutdown/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/standalone/assembly/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/sca/runtime/webapp/webapp-api/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/ 
org/apache/tuscany/

Re: [VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

I have fixed the two technical issues here (the location of the  
parent pom and the type of the composite) and uploaded a new copy of  
the files for core-samples.


--
Jeremy


On Mar 8, 2007, at 4:27 PM, Jean-Sebastien Delfino wrote:



-0 from me.

I tried the release and ran into several issues with the assembly  
distribution and the samples:


- assembly-2.0-alpha-incubating-bin.tar.gz should unpack in an  
asssembly-x.0-alpha-incubating directory instead of the current  
directory


- The tuscany Jars are missing a tuscany-prefix

- Broken links in the core-samples/readme.html

- The samples failed to build until I went and built the java/pom/ 
sca Maven module from the release tag. The pom for that sca module  
should part of the release and published in a Maven repos.


- The webapp sample fails to build with the following error:

[INFO]  
-- 
--

[ERROR] BUILD ERROR
[INFO]  
-- 
--

[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.tuscany.sca.core-samples.common:calculator:jar:2.0- 
alpha-incubating


 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=org.apache.tuscany.sca.core- 
samples.common -DartifactId=calculator \
 -Dversion=2.0-alpha-incubating -Dpackaging=jar -Dfile=/ 
path/to/file


 Path to dependency:
   1) org.apache.tuscany.sca.core-samples.webapp:webcalc:war: 
2.0-alpha-incubating
   2) org.apache.tuscany.sca.core-samples.common:calculator:jar: 
2.0-alpha-incubating


--
1 required artifact is missing.

for artifact:
 org.apache.tuscany.sca.core-samples.webapp:webcalc:war:2.0-alpha- 
incubating


I think that it's because webcalc/pom.xml is missing a   
composite statement.


I also have two concerns:
- I am concerned that this release requires Maven expertise to  
build the samples (we had an alternative with Ant in M1, and IMO we  
should have had one in M2 as well).
- Also I find the release name 2.0-alpha confusing. After 1.0-M1  
and 1.0-M2 I would expect a 1.0-alpha instead of a 2.0-alpha.


--
Jean-Sebastien


-
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: [VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

I have uploaded amended versions of the archives for core samples  
with two fixes:
* included the location of the incubator repo containing the parent  
pom (r516312)

* fixed type for webcalc (r516314)

The location for these is still:
  http://people.apache.org/~jboynes/core-samples-2.0-alpha-incubating/

--
Jeremy

On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:

I have posted release candidates of the 2.0-alpha kernel release on  
my home directory at people.apache.org and uploaded the artifacts  
to the maven repo for:

SCA Parent POM   1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel   2.0-alpha
SCA Runtime  2.0-alpha
SCA Core Samples 2.0-alpha

Please review and then vote on whether we should release them.

These are dependent on the vote for the sca-api's. Also, the JXTA  
module which had a problematic dependency on Bouncy Castle is not  
included in these releases.


Thanks
--
Jeremy

SCA Parent POM
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/pom/sca/1.0-incubating
[pom]http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/1.0-incubating/sca-1.0-incubating.pom
[rat]http://people.apache.org/~jboynes/sca-pom-1.0-incubating/ 
sca-pom-1.0-incubating.rat


SCA Composite Plugin
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/composite-plugin/1.0-incubating
[src]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.tgz
 http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.zip
[rat]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-composite-plugin/1.0-incubating/


SCA Kernel
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/kernel/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-host-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-spi/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-core/2.0-alpha-incubating/


SCA Runtime Environments
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/sca/runtime/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/management/management-jmx/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/maven/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-api/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-host/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/launcher/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.start/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.shutdown/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/assembly/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-host/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-war-plugin/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-itest-plugin/2.0-alpha-incubating/
[binary]

Re: Composite archive name confusion, was: Re: sca-composite plugin

[Jeremy Boynes]

Yep - .car is used by Geromimo (and is also confusing with a JavaEE CAR)
  .sar is used by JBoss

And everyone seems to hate .scar :-(
--
Jeremy

On Mar 8, 2007, at 10:27 PM, Raymond Feng wrote:

Thinking of ".car" or ".sar", but it seems both are used by other  
systems. We are running out of "_ar"!


Thanks,
Raymond

- Original Message - From: "Jeremy Boynes"  
<[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 08, 2007 10:11 PM
Subject: Re: Composite archive name confusion, was: Re: sca- 
composite plugin




Any suggestions?
--
Jeremy

On Mar 8, 2007, at 7:55 PM, Luciano Resende wrote:


Hi Jeremy

  The SCA Assembly spec defines .composites files as definitions of
composites. Wouldn't be very confusing to developers and our   
community in
general to see .composite files representing archives ? At least   
this is

what I saw while reviewing the core-samples release candidate, a
calculator-2.0-alpha-incubating.composite that is actually an  
archive

containing common files for the calculator sample application.

Thoughts ?

On 3/2/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I made a start on this (r513843) - atm it just supports
composite but I'll see about adding the
contribution and itest stuff as well.
--
Jeremy

On Feb 26, 2007, at 2:27 PM, Jeremy Boynes wrote:

> [[ another resend due to flaky email service ]]
>
> I've been thinking about adding a Maven plugin that can be  
used to

> build an sca-composite. This would:
> * copy resources
> * compile the code
> * run any unit tests
> * package the composite as a jar (including any sca-contribution
file)
> * run any integration tests
>
> This would make building reusable composites (like common/
calculator)
> a bit easier as all you'd have to do in your pom is set the
packaging
> to sca-composite and include the plugin.
>
> One question I have would be the file extension to associate
with such
> an archive. In the spec group we've joked about 'scar' files  
but I
> might just go with that unless someone has a better  
alternative :-)

>
> --
> 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]





--
Luciano Resende
http://people.apache.org/~lresende



-
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: Composite archive name confusion, was: Re: sca-composite plugin

[Jeremy Boynes]

Any suggestions?
--
Jeremy

On Mar 8, 2007, at 7:55 PM, Luciano Resende wrote:


Hi Jeremy

  The SCA Assembly spec defines .composites files as definitions of
composites. Wouldn't be very confusing to developers and our  
community in
general to see .composite files representing archives ? At least  
this is

what I saw while reviewing the core-samples release candidate, a
calculator-2.0-alpha-incubating.composite that is actually an archive
containing common files for the calculator sample application.

Thoughts ?

On 3/2/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I made a start on this (r513843) - atm it just supports
composite but I'll see about adding the
contribution and itest stuff as well.
--
Jeremy

On Feb 26, 2007, at 2:27 PM, Jeremy Boynes wrote:

> [[ another resend due to flaky email service ]]
>
> I've been thinking about adding a Maven plugin that can be used to
> build an sca-composite. This would:
> * copy resources
> * compile the code
> * run any unit tests
> * package the composite as a jar (including any sca-contribution  
file)

> * run any integration tests
>
> This would make building reusable composites (like common/ 
calculator)
> a bit easier as all you'd have to do in your pom is set the  
packaging

> to sca-composite and include the plugin.
>
> One question I have would be the file extension to associate  
with such

> an archive. In the spec group we've joked about 'scar' files but I
> might just go with that unless someone has a better alternative :-)
>
> --
> 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]





--
Luciano Resende
http://people.apache.org/~lresende



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

[RESULT] Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

We had +1's from jmarino, meerajk, isilval, jboynes, lresende,  
kelvingoodson, and svkrish

   +0.9 from rfeng
and no -1's

There was concern from jsdelfino, lresende and rfeng about the  
possibility of spec changes during final publication and jboynes  
described how the version number scheme could be used to address that.


I'll ask the IPMC to ratify this. I may wait until the kernel vote  
completes so that they can do both at once.


Thanks everyone.
--
Jeremy

On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:

Please vote to approve the release of the sca-api's for r1.0 of the  
specification. This is the API code that we recently reviewed but  
please vote again to confirm the release.


[tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/spec/sca-api-r1.0/1.0-incubating


[src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.tgz
  http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.zip
[rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating.rat


[pom] http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom
[binary]  http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar
[javadoc] http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating- 
javadoc.jar


Thanks
--
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: JavaComponent and PhysicalOperationDefinition changes, r515719

[Jeremy Boynes]

On Mar 7, 2007, at 6:24 PM, Jim Marino wrote:
It should be the Multiparent CL from the ClassLoaderRegistry. It  
looks like Jeremy got the multi-parent loading merged with the  
composite classloader in r515464. This classloader will load the  
impl class and we can use those to in turn load the param types.


I merged the multi-parent functionality into the CompositeClassLoader  
but it is not yet used. I plan to revamp the loaders to use the  
ClassLoaderRegistry rather than rely on the classloader in the  
DeploymentContext.


The ClassLoader definition will be sent to the target runtime as part  
of the PCS as one of the local resources. That should be there (in  
the CLR) ready for you to use during physical build.


--
Jeremy


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

Re: Getting rid of AtomicComponent

[Jeremy Boynes]

On Mar 7, 2007, at 6:42 PM, Jim Marino wrote:

When we convert over to the federated marhsallers, I think we can  
get rid of AtomicComponent and just have Component. To do this, we  
would need to move some of the lifecycle getters such as  
conversational lifetime, etc. to Component. The other change we  
would need to do is have InstanceWrapper handle init() and destroy 
() callbacks. I think we can do this by having the wrapper  
generated on the controller and serialized across. This would allow  
us to eliminate reflection. Finally, JavaTargetInvoker (should be  
renamed) would then deal with InstanceWrappers which it obtained  
from the ScopeContainer, as opposed to AtomicComponent.


What do people think?


I started down that route a while ago refactoring InstanceWrapperImpl  
to be one specialization of InstanceWrapperBase that used the current  
mechanism of delegating back to the component (at least until we  
could clean that up).


Have a look at PhysicalComponentTestCase for an example of what a  
generated alternative would look like.

--
Jeremy


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

OSOA schemas, was Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

I'd add that the API jar here does *not* contain the schemas.

We don't have approval yet for the 3rd party license covering the  
ones on the OSOA site and to my knowledge do not yet have versions  
available under the Apache License.

--
Jeremy

On Mar 7, 2007, at 9:59 AM, Mike Edwards wrote:


Folks,

With my spec hat on - the NAMES of the specs ain't going to change.

However, some of the FILES belonging to the spec are VERY likely to  
change before publication.  I know FOR SURE that sca-core.xsd is  
going to change from the currently published version, since the  
Assembly WG agreed the changes yesterday.  The problem is that  
there are errors in some of the files that *MUST* get fixed before  
the 1.0 publication.


Some of the problems were raised by Tuscany team members - so  
thanks for those !


PS If anyone spots more problems with those files, be sure to let  
the spec folks know


Yours,  Mike.

Jim Marino wrote:

On Mar 6, 2007, at 11:13 AM, Raymond Feng wrote:

Hi,

I think we used r0.95 in M2 but SCA spec 0.95 was published in  
that  case. Now we use r1.0 ahead of the official SCA 1.0 spec.  
If we  feel 1.0.1-incubating could be used to fix minor issuesin  
our  release to catch up the final SCA 1.0 if there are any  
changes, I'm  OK with the release (+0.9).
Putting my spec hat on, I can pretty confidently say the chances  
of  content changes to the specs are remote at best. I'd  
characterize  'remote' as the possibility of getting 20 lawyers  
together and having  them agree on something that generates more  
work for them :-)
Also, the current versioning scheme will allow us to accommodate   
additional errata to the ones we already filed.

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]

Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

On Mar 6, 2007, at 7:03 PM, Jim Marino wrote:



Putting my spec hat on, I can pretty confidently say the chances of  
content changes to the specs are remote at best. I'd characterize  
'remote' as the possibility of getting 20 lawyers together and  
having them agree on something that generates more work for them :-)




Wouldn't that depend on whether they were billing hourly? :-)
--
Jeremy



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

Re: [VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

On Mar 6, 2007, at 12:01 PM, Luciano Resende wrote:

Bellow, a list of minor issues that we had in past releases, and  
were all

questioned by IPMC :

- Artifacts does not have tuscany- prefix.

- Assembly/standalone distribution is extracting to current directory,
instead of a subdirectory

- For the artifacts that are being extracted to it's own subdirectory,
should we use version number on the directory names (e.g
core-samples-2.0-alpha-incubating instead of core-samples)


For the issue above, I kept the structure in line with what we had  
previously.




- Source distributions (e.g
kernel-2.0-alpha-incubating.zipand
runtime-2.0-alpha-incubating.zip)

does not follow the convention of having a -src sufix on the artifact
name.


Thanks. In order not to break the links in the mail, I've linked  
these to copies with -src in the name. If the vote goes through I'll  
move those to the dist site.




- Couple broken links in core-samples/readme.html

Other then that, samples are working fine with the standalone  
distribution,

but I haven't tested the webapp one.


Good, thanks
--
Jeremy

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

Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

The naming convention is that used by other Apache projects that  
provide independent implementations of spec APIs:

* r1.0 in the artifactId refers to the revision of the spec
* 1.0-incubating in the version refers to our release

If the spec changes their version number between now and final  
release (which I think is unlikely but you never know) then we would  
change r1.0 to match. If there is in an error in our implementation  
or additional errata are published for the spec (but with the same  
version number) then we would release 1.0.1-incubating or 1.1- 
incubating depending on the nature of the change.


This is the same convention we used for the 0.95 APIs released in  
conjunction with M2.


--
Jeremy

On Mar 6, 2007, at 8:40 AM, Luciano Resende wrote:

I think Sebastien's comments about the naming are a valid one, what  
are we

going to call when the spec 1.0 get released ? Other then that, +1.

On 3/6/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


+1

--
Jeremy

On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:

> Please vote to approve the release of the sca-api's for r1.0 of the
> specification. This is the API code that we recently reviewed but
> please vote again to confirm the release.
>
> [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/
> java/spec/sca-api-r1.0/1.0-incubating
>
> [src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
> incubating/sca-api-r1.0-1.0-incubating-src.tgz
>   http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
> incubating/sca-api-r1.0-1.0-incubating-src.zip
> [rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
> incubating/sca-api-r1.0-1.0-incubating.rat
>
> [pom] http://people.apache.org/repo/m2-incubating-repository/
> org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0- 
incubating.pom

> [binary]  http://people.apache.org/repo/m2-incubating-repository/
> org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0- 
incubating.jar

> [javadoc] http://people.apache.org/repo/m2-incubating-repository/
> org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating-
> javadoc.jar
>
> Thanks
> --
> 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]





--
Luciano Resende
http://people.apache.org/~lresende



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

Classloader isloation, was: ITest & multiple composites

[Jeremy Boynes]

On Mar 6, 2007, at 2:10 AM, Dan Murphy wrote:

probably due to my j2ee experiences... I was wondering how / if the  
runtime
would react to different versions of the same component/composite,  
but I'm
sure we have some for of classloader isolation that would handle  
this...


In 1.x we associated classloaders with composites and the classloader  
hierarchy matched the composition tree. Users could add to the  
classpath for each composite classloader using  elements  
in the SCDL. There were problems sharing classes between the runtime  
and application (e.g. SDO or Spring framework classes).


In 2.x we want to support sparse component trees and so are  
decoupling the classloader hierarchy from the composition hierarchy.  
ClassLoaders will simply be resources that get created in a physical  
runtime and referenced by component containers.


just use to the j2ee way and had assumed (due to launcher's command  
line
arguments) that composites needed to be packaged (in a jar or  
similar) so
that they could be contributed to the domain - obviously got that  
wrong :)


That made sense in 1.x. For 2.0-alpha we wanted to move to a model  
where the launcher was given a component to launch (of the "launched"  
implmentation type) and would resolve the resources from the domain  
(i.e. based on contributed classes). There's still work to be done on  
the ContributionService to support that so for now we're still basing  
it on the jar. That should change for alpha2.


--
Jeremy



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

Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

+1

--
Jeremy

On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:

Please vote to approve the release of the sca-api's for r1.0 of the  
specification. This is the API code that we recently reviewed but  
please vote again to confirm the release.


[tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ 
java/spec/sca-api-r1.0/1.0-incubating


[src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.tgz
  http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.zip
[rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating.rat


[pom] http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom
[binary]  http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar
[javadoc] http://people.apache.org/repo/m2-incubating-repository/ 
org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating- 
javadoc.jar


Thanks
--
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]

[VOTE] Release 2.0-alpha of SCA Java kernel

[Jeremy Boynes]

I have posted release candidates of the 2.0-alpha kernel release on  
my home directory at people.apache.org and uploaded the artifacts to  
the maven repo for:

SCA Parent POM   1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel   2.0-alpha
SCA Runtime  2.0-alpha
SCA Core Samples 2.0-alpha

Please review and then vote on whether we should release them.

These are dependent on the vote for the sca-api's. Also, the JXTA  
module which had a problematic dependency on Bouncy Castle is not  
included in these releases.


Thanks
--
Jeremy

SCA Parent POM
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
pom/sca/1.0-incubating
[pom]http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/1.0-incubating/sca-1.0-incubating.pom
[rat]http://people.apache.org/~jboynes/sca-pom-1.0-incubating/sca- 
pom-1.0-incubating.rat


SCA Composite Plugin
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
sca/composite-plugin/1.0-incubating
[src]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.tgz
 http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.zip
[rat]http://people.apache.org/~jboynes/composite-plugin-1.0- 
incubating/composite-plugin-1.0-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-composite-plugin/1.0-incubating/


SCA Kernel
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
sca/kernel/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/kernel-2.0-alpha- 
incubating/kernel-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-host-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-spi/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/kernel/tuscany-core/2.0-alpha-incubating/


SCA Runtime Environments
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
sca/runtime/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.tgz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.zip
[rat]http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/runtime-2.0-alpha-incubating.rat
[maven]  http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/management/management-jmx/2.0- 
alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/services/maven/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-api/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/standalone-host/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/launcher/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.start/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/server.shutdown/2.0-alpha- 
incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/standalone/assembly/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-api/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/sca/runtime/webapp/webapp-host/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-war-plugin/2.0-alpha-incubating/
 http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/tuscany/tuscany-itest-plugin/2.0-alpha-incubating/
[binary] http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/assembly-2.0-alpha-incubating-bin.tar.gz
 http://people.apache.org/~jboynes/runtime-2.0-alpha- 
incubating/assembly-2.0-alpha-incubating-bin.zip


SCA Core Samples
[tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
sca/core-samples/2.0-alpha-incubating
[src]http://people.apache.org/~jboynes/co

Re: ITest & multiple composites

[Jeremy Boynes]

On Mar 5, 2007, at 2:10 PM, Dan Murphy wrote:



There may be some confusion here over "deploy." In SCA you don't
"deploy" applications in the traditional sense - you contribute
implementations to a domain and then assemble component hierarchies
from them.



Interesting, I appreciated that there was no deploy (ala J2EE) but had
assumed that composites were isolated. I guess I misinterpreted the  
reasons

behind Sebastien's separation to run under different vms...


Not sure what you mean by "isolated" but composites are logical  
groupings (er, compositions :-) ) of components that are orthogonal  
to the physical topology. Unless the composite is specifically marked  
"local" or unless connected by local references, the components in a  
single composite could quite easily be running in different physical  
runtimes. Supporting this core architectural tenet in a federated  
world is one of the changes going on in trunk atm.


--
Jeremy


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

Updating Tuscany SCA namespace

[Jeremy Boynes]

I am going to update the XML namespace in trunk to match the release  
version, specifically
* system namespace to http://tuscany.apache.org/xmlns/sca/system/2.0- 
alpha

* user namespace to http://tuscany.apache.org/xmlns/sca/2.0-alpha

However, as the physical marshallers are still experimental I am not  
going to change those for now (they will still be -SNAPSHOT even in  
the release).

--
Jeremy


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

Re: ITest & multiple composites

[Jeremy Boynes]

On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote:


Hi Jeremy,

I think what you're suggesting is along the lines of the 'whilst I  
could
deploy nested composites' thought (I may have misunderstood you  
though)...
I would have liked to deploy two separate composites as it seemed  
likely
that the code path could be different when using nested composites  
(which I
also planned to do, presuming these would be optimised) this  
way I would

end up with tests for databindings test for :
inter component
inter composite (in a nested composite)
inter composite (not nested)
Does that make sense ?


Not really.

There may be some confusion here over "deploy." In SCA you don't  
"deploy" applications in the traditional sense - you contribute  
implementations to a domain and then assemble component hierarchies  
from them.


The itest plugin is designed for users to test their applications. If  
you want to test the internals of a databinding or how it is  
activated by the fabric, I'd suggest testing that directly. You can  
get much better coverage using the internal SPIs than you can with a  
fairly convoluted multi-vm setup. And that wouldn't involve  
"deploying" anything.


If you look at trunk, we optimize away the implementations of  
composites and just have connections between leaf components so all  
of that would come down to "inter component." There are two forms  
that can take:

* connection between two components in the same VM
* binding of component service or reference to a transport

Each of those only requires a single VM to test.



Ideally I would like to do the inter composite (not nested) between  
2 jvms,

Sebastien's did something similar (although in a single JVM) by
instantiating a second SCATestCase to deploy additional composites (
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca- 
java-integration/testing/sca/itest/bindings/bindingsclient/src/test/ 
java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java

)
I was wondering if the there are plans to improve iTest (& plugin if
applicable) to facilitate multi-vm / non-nested multiple composite  
testing.


The itest plugin works by "deploying" a test composite to a local  
domain running inside Maven. With SCA's abstraction of the  
environment from the programming model, that provides quite a lot of  
support for integration testing of a composite.


I think it would be good to support "deployment" to a different  
domain, which really means contributing the composite to a remote  
server through a remote ContributionService - something a bit like  
Cargo would be good to have.


Another improvement would be a mock framework for composites that  
allow the simulation of external references - I've been wondering  
about integrating the itest plugin with EasyMock for that.


Those are both just ideas rather than "plans" - if this is something  
that interests you jump on in.

--
Jeremy


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

Re: Site switch to the cwiki

[Jeremy Boynes]

It looks like it's using:
http://cwiki.apache.org/ 
TUSCANY/"  />

which may take a sec to kick in as the page is being rendered.

I would suggest making the page really short - if we're not using the  
generated site any longer you could just replace the root page with  
one that just does the redirect.


If the server allows, another alternative would be to install  
a .htaccess file with a redirect in it:

Redirect /tuscany http://cwiki.apache.org/TUSCANY/
(or something like that). If .htaccess is disabled you might ask  
infra for help.


--
Jeremy

On Mar 5, 2007, at 9:45 AM, Jim Marino wrote:

Looks like something in Anakia when it renders the html...let me  
look into it.


Jim

On Mar 5, 2007, at 8:52 AM, Luciano Resende wrote:


Hi Jim

  Looks like you did a redirect on the original site, and when I  
try to
access the Tuscany page, it quickly shows the original site (in  
html) and
then it redirects it to the cWiki one. Isn't there a cleaner way  
of doing

this ? I see other sites using wiki as it's website working fine.

BTW, I tried o get an anser at #asfinfra, but looks like people  
are still a

little slow there, might be morning hours.

--
Luciano Resende
http://people.apache.org/~lresende

On 3/4/07, Jim Marino <[EMAIL PROTECTED]> wrote:


FYI,

I've cut-over the site to using the cwiki which should go live as
soon as the files replicate. I left the old site files in place
under /site as there are still a few wiki links which point back to
them (mainly the download pages). I'll try and convert those over as
well over the next day.

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]

Re: ITest & multiple composites

[Jeremy Boynes]

I believe the itest plugin already supports this. The harness SCDL  
refers to the test composite that includes/uses the composite-under- 
test and that can in turn include/use nested composites. Classpath  
extension through  elements can be used to add  
implementation dependencies and inner scdl files can be located using  
scdlResource/scdlLocation attributes.


To just test inter-composite communication you could just have the  
test composite use two other composites as implementations (i.e. two  
components with )


HTH
--
Jeremy

On Mar 5, 2007, at 6:42 AM, Dan Murphy wrote:


Hi,

Is there anything planned for iTest to allow one to deploy multiple
composites in the same domain?

As I understand it, currently there is onlya setApplicationSCDL in the
SCATestCase, so whilst I could deploy nested composites, I can't  
deploy

muliple composites easily to test inter composite commuication.

Anyone working on this ?

Cheers,
Dan



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

Sourcecheck failures in core

[Jeremy Boynes]

I get a a bunch of sourcecheck failures in core (including PMD  
failures) - many of these relate to the marshallers and contribution  
service so Meeraj, Luciano, please could you clean them up.


Thanks
--
Jeremy


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

Preparing to release trunk

[Jeremy Boynes]

I have tagged the sca parent pom in preparation for releasing trunk  
and am about to update the individual modules to use it. I am going  
to hold off from deploying the pom to the release repository for now  
so until then it will be necessary to build it locally first:

  $ cd tags/java/pom/sca/1.0-incubating
  $ mvn install

I am also going to update trunk to use the candidate spec api jar  
that we are currently voting on.

--
Jeremy

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

[VOTE] Release 1.0-incubating version of sca-api-r1.0

[Jeremy Boynes]

Please vote to approve the release of the sca-api's for r1.0 of the  
specification. This is the API code that we recently reviewed but  
please vote again to confirm the release.


[tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/ 
spec/sca-api-r1.0/1.0-incubating


[src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.tgz
  http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating-src.zip
[rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- 
incubating/sca-api-r1.0-1.0-incubating.rat


[pom] http://people.apache.org/repo/m2-incubating-repository/org/ 
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom
[binary]  http://people.apache.org/repo/m2-incubating-repository/org/ 
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar
[javadoc] http://people.apache.org/repo/m2-incubating-repository/org/ 
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating-javadoc.jar


Thanks
--
Jeremy


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