Scott Kurz wrote:
When you wrote:
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
How were you thinking a particular XSD
Venkata Krishnan wrote:
From the history of this mail, I suspect that you haven't got my post in
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am
certainly eager to fix this. Let me know your thoughts on what I have
asked there. Thanks.
Sorry, it's weird, I
Venkata Krishnan wrote:
It would also be good to have some sort of 'ping' function that could be
used to check if a service is receptive to requests. Infact I wonder if the
Workspace Admin should also be able to test this sort of a ping per
binding. Is this something that can go into the
Simon Nash wrote:
Jean-Sebastien Delfino wrote:
[snip]
- route the JIRA traffic out of the dev list as suggested by Matthieu
I understand that this traffic can get a bit overwhelming at times, but
I'd like to make the case that it does have value for new developers
(though not for users).
On 05/02/2008, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Nash wrote:
Jean-Sebastien Delfino wrote:
[snip]
- route the JIRA traffic out of the dev list as suggested by Matthieu
I understand that this traffic can get a bit overwhelming at times, but
I'd like to make the case
On Feb 5, 2008 2:38 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
From the history of this mail, I suspect that you haven't got my post in
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html.
I am
certainly eager to fix this. Let me know
[
https://issues.apache.org/jira/browse/TUSCANY-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1514:
Component/s: (was: Java DAS RDB)
Java SDO Implementation
This JIRA
On Feb 5, 2008 10:09 AM, sebb [EMAIL PROTECTED] wrote:
snip
However few (if any) mail archives seem to offer such facilies and so
can be difficult to read if there are lots of JIRA messages mixed in
with the rest.
Thats a good point. Up till now I've thought its better to have the JIRA
ant elder wrote:
Could you say a bit more about why it needs to be a runtime module not just
somewhere like maven-web-junit, and what the issue is in point 3? (as you
can guess my preference is for this to not be in the core runtime :))
...ant
I agree that we should keep this out of the
Jean-Sebastien Delfino wrote:
Simon Nash wrote:
Jean-Sebastien Delfino wrote:
[snip]
- route the JIRA traffic out of the dev list as suggested by Matthieu
I understand that this traffic can get a bit overwhelming at times, but
I'd like to make the case that it does have value for new
Typically these discussions have multiple aspects to it and we end up
bringing perspectives to each aspect. If there is such a topic then I'd
think the WIKI is a good place. There could be one description of the
problem and comments by the community at various points. So at any time one
knows
Hi,
I observe are some intents named 'soap', 'soap11', 'soap12'. I'd like to
know if these are supposed to be intents classified as 'mayProvide' for
binding.ws.
Just to refresh, 'mayProvide' intents are those that can be specified for a
binding / implementation and that needs no matching
OK, just wanted to make sure I hadn't missed a discussion on how to do
this with dynamic SDOs.
You know, one issue I noticed when looking at this with static SDOs is
the way that SDO makes it hard for you
to programmatically go from static SDO to XSD. Looking at the SDO
source I think it was
Hi,
The output shows that the
org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase
has errors, have a look there.
If you only want to get the build done don't run the tests -Dmaven.test.skip
= true
R
- Original Message -
From: Matthew Peters
I am seeing the following error during a Tuscany build. This is a fresh
checkout from Tuscany svn. Can anyone tell me what the cause might be?
Matthew
C:\Documents and Settings\Administrator\sca\modules\contribution-implmvn
[INFO] Scanning for projects...
[INFO]
On Feb 3, 2008 5:01 PM, Mike Edwards [EMAIL PROTECTED] wrote:
Folks,
It is important to remember that when an interface is specified EITHER
as some non-WSDL interface type (eg Java interface) OR where it is
specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
service may
Hi Scott,
There was a discussion around this with the SDO folks and their view point
was that, having generated the static SDO from an XSD, why would one want to
go and generate the XSD again. Ideally the original XSD should be used.
Its been a while since I've been thro this, but I do remember
[
https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David T. Adcox updated TUSCANY-2014:
Attachment: (was: Test2014.java)
XMLDocument object's rootElement member not
[
https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David T. Adcox updated TUSCANY-2014:
Attachment: Test2014.java
A bit cleaner sample of the problem.
XMLDocument object's
Scott Kurz wrote:
OK, just wanted to make sure I hadn't missed a discussion on how to do
this with dynamic SDOs.
You know, one issue I noticed when looking at this with static SDOs is
the way that SDO makes it hard for you
to programmatically go from static SDO to XSD. Looking at the SDO
Richard Featherstone wrote:
Hi,
The output shows that the
org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase
has errors, have a look there.
If you only want to get the build done don't run the tests
-Dmaven.test.skip = true
R
- Original Message
.. meanwhile... I have started to make some changes locally to see if what I
am proposing about pulling the builder into a module and using the wirters
to write relevant fragments of SCDL, is feasible...
- Venkat
On Feb 5, 2008 3:52 PM, Venkata Krishnan [EMAIL PROTECTED] wrote:
On Feb 5, 2008
Folks,
Jean-Sebastien Delfino wrote:
Richard Featherstone wrote:
Hi,
The output shows that the
org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase
has errors, have a look there.
If you only want to get the build done don't run the tests
Thanks all,
When I looked closer and distinguished which was the significant error
message it was indeed to do with the blank in c:\document and settings.
I did indeed move to a directory with no spaces and that error went away.
Thanks for the replies.
Matthew Peters
Mike Edwards [EMAIL
This should be fixed in revision #618718
On Feb 5, 2008 9:28 AM, Matthew Peters [EMAIL PROTECTED] wrote:
Thanks all,
When I looked closer and distinguished which was the significant error
message it was indeed to do with the blank in c:\document and settings.
I did indeed move to a directory
The bottom of the issue comes from
http://jira.codehaus.org/browse/SUREFIRE-123. Your fix is indeed a
workaround :-).
Thanks,
Raymond
- Original Message -
From: Luciano Resende [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, February 05, 2008 9:45 AM
Subject: Re:
The Apache Tuscany team are delighted to announce the 1.1 release of the
Java SCA project.
Apache Tuscany provides a runtime environment based on the Service Component
Architecture (SCA). SCA is a set of specifications aimed at simplifying SOA
application development. These specifications are
[
https://issues.apache.org/jira/browse/TUSCANY-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565952#action_12565952
]
Simon Laws commented on TUSCANY-1999:
-
Hi
I've just been look at the patch and have
Venkata Krishnan wrote:
Typically these discussions have multiple aspects to it and we end up
bringing perspectives to each aspect. If there is such a topic then I'd
think the WIKI is a good place. There could be one description of the
problem and comments by the community at various points.
Jean-Sebastien Delfino wrote:
Reading the composite file / building its model / re-writing it to
finally apply the xpath sounds very complicated.
As an application developer I'll write the appliesTo xpath to match what
I see in a composite XML file. Why can't we simply run the xpath on that
Let me try to propose the following fix:
1) Add new interface such as PassByValueProvider (please help me with a
better name) to the SPI.
public interface PassByValueProvider {
/**
* Indicate if the provider will enforce the pass-by-value semantics
*/
boolean
Raymond Feng wrote:
Let me try to propose the following fix:
1) Add new interface such as PassByValueProvider (please help me with a
better name) to the SPI.
public interface PassByValueProvider {
/**
* Indicate if the provider will enforce the pass-by-value semantics
*/
We now have the iTest pom handling all the configuration for running
the execution of the iTests in a web-container. At the moment, we have
enabled selected iTests (services and componentType) and you can
execute the tests in Geronimo and/or Jetty. Adding new iTests should
be as simple as adding
Ok, let me go try this and post back. I'd like to vary this a bit - but let
me have some code to talk about.
Meanwhile, I did get ahead with my proposal but did not quite like the way I
had to pass the CompositeProcessor all the way from the Runtime down to the
builders. It seemed very hacky.
34 matches
Mail list logo
