[
https://issues.apache.org/jira/browse/TUSCANY-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482060
]
Kelvin Goodson commented on TUSCANY-1171:
-
Capturing some status ---
Attempting to address the issues at
[
https://issues.apache.org/jira/browse/TUSCANY-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482061
]
Kelvin Goodson commented on TUSCANY-1171:
-
Above link should have been
XSDChoiceTest
-
Key: TUSCANY-1183
URL: https://issues.apache.org/jira/browse/TUSCANY-1183
Project: Tuscany
Issue Type: Test
Components: Java SDO Community Test Suite
Reporter: Andy Grove
The attached zip
[
https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Grove updated TUSCANY-1183:
Attachment: XSDChoiceTest-1183.zip
XSDChoiceTest
-
Key:
Hi Ole,
I am no EMF expert. Can you help me understand what this Ecore2Ecore Model and
Processor is used for? Thanks.
Sincerely,
Fuhwei Lwo
Ole Ersoy [EMAIL PROTECTED] wrote: Hi,
I've created an Ecore2Ecore Model and Processor.
I was wondering if this might find a home in Tuscany?
The
[
https://issues.apache.org/jira/browse/TUSCANY-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1172.
-
Resolution: Fixed
plugin LICENSE.txt file has spurious
Hi Ole,
it would be great to understand a bit more about the use case(s) for such
a tool. I haven't had occasion to use the EMF one.
Regards, Kelvin.
On 17/03/07, Ole Ersoy [EMAIL PROTECTED] wrote:
Hi,
I've created an Ecore2Ecore Model and Processor.
I was wondering if this might find a
On 3/16/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
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
Hi Ole,
Sounds interesting, but unless you want to reimplement the idea as an
SDOType2SDOType model (independent of EMF), Tuscany is not the right home.
Tuscany is an SDO implementation, which currently happens to have a
dependency on EMF. It uses Ecore in restrictred and specialized ways, and
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
[
https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482093
]
Andy Grove commented on TUSCANY-1178:
-
I've spent some time looking at the spec and I think it would be useful
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
[
https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482125
]
Frank Budinsky commented on TUSCANY-1178:
-
Hi Andy,
I agree with your 2 conclusions.
Frank.
Hi, Ant.
I already merged the ElementInfo/TypeInfo/XMLType in the spi/model folder a
few days ago. You probably just have to re-import the types if any classes
still reference the old package name.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To:
[
https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482135
]
Andy Grove commented on TUSCANY-1178:
-
Thanks, Frank. I've filed the following bug against the specification:
Extend depth and breath of generated databinding tests
--
Key: TUSCANY-1184
URL: https://issues.apache.org/jira/browse/TUSCANY-1184
Project: Tuscany
Issue Type: Improvement
Jean-Sebastien Delfino wrote:
Jim Marino wrote:
If that helps, I have been able to use the Jetty service in the
integration branch as a ServletHost to expose Web Services with the
Axis2 binding. To see this working you can take a look at the
sca/extensions/axis2/samples/helloworld-ws
Isn't a package named idl more appropriate?
...ant
On 3/19/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Ant.
I already merged the ElementInfo/TypeInfo/XMLType in the spi/model folder
a
few days ago. You probably just have to re-import the types if any classes
still reference the old
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
The code in trunk was using model as the package name. When I merged the
changes, I decided to leave them as is and defer the refactoring to a later
point.
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, March 19,
I've done a checkout and when I opened the
C:\Adriano\Faculdade\Tuscany\Tuscany\CPP\DAS\VSExpress\tuscany_das\das_runtime\das_runtime.sln
solution, it has only the das_runtime project and the das_lite project
doesn't apper :s, did you remove it from the solution or I forgot to include
the file on
Ok so how about I move all the idl related classes from model to
org.apache.spi.idl? I was thinking about that anyway as part of the IDL
refactoring that was discussed a while back.
...ant
On 3/19/07, Raymond Feng [EMAIL PROTECTED] wrote:
The code in trunk was using model as the package
Are you talking about das_lite here ?
https://svn.apache.org/repos/asf/incubator/tuscany/cpp/das/VSExpress/tuscany_das/
Does it still look like I missed something ? Let me know...
--
Luciano Resende
http://people.apache.org/~lresende
On 3/19/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I've
On Mar 19, 2007, at 11:04 AM, Raymond Feng wrote:
The code in trunk was using model as the package name. When I
merged the changes, I decided to leave them as is and defer the
refactoring to a later point.
FYI, The reason why it uses that is there are references to the class
from
On Mar 19, 2007, at 11:11 AM, ant elder wrote:
Ok so how about I move all the idl related classes from model to
org.apache.spi.idl? I was thinking about that anyway as part of the
IDL
refactoring that was discussed a while back.
+1 as long as you don't introduce circular references.
Hi Fuhwei,
Sure. The ecore2ecore model maps one ecore model to another.
Here's a real world scenario that I'm using it for that will hopefully
make it clearer.
1) I generate an ecore model from the maven pom v400 xml schema.
2) I map this model using ecore2ecore to another model I created
Hi Frank,
OK - Sounds good - I'll study up on my SDO concepts a little more - and
look at how we can make it work.
I did donate it to EMF on bugzilla already as well
https://bugs.eclipse.org/bugs/show_bug.cgi?id=173226
Cheers,
- Ole
Frank Budinsky wrote:
Hi Ole,
Sounds interesting, but
Hmm, this seems like an example of where legal red tape may be getting
in the way of the spirit of reuse. 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
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:
Jeremy Boynes [EMAIL PROTECTED] wrote on 03/19/2007 06:14:58 PM:
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
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
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=revrev=520115
Log:
Avoid problems with other scopes
Modified:
Has there already been discussion about adding a HelperContext parm for
methods which take URI and name as input?
It seems necessary to me. For example, if you've created a Type with
helperContext1.getXSDHelper().define() or
helperContext1.getTypeHelper().define(),
then
Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our SCA
runtime kernel. I posted two diagrams on our Wiki at
http://cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our+runtime
to help start the discussion.
One of the ideas is to allow for
On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our
SCA runtime kernel. I posted two diagrams on our Wiki at http://
cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
+runtime
35 matches
Mail list logo
