On Tue, Apr 21, 2009 at 11:57 PM, ant elder wrote:
>> Hi Ant,
>>
>> I always thought having -xml module as a good approach, in terms of
>> spring I see this module as independent module without any dependencies from
>> spring binaries. Are we following any nomenclature to split the modules? ma
On Wed, Apr 22, 2009 at 7:57 AM, Luciano Resende wrote:
> On Tue, Apr 21, 2009 at 11:52 PM, ant elder wrote:
> >
> >
> > On Wed, Apr 22, 2009 at 7:50 AM, Luciano Resende
> > wrote:
> >>
> >> On Tue, Apr 21, 2009 at 11:37 PM, ant elder
> wrote:
> >> >
> >> > I don't actually see any serious issu
On Wed, Apr 22, 2009 at 12:02 AM, ant elder wrote:
>
> Lets not argue if this is going to be changed anyway, but just labeling
> things "breaking" or "hacking" doesn't make it something true. A valid
> export is what *we* decide is what we want the module to export. Any new
> module is going to us
On Tue, Apr 21, 2009 at 1:35 PM, ant elder wrote:
> I think we've consensus now that instead of having three maven modules
> (model/model-xml/model-runtime) its ok to have the model and model-xml in a
> single module
It seems that statement may not be true :(
I think it would be good to be con
On Wed, Apr 22, 2009 at 12:08 AM, Giorgio Zoppi wrote:
> I'm working in two direction:
> * bindingg.p2p - I'm going to provide a way to publish a service uri
> in a DHT with a Chord Algorithm, using Overlayweaver
> * implementation.python - a native python (CPython) implementation for
> components
On Wed, Apr 22, 2009 at 12:13 AM, ant elder wrote:
>
>
> On Tue, Apr 21, 2009 at 1:35 PM, ant elder wrote:
>>
>> I think we've consensus now that instead of having three maven modules
>> (model/model-xml/model-runtime) its ok to have the model and model-xml in a
>> single module
>
> It seems that
On Wed, Apr 22, 2009 at 8:26 AM, Luciano Resende wrote:
> On Wed, Apr 22, 2009 at 12:13 AM, ant elder wrote:
> >
> >
> > On Tue, Apr 21, 2009 at 1:35 PM, ant elder wrote:
> >>
> >> I think we've consensus now that instead of having three maven modules
> >> (model/model-xml/model-runtime) its ok
2009/4/22 ant elder :
>
>
> On Wed, Apr 22, 2009 at 12:08 AM, Giorgio Zoppi
> wrote:
>>
>> I'm working in two direction:
>> * bindingg.p2p - I'm going to provide a way to publish a service uri
>> in a DHT with a Chord Algorithm, using Overlayweaver
>> * implementation.python - a native python (CPy
On Wed, Apr 22, 2009 at 8:30 AM, Giorgio Zoppi
wrote:
> 2009/4/22 ant elder :
> >
> >
> > On Wed, Apr 22, 2009 at 12:08 AM, Giorgio Zoppi >
> > wrote:
> >>
> >> I'm working in two direction:
> >> * bindingg.p2p - I'm going to provide a way to publish a service uri
> >> in a DHT with a Chord Algor
On Wed, Apr 22, 2009 at 12:29 AM, ant elder wrote:
>> Are we talking only about extensions (bindings and implementations) ?
>
> I'm suggesting everything.
>
>>
>> For other modules, I'd suggest we check case by case, as I have the
>> same concerns expressed by Raymond on this thread.
>>
>
> But wh
Might as well explore this one too at the same time as the *-xml module
discussion ;)
What are the reasons for having the -policy modules separate from the
-runtime modules?
There aren't so many of these, just binding-jms-policy and
binding-ws-axis2-policy, i'd like to merge those into the associ
On Wed, Apr 22, 2009 at 8:30 AM, Giorgio Zoppi
wrote:
>
>
> Just a question: Tuscany and cloud computing, any idea?
Now that Google App Engine is supporting Java, it would be a good idea
to have Tuscany/SCA running on this environment
Thoughts ?
--
Luciano Resende
Apache Tuscany, Apache
On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende wrote:
> On Wed, Apr 22, 2009 at 12:29 AM, ant elder wrote:
> >> Are we talking only about extensions (bindings and implementations) ?
> >
> > I'm suggesting everything.
> >
> >>
> >> For other modules, I'd suggest we check case by case, as I have
On Wed, Apr 22, 2009 at 12:42 AM, ant elder wrote:
> Might as well explore this one too at the same time as the *-xml module
> discussion ;)
>
> What are the reasons for having the -policy modules separate from the
> -runtime modules?
>
> There aren't so many of these, just binding-jms-policy and
On Wed, Apr 22, 2009 at 12:45 AM, ant elder wrote:
>> > But what are those concerns? No one has ever given any technical reasons
>> > for
>> > keeping them separate that makes sense if we're not doing it
>> > consistently.
>> >
>>
>> Having the xml processors in a separate module would allow us ex
On Wed, Apr 22, 2009 at 8:47 AM, Luciano Resende wrote:
> On Wed, Apr 22, 2009 at 12:42 AM, ant elder wrote:
> > Might as well explore this one too at the same time as the *-xml module
> > discussion ;)
> >
> > What are the reasons for having the -policy modules separate from the
> > -runtime mod
On Wed, Apr 22, 2009 at 8:45 AM, ant elder wrote:
>
>
> On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende
> wrote:
>>
>> On Wed, Apr 22, 2009 at 12:29 AM, ant elder wrote:
>> >> Are we talking only about extensions (bindings and implementations) ?
>> >
>> > I'm suggesting everything.
>> >
>> >>
>
On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws wrote:
> On Wed, Apr 22, 2009 at 8:45 AM, ant elder wrote:
> >
> >
> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende
> > wrote:
> >>
> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elder
> wrote:
> >> >> Are we talking only about extensions (bindings an
snip...
>
> TUSCANY-2167 was caused by the base policy modules including WS binding
> policy and dragging in some WS dependencies wasn't it? So thats fixed now
> and isn't any issue with merging binding-ws-axis2-policy in the
> binding-ws-axis2 module is it?
>
> ...ant
>
>
I made most of these
On Wed, Apr 22, 2009 at 12:51 AM, ant elder wrote:
>
>
> TUSCANY-2167 was caused by the base policy modules including WS binding
> policy and dragging in some WS dependencies wasn't it? So thats fixed now
> and isn't any issue with merging binding-ws-axis2-policy in the
> binding-ws-axis2 module i
On Wed, Apr 22, 2009 at 12:56 AM, ant elder wrote:
>
>
> Ok and thats the same as what Luciano just mentioned in another post to this
> thread. So...if we had a way to enable/disable support for either namespace
> independent of pulling modules in/out of the classpath would that address
> this con
On Wed, Apr 22, 2009 at 8:56 AM, ant elder wrote:
>
>
> On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws
> wrote:
>>
>> On Wed, Apr 22, 2009 at 8:45 AM, ant elder wrote:
>> >
>> >
>> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende
>> > wrote:
>> >>
>> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elde
On Wed, Apr 22, 2009 at 8:59 AM, Luciano Resende wrote:
> On Wed, Apr 22, 2009 at 12:51 AM, ant elder wrote:
> >
> >
> > TUSCANY-2167 was caused by the base policy modules including WS binding
> > policy and dragging in some WS dependencies wasn't it? So thats fixed now
> > and isn't any issue wi
On Wed, Apr 22, 2009 at 8:57 AM, Simon Laws wrote:
> snip...
>
> >
> > TUSCANY-2167 was caused by the base policy modules including WS binding
> > policy and dragging in some WS dependencies wasn't it? So thats fixed now
> > and isn't any issue with merging binding-ws-axis2-policy in the
> > bindi
> That sounds excellent, are you using 1.x or 2.x? There have been a lot of
> changes in 2.x for the endpoint code that should make that work better and
> easier. I had a peek in you sandbox area in svn and couldn't see this, could
> you commit it
Ok.
>
>>
>> Just a question: Tuscany and cloud co
On Tue, Apr 21, 2009 at 4:37 PM, ant elder wrote:
> Ok yes i agree with all that, it is the purpose of the SCAClient. And that
> reinforces the point that the impl should be separate from the Node. I know
> the current code has NodeImpl implementing SCAClient but that was just a
> easy way to demo
On Wed, Apr 22, 2009 at 9:01 AM, Luciano Resende wrote:
> On Wed, Apr 22, 2009 at 12:56 AM, ant elder wrote:
> >
> >
> > Ok and thats the same as what Luciano just mentioned in another post to
> this
> > thread. So...if we had a way to enable/disable support for either
> namespace
> > independent
> these aren't pluggable modules as the -runtime module directly news up
> classes from the -policy module so i can't see any reasons for keeping the
> code in a separate module now.
>
> ...ant
>
They should be pluggable and if there are things there that are
explicitly created by the runtime t
Hey Giorgio
Good to hear from you.
snip...
> Needs further investigations on how to deploy tuscany in a cloud.
>
It certainly does;-)
Simon
On Tue, Apr 21, 2009 at 10:56 PM, Luciano Resende wrote:
> This would be a great opportunity to showcase the current status of
> Tuscany. While Raymond and myself have already submitted abstracts for
> ApacheCon US 2009, we could probably re-arrange the contents and
> propose a 1/2 day track for t
On Wed, Apr 22, 2009 at 9:30 AM, Simon Laws wrote:
> > these aren't pluggable modules as the -runtime module directly news up
> > classes from the -policy module so i can't see any reasons for keeping
> the
> > code in a separate module now.
> >
> >...ant
> >
>
> They should be pluggable and i
>
> Removing binding-ws-axis2-policy from the build of binding-ws-axis build
> gives *lots* of compile errors as the runtime code directly uses classes in
> the policy module. We could change all those to be proper plugable extension
> points but it seems unnecessary to me as i can't image anyone e
Hi
after a long time away from Tuscany I'm in a position to start contributing
again. I'm planning to get involved in testing SCA against the OASIS specs.
To that end I'm going to have a little play in my sandbox with svn:externals
and whatever other tricks I can discover to investigate whether w
On Wed, Apr 22, 2009 at 10:54 AM, Simon Laws wrote:
> However if we, as a group, think having less modules in
> the build is more important then I'll concede the point. I would like
> to keep it separate for the moment while we tidy the binding though.
>
> Simon
>
There is an alternative, perhaps
On Wed, Apr 22, 2009 at 11:05 AM, kelvin goodson wrote:
> Hi
>
> after a long time away from Tuscany I'm in a position to start contributing
> again. I'm planning to get involved in testing SCA against the OASIS specs.
> To that end I'm going to have a little play in my sandbox with svn:externals
On Wed, Apr 22, 2009 at 11:05 AM, kelvin goodson
wrote:
> Hi
>
> after a long time away from Tuscany I'm in a position to start contributing
> again. I'm planning to get involved in testing SCA against the OASIS specs.
> To that end I'm going to have a little play in my sandbox with svn:external
Tests can be viewed here
http://tools.oasis-open.org/version-control/svn/sca-assembly/TestCases
or extracted here
svn://tools.oasis-open.org/version-control/svn/sca-assembly/TestCases
Kelvin.
2009/4/22 Simon Laws
> On Wed, Apr 22, 2009 at 11:05 AM, kelvin goodson
> wrote:
> > Hi
> >
> > after
thanks ant .. it's good to be back :)
2009/4/22 ant elder
>
>
> On Wed, Apr 22, 2009 at 11:05 AM, kelvin goodson
> wrote:
>
>> Hi
>>
>> after a long time away from Tuscany I'm in a position to start
>> contributing again. I'm planning to get involved in testing SCA against the
>> OASIS specs.
Ah, I see, thanks for the link Kelvin.
Simon
[
https://issues.apache.org/jira/browse/TUSCANY-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-2930:
---
Assignee: Simon Laws
> Add wireFormat.jmsDefault for the JMS binding
>
Just wanted to note that it seems that an additional burden on the
runtime implementor to support this API is to recognize if the service
is described by .
If so the runtime has to establish this WSDL interface on the runtime
representation of the reference built for the proxy without having the
d
On Wed, Apr 22, 2009 at 2:42 PM, Scott Kurz wrote:
> Just wanted to note that it seems that an additional burden on the
> runtime implementor to support this API is to recognize if the service
> is described by .
>
> If so the runtime has to establish this WSDL interface on the runtime
> represen
ant elder wrote:
Stepping back, what' s the problem we are trying to solve here ? I
kind like the "Don' t fix what ain't broke" phrase [1]...
I think it is "broke" :) We could make the runtime simpler if we had
more consistent use of fewer more functional modules and had a common
u
On Wed, Apr 22, 2009 at 10:10 AM, ant elder wrote:
> would not be invokeable via SCAClient as the service isn't exposed with the
> SCA binding.
I'd also assume the service would need to be exposed over binding.sca.
Continuing my line of thought... if there is any variability in
wireFormat f
Please review and vote on releasing the alpha1 release of the Tuscany
Zip plugin module.
The zip plugin enables using a packaging of zip in a Maven project
pom.xml to create a zip format SCA contribution.
The tag for the release is:
https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/mave
snip...
> Presumably an SCAClient impl would only be expected to talk to an SCA domain
> with a similar implementation?
Y - binding-sca only works inside a domain.
> So the Tuscany SCAClient would use the
> Tuscany SCA binding to talk to a Tuscany domain, but you wouldn't be able to
> use the Tus
On Wed, Apr 22, 2009 at 4:10 PM, Simon Laws wrote:
> Currently we have this trick in our local client where a new $self$
> reference created. However It sounds ok to me to say that you can only
> talk to things with an SCA binding. If you want to talk to something
> without an sca binding then ad
+1 on Simon's view. IMO, policies should be optional as some composite
applications don't care about them at all or only need a subset. For
example, if I just want to expose a web service from a java component, why
do I have to take the whole WS-* stack.
I also agree that our binding-ws-* sto
Here are my two cents based on my understanding of the OASIS spec:
1) SCAClient.getService() is similar to connect an SCA service using a dummy
reference without any binding declarations. The OASIS spec says the binding
for the reference will be provided by the service binding in such cases.
T
On Wed, Apr 22, 2009 at 4:36 PM, Raymond Feng wrote:
> example, if I just want to expose a web service from a java component, why
> do I have to take the whole WS-* stack.
>
Thats absolutely correct and the really good reason for have things in
separate modules IMHO. Notice that its something f
+1 on Mike's proposal. Additionally, I prefer to leave assembly-xml and
policy-xml as is. My bottom line to keep the clean modularity without
over-engineering. Meanwhile, I really don't think merging functionally
decoupled modules into a fat one is going to reduce spaghetti as it just
hides the
Folks,
I ran a full build against Tuscany 2.0 after doing svn update earlier today - and then executed mvn
-Peclipse against the result.
The generated .classpath files for the Eclipse projects all contained this
entry:
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.
Hi,
I just tried and I got the correct .classpath files:
output="target/test-classes" including="**/*.java"/>
excluding="**/*.java"/>
excluding="**/*.java"/>
sourcepath="M2_REPO/junit/junit/4.5/junit-4.5-sources.jar"/>
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
Can you try
Reading through the maven-eclipse-plugin code, it tries to detect the JRE
setting from the workspace. How do you place the tuscany source code and
your Eclipse workspace?
Please try to run mvn -Peclipse -X against one module. Post the output here.
I might be able to figure out something.
Tha
I added the Bundle-RequiredExecutionEnvironment header to the OSGi MANIFE.MF
so that the bundles can be correctly resolved in the Eclipse PDE with JDK
1.5. Let me check if that causes the issue.
Thanks,
Raymond
--
From: "Mike Edwards"
Sent: Wedne
On Wed, Apr 22, 2009 at 10:41 AM, Raymond Feng wrote:
> Reading through the maven-eclipse-plugin code, it tries to detect the JRE
> setting from the workspace. How do you place the tuscany source code and
> your Eclipse workspace?
>
Maybe the eclipse is still setup to use 1.5 JRE ? Check in
prefe
On Wed, Apr 22, 2009 at 11:54 AM, Raymond Feng wrote:
> Here are my two cents based on my understanding of the OASIS spec:
>
> 1) SCAClient.getService() is similar to connect an SCA service using a dummy
> reference without any binding declarations. The OASIS spec says the binding
> for the refere
Extensibility of Contribution and other model objects
-
Key: TUSCANY-2983
URL: https://issues.apache.org/jira/browse/TUSCANY-2983
Project: Tuscany
Issue Type: Bug
Components: Java
Ram,
Thanks for the updated summary.
I have a couple of questions, if you don't mind.
First, this is probably an obvious question, but by the "SCA
resolution mechanism" you mean:
1. first look in the current contribution
and if not found
2. then look for SCA contribution import/exports.
2892 If a reference does not have a binding, then the binding used can be
any of the bindings
2893 specified by the service provider, as long as the intents attached to
the reference and
2894 the service are all honoured.
--
From: "Scott Kurz"
Se
[
https://issues.apache.org/jira/browse/TUSCANY-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701679#action_12701679
]
Luciano Resende commented on TUSCANY-2866:
--
A workaround would be to install dir
The latest OASIS SCA Assembly Spec has the following:
3509 When a contribution contains a reference to an artifact from a
namespace that is declared in an import
3510 statement of the contribution, if the SCA artifact resolution mechanism
is used to resolve the artifact, the
3511 SCA runtime M
[
https://issues.apache.org/jira/browse/TUSCANY-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng reassigned TUSCANY-2983:
-
Assignee: Raymond Feng
> Extensibility of Contribution and other model objects
> --
[
https://issues.apache.org/jira/browse/TUSCANY-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-2983.
---
Resolution: Fixed
A fix is checked into 1.x branch under r767683.
> Extensibility of Contr
[
https://issues.apache.org/jira/browse/TUSCANY-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701784#action_12701784
]
Scott Kurz commented on TUSCANY-2966:
-
Just noticed there is a reset() on BytesMessag
On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng wrote:
> +1 on Mike's proposal.
Wonderful!
> over-engineering. Meanwhile, I really don't think merging functionally
> decoupled modules into a fat one is going to reduce spaghetti as it just
> hides the spaghetti. I would rather get all the dependenc
66 matches
Mail list logo
