Hi,
I agree to your views on intents and I also like the proposal you are making
with respect to making use of 'appliesTo'. Sounds like a clean way out.
The only issue standing in the way is of how we get hold of the SCDL over
which the xpath in 'appliesTo' can be applied. I'd like to use our
[
https://issues.apache.org/jira/browse/TUSCANY-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564680#action_12564680
]
Venkatakrishnan commented on TUSCANY-2016:
--
I am able to replicate this locally
On Jan 31, 2008 7:45 PM, Luciano Resende [EMAIL PROTECTED] wrote:
I was trying to find a JMS web app sample, do we have any ?
No. I had considered making one but have left all webapp things for now till
the discussions around what runtimes we support get resolved.
Also, in the context of a
On Jan 31, 2008 1:41 PM, ant elder [EMAIL PROTECTED] wrote:
I'd like to get some discussion going on what we want to do for graduating
to an Apache TLP.
The attempt back in November raised issues about diversity and since then
it
feels like we've just been waiting around hoping diversity
[
https://issues.apache.org/jira/browse/TUSCANY-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-1999:
---
Assignee: Simon Laws
ConversationAttributes and expiry doesn't work with Stateless
On Feb 1, 2008 12:27 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Folks,
I think that there may be a problem with building the SCA code from trunk.
I did an svn update on my system yesterday and then did mvn clean.
This FAILED, complaining about not being able to find jars relating to
Saxon
snip..
On Jan 31, 2008 8:44 PM, Lou Amodeo [EMAIL PROTECTED] wrote:
Hi Simon, This timing of this is more of a service side requirement than
a
client one. Due to some dependencies I have I need to have access to a
physical WSDL file at service provider startup.
OK, I see. Where would you
Folks,
I think that there may be a problem with building the SCA code from trunk.
I did an svn update on my system yesterday and then did mvn clean.
This FAILED, complaining about not being able to find jars relating to
Saxon 9.0.0.2. I then tried simply mvn, which also failed, this time
That sounds ok to me.
...ant
On Feb 1, 2008 3:10 PM, Simon Laws [EMAIL PROTECTED] wrote:
I'm looking at copying the 1.1 release artifacts up onto the new
distribution infrastructure at
www.apache.org/dist/incubator/
We need to make a decision about how this will be structured. As a
Some more comments inline
Lets see if I can articulate this a little better. My thinking is that
taget= represents a binding independent way to resolve an endpoint. It
doesnt necessarily specify the contents of the effective URI that is
used to address an endpoint.
+1
In the
Simon,
Simon Laws wrote:
Hi Mike
Where did mvn clean fail for you? We have seen problems with this in the
recent past around the java/wsdl tooling but I thought that had been fixed.
Simon
It failed in contribution-classloader, where one of the classloading
tests got an exception trying to
On Jan 31, 2008 5:04 PM, Lou Amodeo [EMAIL PROTECTED] wrote:
Hi, I have a question about the implementation of the wsdlless
deployment
function.
The issues I see are occurring in a couple of places within the
life-cycle.
Namely, deployment, binding start, and service definition. It occurs
I'm looking at copying the 1.1 release artifacts up onto the new
distribution infrastructure at
www.apache.org/dist/incubator/
We need to make a decision about how this will be structured. As a default I
assume we stick pretty much with what we have already (see
On Jan 31, 2008 5:04 PM, Lou Amodeo [EMAIL PROTECTED] wrote:
Hi, I have a question about the implementation of the wsdlless
deployment
function.
The issues I see are occurring in a couple of places within the
life-cycle.
Namely, deployment, binding start, and service definition. It occurs
+1
Simon Laws wrote:
I'm looking at copying the 1.1 release artifacts up onto the new
distribution infrastructure at
www.apache.org/dist/incubator/
We need to make a decision about how this will be structured. As a default I
assume we stick pretty much with what we have already (see
Create JMS webapp sample
Key: TUSCANY-2026
URL: https://issues.apache.org/jira/browse/TUSCANY-2026
Project: Tuscany
Issue Type: Improvement
Components: Java SCA JMS Binding Extension
Affects Versions:
Hi
The Tuscany project is now ready to distribute its Java SCA Release
1.1-incubating. Following up from Robert's recent post to the Tuscany dev
list [1] I am posting here before proceeding to copy the artifacts up to
www.apache.org/dist/incubator.
The proposal it to use a similar release
Sounds ok.
On Feb 1, 2008 8:09 AM, Mike Edwards [EMAIL PROTECTED] wrote:
+1
Simon Laws wrote:
I'm looking at copying the 1.1 release artifacts up onto the new
distribution infrastructure at
www.apache.org/dist/incubator/
We need to make a decision about how this will be
Hi,
(Sorry for the long text, I make it availabe on our WIKI too:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Automation+of+itests+in+web+applications).
In our WAR packaging scheme, we package SCA artifacts with Tuscany runtime
jars in a WAR so that it can be deployed to a web
+1 from me.
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Friday, February 01, 2008 7:10 AM
Subject: Distribution structure
I'm looking at copying the 1.1 release artifacts up onto the new
distribution
A quick update: I managed to get the automation working with Geronimo 2.0.2
too using the geronimo-maven-plugin. The new pom.xml has been updated at the
wiki page.
Thanks,
Raymond
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday,
Mike Edwards wrote:
[snip]
Jean-Sebastien Delfino wrote:
I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need
I agree with the objectives. The second of the two is more important
from my perspective.
I was thinking about
22 matches
Mail list logo
