Hi all,
Currently I cann't download the nightly kit of tuscany, the lastest one is 1.0
m2. But after 1.0 m2, lots of new features go into tuscany, so how about build
nightly kit and publish it for us to download to try with the lastest api and
features.
Thanks very much
Freeman
The code to be patched is in the cts part of the repository... so you
will also need to do a svn co
https://svn.apache.org/repos/asf/incubator/tuscany/java/cts/
(incidently I've found https seems to make for a more reliable sync in
eclipse http seems to often result in a 200 message)
On
I've probably missed something in the mailing list here. Since profiles
appeared in the top level pom the way I have been ensuring a change in SDO
doesn't break modules that have dependencies on SDO is to run a mvn -Pall.
I've done a bit of mailing list searching to find posts related to how
Hi Raymond,
I have done the following: -
- Created a JavaBeansDataBinding with basetype as java.lang.Object and have
included a DOMNode2JavaBean transformer into this binding. This tranformer
has the xml to javabean transformation that I have done.
- Extended the AbstractPropertyProcessor's
Scenario - SDO users have XSDs that would reference types defined in
sdoModel.xsd. It's inconvenient for the users to include the sdoModel.xsd in
their apps. They should be able to register their types in XSD with SDO runtime
since sdoModel.xsd is SDO's built-in model.
To satisfy the scenario
Hi.
Wondering what the schedule might be for commiting tuscany-1048 and 1081 ?
Brian Murray has been making some fixes to his test cases here in our ant
environement. We would like to work directly within maven and CTS but
simply put developing using/creating patches is a little cumbersome.
I
Can someone tell me if there is any samples or other information available
for using the JMS binding? Is the JMS binding functional at this point.
Thanks
Hi Robbie,
I'm working with Geoff to get those two applied... once they are we
will have the peer project (1081 is the peer project structure - at
least an initial one)... when applied it runs 328 (or something like
that) tests most of them pass :)
Hopefully more news by COB...
Cheers,
Dan
The JMS binding and sample can be found here :
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/extensions/jms/
As for current status, I think Ant has been more involved with that binding
and can probably give you more info.
On 1/30/07, Lou Amodeo [EMAIL PROTECTED] wrote:
Can
Yes, your CLA should be fine...
One of the first things that we will need on DAS to easily accommodate new
implementations would be to refactor the DAS Interfaces to it's own project
(e.g DAS API) and have the current DAS RDB having that as a dependency, and
then DAS LDAP would also use DAS API
I added this to FAQ (
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+-+FAQ)
Please update the link if additional info needs to be added.
On 1/29/07, Rick [EMAIL PROTECTED] wrote:
Ok, I had a momentary mental block that 0.1-pre-spec-SNAPSHOT is a ...
SNAPSHOT.
So the
[
https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Winn updated TUSCANY-1048:
Attachment: TUSCANY-1048-gmw.patch
I've re-worked the patch to add svn properties and correct
Adriano,
getUserData is not an alternative to getInteger (and similar).
As best I can tell, it was added to allow people to add some user specific
data to a data object. The data is supplied (in setUserData) as a void* so
it really can be anything. This option exists for all data objects,
XSDHelper#define
2-1. loads XSD as well as imported/included ones (as XSD model)
2-2. converts all XSDs to SDO Types (as SDO model)
sdoModel.xsd is converted/generated to SDO Types already.
It's possible not to repeat 2-1 and 2-2 when sdoModel.xsd is imported by
user XSD, therefore sdoModel.xsd
On 1/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
[snip]
Simon Nash wrote:
A repackaging into a kernel and language extensions as suggested by
Pete, Ignacio, and Jeremy seems like a good direction. We'll still
have to find a name for the (native, C++, scripting, ???) kernel,
I notice in implementing the PHP extension (yes - believe it or not I'm
nearly ready to make a patch for the next version ;-) that, given the way
that I have implemented the PHP extension there is insufficient information
available in the SCA runtime in order to do correct type conversions when
[
https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Murphy updated TUSCANY-1048:
Attachment: TUSCANY-1048-dm-20073001.patch
Sorry Geoff, didn't spot that one of the earlier
Hi, Venkat.
Please see my comments inline.
Thanks,
Raymond
- Original Message -
From: Venkata Krishnan [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 30, 2007 4:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
Hi Raymond,
On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
Jeremy,
thanks for your reply. A key time when this has become an issue
for me is
when applying patches. My general process has been to ensure I have a
complete clean svn extraction, build it to see if there are any
current
issues in
OK - Cool.
I'll checkout the DAS project and have a go
at the refactoring.
Then I'll read some of the DAS example doco (I think
there is some) and try to come up with similar
examples for LDAP that can be used as a guide
to starting the DAS implentation.
I'll do it Cookbook style like:
Sure, let me know if you have questions.
On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote:
OK - Cool.
I'll checkout the DAS project and have a go
at the refactoring.
Then I'll read some of the DAS example doco (I think
there is some) and try to come up with similar
examples for LDAP that can be
Should I be grabbing das-java-M2?
--- Luciano Resende [EMAIL PROTECTED] wrote:
Yes, your CLA should be fine...
One of the first things that we will need on DAS to
easily accommodate new
implementations would be to refactor the DAS
Interfaces to it's own project
(e.g DAS API) and have
Trunk DAS is pretty stable, unless you find any problems with it, I'd
recommend staying with trunk.
On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote:
Should I be grabbing das-java-M2?
--- Luciano Resende [EMAIL PROTECTED] wrote:
Yes, your CLA should be fine...
One of the first things that
OK - I think this is the trunk:
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb
And I think these are the interfaces:
-rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java
-rw-r--r-- 1 ole ole 3914 Dec 4 14:40
ConfigHelper.java
-rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java
On Jan 30, 2007, at 11:40 AM, Raymond Feng wrote:
Yes. The JAR is a packaging format understood by a
ContributionService in the domain. Based on the media type
(application/zip or application/x.tuscany.jar) this is processed
by the appropriate ContributionProcessor implementation and the
Hi, Jeremy.
Thank you for the explanation.
One more thing to clarify:
Assuming I have a folder structure on the file system to host my
contribution:
/tuscany/apps/MyApp/
/tuscany/apps/MyApp/META-INF/sca/default.scdl
/tuscany/apps/MyApp/xsd/a.xsd
Hi,
For the sake of similicity can we assume that allocation of components to
runtimes are explicitly specified in the SCDL, when it is made available to
the assembly service? Then the assembly service can matreilize the physical
component model for individual target slave runtimes, serialize
Yes, this would be the first step and you are on the right track, if we
identify others, we could continue moving them gradatively...
Another think to have in mind, and I don't think I have an answer right now,
is around the config model, and where is the best place for it : API
project, a
On Jan 30, 2007, at 1:32 PM, Raymond Feng wrote:
Hi, Jeremy.
Thank you for the explanation.
One more thing to clarify:
Assuming I have a folder structure on the file system to host my
contribution:
/tuscany/apps/MyApp/
/tuscany/apps/MyApp/META-INF/sca/default.scdl
Great - Thanks - Good to know I'm on the right track.
Just taking a quick shot:
I think there should be a
org.apache.tuscany.das.config.model.rdb
+
some other implementation packages
in it's own project.
And the same for ldap. So:
org.apache.tuscany.das.config.model.ldap
+ implementation
Shorter NameSpace prefix to speed up XML processing and reduce communication
bandwidth
--
Key: TUSCANY-1083
URL: https://issues.apache.org/jira/browse/TUSCANY-1083
[
https://issues.apache.org/jira/browse/TUSCANY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang ZHONG updated TUSCANY-1083:
Attachment: prefix.xsd
ShortPrefix
All SDO build tests have passed with the
[
https://issues.apache.org/jira/browse/TUSCANY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468844
]
Yang ZHONG commented on TUSCANY-928:
It has been over 1.5 months. Thanks to Fuhwei and Kelvin for the feedback.
33 matches
Mail list logo
