date:20070319

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 contains a sample XSD test from Rogue Wave's test suite.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1183) XSDChoiceTest


 [ 
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: 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
 Attachments: XSDChoiceTest-1183.zip


 The attached zip contains a sample XSD test from Rogue Wave's test suite.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ecore2Ecore Model and Processor Donation

2007-03-19 Thread Fuhwei Lwo

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 model maps one ecore model to another. 
It's different from the Eclipse implementation (Thought it was tricky to 
use),
but I tried to reuse the naming of objects as much as possible.

The processor will take a source model instance and create the 
corresponding target model.

Here is the URL:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all/ecore2ecore.model.parent

Cheers,
- Ole



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1172) plugin LICENSE.txt file has spurious

2007-03-19 Thread Kelvin Goodson (JIRA)


 [ 
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
 

 Key: TUSCANY-1172
 URL: https://issues.apache.org/jira/browse/TUSCANY-1172
 Project: Tuscany
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: Java-SDO-M3
 Environment: Java 1.4.2
Reporter: Paul Golick
Priority: Minor
 Fix For: Java-SDO-M3

 Attachments: 1172.patch


 The java\sdo\plugin\src\main\resources\META-INF\LICENSE.txt file has 
 unnecessary references to Mozilla Public License 1.1 (MPL) and to Common 
 Development and Distribution License 1.0 (CDDL).  These should be removed 
 since these references may unnecessarily deter use of this component by users 
 that avoid code licensed with MPL or CDDL.  This LICENSE.txt file is also not 
 consistent with the NOTICE.txt file of the same directory.
 A patch removing these unnecessary license references will be submitted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ecore2Ecore Model and Processor Donation

2007-03-19 Thread kelvin goodson


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 home in Tuscany?

The model maps one ecore model to another.
It's different from the Eclipse implementation (Thought it was tricky to
use),
but I tried to reuse the naming of objects as much as possible.

The processor will take a source model instance and create the
corresponding target model.

Here is the URL:


https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all/ecore2ecore.model.parent

Cheers,
- Ole



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn move, was: Databinding itest reorg proposal

2007-03-19 Thread Simon Laws


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 taking the time to explain.

If you're new to Subversion I highly recommend reading this:
   http://svnbook.red-bean.com/

There's an Appendix on Subversion for CVS Users :-)
--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cool. Thanks Jeremy

Re: Ecore2Ecore Model and Processor Donation

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 
the goal, over time, is to decrease the dependence on EMF. An EMF-specific 
(Ecore) mapping model would not be appropriate at Tuscany. 

Have you considered contributing it to the EMFT (EMF Technology) project 
at Eclipse? EMFT is the intended home for new EMF-based technologies.

Frank

Ole Ersoy [EMAIL PROTECTED] wrote on 03/17/2007 07:15:38 PM:

 Hi,
 
 I've created an Ecore2Ecore Model and Processor.
 
 I was wondering if this might find a home in Tuscany?
 
 The model maps one ecore model to another. 
 It's different from the Eclipse implementation (Thought it was tricky to 

 use),
 but I tried to reuse the naming of objects as much as possible.
 
 The processor will take a source model instance and create the 
 corresponding target model.
 
 Here is the URL:
 
 https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.
 factory.all/ecore2ecore.model.parent
 
 Cheers,
 - Ole
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SDO Java M3 Release Candidate RC1

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 using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We 
asked the EMF team if they could switch this to the IOC pattern, so we 
could inject our SDO specific metadata factories. They said they would, 
but can't before EMF version 2.3 which is Java 5 dependent. Since we won't 
(can't) move to EMF 2.3, our interim solution was to create subclasses in 
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which 
override the methods that create metadata. The subclasses contain copies 
of the base method, only using a factory instance variable instead of the 
singleton. For example:

class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;

void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable = 
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}

... etc.

}

So, the question is, what kind of license do we need in these two Tuscany 
classes?

1. Apache.
2. Apache + Eclipse
3. Other?

Currently, I think we just have #1. If anyone can provide guidance on 
this, it would be much appreciated.

Thanks,
Frank.


Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:

 Those are the ones. You said before that you thought this might be 
 generated but that you were sure Frank would confirm. He has not done 
 so.
 
 What seems odd to me is that if this was generated then I would have 
 expected consistent text to have been produced by the generator. 
 Instead we have things like:
 
 + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks 
 Exp $
 
 and
 
 + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
 
 which correlate directly to headers found in files in the Eclipse 
 repo. This makes the provenance of the code uncertain which is why we 
 need clarification of what happened.
 
 --
 Jeremy
 
 On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
 
  I think you are freferring to commit r513560 .* *There was no code 
  copied
  from eclipse.  The EMF generator puts an eclipse header in to 
  generated code
  by default. That code was simply the result of using that generator 
  against
  our own schemas.
 
  Regards, Kelvin.
 
 
 
 
  On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
 
  Not to be a party-pooper, but what was the outcome with the code
  copied from Eclipse?
  --
  Jeremy
 
  On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
 
   I have posted an SDO Java M3 release candidate here:
   http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://
   people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/ 
  ~robbinspg/M3-RC1/
  
  
   Please take a look at this and try it out, so that I can pick up
   any errors
   quickly and move towards a vote on a proper release in the short 
  term.
  
   Thanks, Kelvin.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created

[
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 to look
an example in more detail.

Lets look at the following example (note: in the test case none of the above
types are used for nillable elements so this example is not exactly the same as
the test case).

xsd:element name=smallOddNumber nillable=true minOccurs=0
type=dtfs:smallOddNumber/

The spec says that for the element smallOddNumber we need to create an SDO
Property called smallOddNumber with nullable=true. No problem so far.

The spec then says that If the type of the element has Simple Content without
attributes, a Java Type with an Object instance class is assigned. For example,
IntObject instead of Int.

My interpretation of this is that the SDO Property smallOddNumber should have
an SDO Type commonj.sdo/java#IntObject assigned rather than
commonj.sdo/Int. This implies that the property would never be assigned the
type smallOddNumber, which doesn't seem correct.

I think there are two conclusions from this:

1. The CTS should not expect the extra Object types to be created - this isn't
required by the specification (but shouldn't be disallowed either)
2. This part of the specification needs reviewing / amending. Do you agree? If
so, we should file a bug against the specification too.

DynamicTypesFromSchemaTestCase expecting *Object types to be created

Key: TUSCANY-1178
URL: https://issues.apache.org/jira/browse/TUSCANY-1178
Project: Tuscany
Issue Type: Bug
Components: Java SDO Community Test Suite
Reporter: Andy Grove

DynamicTypesFromSchemaTestCase expects the following types to be included in
the list returned by XSDHelper.define() but there are no types with these
names in the XSD (these types minus the Object suffix do exist though). Is
there something in the spec that says these extra Object types must be
created or is this Tuscany-specific implementation detail that should be
excluded from the CTS?
evenNumberOfOddOrEvenDigitsObject
monthObject
oddOrEvenDigitsObject
smallIntObject
smallOddNumberObject

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SDO Java M3 Release Candidate RC1

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 presume this is IBM code) relicense it under  
AL and contribute

  via the IP Clearance process
* Do an alternative implementation, best done by someone who has not  
seen the Eclipse code


--
Jeremy

On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:


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 using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they  
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since  
we won't
(can't) move to EMF 2.3, our interim solution was to create  
subclasses in

Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain  
copies
of the base method, only using a factory instance variable instead  
of the

singleton. For example:

class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;

void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}

... etc.

}

So, the question is, what kind of license do we need in these two  
Tuscany

classes?

1. Apache.
2. Apache + Eclipse
3. Other?

Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.

Thanks,
Frank.


Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:


Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.

What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:

+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $

and

+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $

which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.

--
Jeremy

On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:


I think you are freferring to commit r513560 .* *There was no code
copied
from eclipse.  The EMF generator puts an eclipse header in to
generated code
by default. That code was simply the result of using that generator
against
our own schemas.

Regards, Kelvin.




On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:


Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy

On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:


I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://
people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/

~robbinspg/M3-RC1/



Please take a look at this and try it out, so that I can pick up
any errors
quickly and move towards a vote on a proper release in the short

term.


Thanks, Kelvin.



--- 
--

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created

2007-03-19 Thread Frank Budinsky (JIRA)


[ 
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.


 DynamicTypesFromSchemaTestCase expecting *Object types to be created
 

 Key: TUSCANY-1178
 URL: https://issues.apache.org/jira/browse/TUSCANY-1178
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove

 DynamicTypesFromSchemaTestCase  expects the following types to be included in 
 the list returned by XSDHelper.define() but there are no types with these 
 names in the XSD (these types minus the Object suffix do exist though). Is 
 there something in the spec that says these extra Object types must be 
 created or is this Tuscany-specific implementation detail that should be 
 excluded from the CTS?
 evenNumberOfOddOrEvenDigitsObject
 monthObject
 oddOrEvenDigitsObject
 smallIntObject
 smallOddNumberObject

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread Raymond Feng


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: tuscany-commits@ws.apache.org
Sent: Monday, March 19, 2007 5:41 AM
Subject: svn commit: r519930 - in 
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: 
ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java




Author: antelder
Date: Mon Mar 19 05:40:59 2007
New Revision: 519930

URL: http://svn.apache.org/viewvc?view=revrev=519930
Log:
Copy IDL classes from integration brn to trunk to get idl WSDL building in 
trunk (probably only temp here till the IDL work is done)


Added:

incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java
 - copied unchanged from r519927, 
incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java
 - copied unchanged from r519926, 
incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java
 - copied unchanged from r519927, 
incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java
 - copied unchanged from r519927, 
incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created


[ 
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:

http://www.xcalia.com/support/browse/SDO-230


 DynamicTypesFromSchemaTestCase expecting *Object types to be created
 

 Key: TUSCANY-1178
 URL: https://issues.apache.org/jira/browse/TUSCANY-1178
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove

 DynamicTypesFromSchemaTestCase  expects the following types to be included in 
 the list returned by XSDHelper.define() but there are no types with these 
 names in the XSD (these types minus the Object suffix do exist though). Is 
 there something in the spec that says these extra Object types must be 
 created or is this Tuscany-specific implementation detail that should be 
 excluded from the CTS?
 evenNumberOfOddOrEvenDigitsObject
 monthObject
 oddOrEvenDigitsObject
 smallIntObject
 smallOddNumberObject

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1184) Extend depth and breath of generated databinding tests

2007-03-19 Thread Simon Laws (JIRA)

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
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-integration
 Environment: All supported
Reporter: Simon Laws
 Assigned To: Simon Laws
Priority: Minor


The tests as originally commited provided hard coded suport for a limited 
number of types in SDO and JAXB bindings. These hard coded tests have been 
augmented with a common project to store shared schema and a set of template 
files that can be used to generate the tests themselves. The work now is to 
fill out the set of types and combinations of bindings tested. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat service, was: http.jetty service

2007-03-19 Thread Jean-Sebastien Delfino


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 sample.


--Jean-Sebastien


Cool, do you want to pull up the Axis2 binding to have it work off 
the 2.0 alpha kernel release so we can get a WS stack integrated? I 
think it would be useful if we could release Axis around the time we 
release some of the other extensions, e.g. Spring, Groovy and JPA.


Jim



It looks like Ant is going to try to do it (see 
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED]) 
so in parallel I'm thinking about  experimenting a little with Tomcat. 
I'd like to see if we can integrate with Tomcat like what we've done 
with Jetty, and run services with WS bindings without having to 
package the whole app as a War.




I've made some progress with this. I'm creating a new Tomcat transport 
service module similar to the Jetty transport service under 
sca/services/transports/http.tomcat. It should be running later today, I 
need to do a little more testing with both Tomcat 5.5 and 6.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread ant elder


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 package name.

Thanks,
Raymond

- Original Message -
From: [EMAIL PROTECTED]
To: tuscany-commits@ws.apache.org
Sent: Monday, March 19, 2007 5:41 AM
Subject: svn commit: r519930 - in

/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl:
ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java


 Author: antelder
 Date: Mon Mar 19 05:40:59 2007
 New Revision: 519930

 URL: http://svn.apache.org/viewvc?view=revrev=519930
 Log:
 Copy IDL classes from integration brn to trunk to get idl WSDL building
in
 trunk (probably only temp here till the IDL work is done)

 Added:


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java
  - copied unchanged from r519926,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

target attach needs the source information

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 close, I'm  
also going to rename the methods to attachToSource and attachToTarget.


--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread Raymond Feng

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, 2007 10:46 AM
Subject: Re: svn commit: r519930 - in 
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: 
ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java




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 package name.

Thanks,
Raymond

- Original Message -
From: [EMAIL PROTECTED]
To: tuscany-commits@ws.apache.org
Sent: Monday, March 19, 2007 5:41 AM
Subject: svn commit: r519930 - in

/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl:
ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java


 Author: antelder
 Date: Mon Mar 19 05:40:59 2007
 New Revision: 519930

 URL: http://svn.apache.org/viewvc?view=revrev=519930
 Log:
 Copy IDL classes from integration brn to trunk to get idl WSDL building
in
 trunk (probably only temp here till the IDL work is done)

 Added:


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java
  - copied unchanged from r519926,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java


incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java
  - copied unchanged from r519927,

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: C++ DAS Lite versus C++ DAS, was Fwd: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite Command classes

2007-03-19 Thread Adriano Crestani


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 the patch? I think you should copy all the files I sent to you
into the repo.

Adriano Crestani

On 3/16/07, Luciano Resende [EMAIL PROTECTED] wrote:


I have just applied your patch. At some point, once we get things more
stable, we should decide witch way to go, and maybe promote the das_lite
to
just c++ das. For now this should be OK.

BTW, I liked Pete's comments : keep DASing ;-)

--
Luciano Resende
http://people.apache.org/~lresende

On 3/15/07, Adriano Crestani [EMAIL PROTECTED] wrote:

 I think you got the point when you said to remove the files from the
 project, I don't know how I hadn't thought about it. Because the main
 reason
 to create a new project in VS solution is to avoid the compilation
errors
 from those many classes that are not completed implemented.

 But also because I wanted to keep the previous implementation, for
 example,
 of the class ReadCommandImpl that was reimplemented in das_lite project.
 With diferent versions of classes we can define what is already
 implemented
 completely(das_lite project) and what remains to be
 implemented(das_runtime
 project).

 I think we could try another approach where we could move the classes
from
 the das_runtime to a trunk or something like and the classes that we are
 actually implementing from the das_lite(cpp/das/runtime/das_lite/src/)
 project to the das_runtime(cpp/das/runtime/core/src) project and
 continuing
 implementing from there.

 What do you think?

 Adriano Crestani





 On 3/15/07, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Hi Adriano
 
 I was looking into your patch, and realized you had created a new
  project
  located at (cpp/das/runtime/das_lite/src/) instead of continuing to
work
  on
  (cpp/das/runtime/core/src). I tought that from a previous quick
 discussion
 
  we had agreed that das_lite was more a initial simple scenario rather
 then
  a
  new project.
 
 I have couple questions :
 - Could you please elaborate what your plans are here ?
 - What's the main differences between C++ DAS and C++ DAS Lite
?
 - Is this new project a small subset of files that were
 duplicated
  from cpp/das/runtime/core/src ? If so, is there a way to have one
 project
  but only compile/use the subset of files required, maybe just not
adding
  them to the VS project ?
 
 I'll wait after clarification on this subject before I apply the
 patch.
 If anyone else have other thoughts/questions, please let me know.
 
  --
  Luciano Resende
  http://people.apache.org/~lresende 
http://people.apache.org/%7Elresende
 
 
  -- Forwarded message --
  From: Adriano Crestani (JIRA) tuscany-dev@ws.apache.org
  Date: Mar 15, 2007 10:39 AM
  Subject: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite
 Command
  classes
  To: tuscany-dev@ws.apache.org
 
 
   [
 
 

https://issues.apache.org/jira/browse/TUSCANY-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
  ]
 
  Adriano Crestani updated TUSCANY-1140:
  --
 
  Attachment: tuscany1040.crestani.20070315.patch
 
  - Added a new project to vs solution titled das_lite
 
  - Implementation of ReadCommanImpl, BaseCommandImpl and CommandImpl
  classes
 
  - Integration with sdo on ReadCommanImpl::buildGraph method is not
 working
 
  correctly
 
  - Also added other classes of das_lite library, but not completely
  implemented yet
 
   Implementation of DAS Lite Command classes
   --
  
   Key: TUSCANY-1140
   URL:
 https://issues.apache.org/jira/browse/TUSCANY-1140
   Project: Tuscany
Issue Type: Sub-task
Components: C++ DAS
  Affects Versions: Wish list
  Reporter: Adriano Crestani
   Assigned To: Adriano Crestani
   Fix For: Wish list
  
   Attachments: tuscany1040.crestani.20070315.patch
  
  
   Implementation of BaseCommandImpl, Command, CommandImpl and
  ReadCommandImpl classes as described on the DAS Lite  class diagram:
  http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093
 
  --
  This message is automatically generated by JIRA.
  -
  You can reply to this email to add a comment to the issue online.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread ant elder


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 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, 2007 10:46 AM
Subject: Re: svn commit: r519930 - in

/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl:
ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java


 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 package name.

 Thanks,
 Raymond

 - Original Message -
 From: [EMAIL PROTECTED]
 To: tuscany-commits@ws.apache.org
 Sent: Monday, March 19, 2007 5:41 AM
 Subject: svn commit: r519930 - in


/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl:
 ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java


  Author: antelder
  Date: Mon Mar 19 05:40:59 2007
  New Revision: 519930
 
  URL: http://svn.apache.org/viewvc?view=revrev=519930
  Log:
  Copy IDL classes from integration brn to trunk to get idl WSDL
building
 in
  trunk (probably only temp here till the IDL work is done)
 
  Added:
 
 

incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java
   - copied unchanged from r519927,
 

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ElementInfo.java
 
 

incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java
   - copied unchanged from r519926,
 

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/ServiceFaultException.java
 
 

incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java
   - copied unchanged from r519927,
 

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/TypeInfo.java
 
 

incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java
   - copied unchanged from r519927,
 

incubator/tuscany/branches/sca-java-integration/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl/XMLType.java
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: C++ DAS Lite versus C++ DAS, was Fwd: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite Command classes

2007-03-19 Thread Luciano Resende


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 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 the patch? I think you should copy all the files I sent to you
into the repo.

Adriano Crestani

On 3/16/07, Luciano Resende [EMAIL PROTECTED] wrote:

 I have just applied your patch. At some point, once we get things more
 stable, we should decide witch way to go, and maybe promote the das_lite
 to
 just c++ das. For now this should be OK.

 BTW, I liked Pete's comments : keep DASing ;-)

 --
 Luciano Resende
 http://people.apache.org/~lresende

 On 3/15/07, Adriano Crestani [EMAIL PROTECTED] wrote:
 
  I think you got the point when you said to remove the files from the
  project, I don't know how I hadn't thought about it. Because the main
  reason
  to create a new project in VS solution is to avoid the compilation
 errors
  from those many classes that are not completed implemented.
 
  But also because I wanted to keep the previous implementation, for
  example,
  of the class ReadCommandImpl that was reimplemented in das_lite
project.
  With diferent versions of classes we can define what is already
  implemented
  completely(das_lite project) and what remains to be
  implemented(das_runtime
  project).
 
  I think we could try another approach where we could move the classes
 from
  the das_runtime to a trunk or something like and the classes that we
are
  actually implementing from the das_lite(cpp/das/runtime/das_lite/src/)
  project to the das_runtime(cpp/das/runtime/core/src) project and
  continuing
  implementing from there.
 
  What do you think?
 
  Adriano Crestani
 
 
 
 
 
  On 3/15/07, Luciano Resende [EMAIL PROTECTED] wrote:
  
   Hi Adriano
  
  I was looking into your patch, and realized you had created a new
   project
   located at (cpp/das/runtime/das_lite/src/) instead of continuing to
 work
   on
   (cpp/das/runtime/core/src). I tought that from a previous quick
  discussion
  
   we had agreed that das_lite was more a initial simple scenario
rather
  then
   a
   new project.
  
  I have couple questions :
  - Could you please elaborate what your plans are here ?
  - What's the main differences between C++ DAS and C++ DAS
Lite
 ?
  - Is this new project a small subset of files that were
  duplicated
   from cpp/das/runtime/core/src ? If so, is there a way to have one
  project
   but only compile/use the subset of files required, maybe just not
 adding
   them to the VS project ?
  
  I'll wait after clarification on this subject before I apply the
  patch.
  If anyone else have other thoughts/questions, please let me know.
  
   --
   Luciano Resende
   http://people.apache.org/~lresende 
 http://people.apache.org/%7Elresende
  
  
   -- Forwarded message --
   From: Adriano Crestani (JIRA) tuscany-dev@ws.apache.org
   Date: Mar 15, 2007 10:39 AM
   Subject: [jira] Updated: (TUSCANY-1140) Implementation of DAS Lite
  Command
   classes
   To: tuscany-dev@ws.apache.org
  
  
[
  
  
 

https://issues.apache.org/jira/browse/TUSCANY-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
   ]
  
   Adriano Crestani updated TUSCANY-1140:
   --
  
   Attachment: tuscany1040.crestani.20070315.patch
  
   - Added a new project to vs solution titled das_lite
  
   - Implementation of ReadCommanImpl, BaseCommandImpl and CommandImpl
   classes
  
   - Integration with sdo on ReadCommanImpl::buildGraph method is not
  working
  
   correctly
  
   - Also added other classes of das_lite library, but not completely
   implemented yet
  
Implementation of DAS Lite Command classes
--
   
Key: TUSCANY-1140
URL:
  https://issues.apache.org/jira/browse/TUSCANY-1140
Project: Tuscany
 Issue Type: Sub-task
 Components: C++ DAS
   Affects Versions: Wish list
   Reporter: Adriano Crestani
Assigned To: Adriano Crestani
Fix For: Wish list
   
Attachments: tuscany1040.crestani.20070315.patch
   
   
Implementation of BaseCommandImpl, Command, CommandImpl and
   ReadCommandImpl classes as described on the DAS Lite  class diagram:
  
http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093
  
   --
   This message is automatically generated by JIRA.
   -
   You can reply to this email to add a comment to the

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread Jim Marino



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 model that cause tangles between the packages.


Jim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519930 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/idl: ElementInfo.java ServiceFaultException.java TypeInfo.java XMLType.java

2007-03-19 Thread Jim Marino



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. Otherwise,  
we'll need to come up with a better solution.


Jim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ecore2Ecore Model and Processor Donation

2007-03-19 Thread Ole Ersoy

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
(LibrarySpecDescriptor)
3) I load maven pom.xml instances and use the ecore2ecore processor to
create corresponding LibrarySpecDescriptor instances (That are passed to
a JET template for generating RPM Spec files).

So the Ecore2Ecore model describes how EClassifiers of two different
models relate, as well as howthe EStructuralFeatures of the two models map.

The processor will create a target model instance, given a source model
instance.

SDO Scenario:
Suppose you had an SDO model: PurchaseOrderVersion1

Later you create a newer version: PurchaseOrderVersion2

PurchaseOrderVersion2 has features and classes that map to
PurchaseOrderVersion1
In addition PurchaseOrderVersion2 has additional features and classes
that map to SupplierVersion1

So you wish to create PurchaseOrderVersion2 instances from
PurchaseOrderVersion1 instances, along with SupplierVersion1 instances.

You could use Ecore2Ecore to map the models and then the
Ecore2EcoreProcessor to create the PurchaseOrderVersion2 instances.

Does that help?

Please let me know if need to elaborate on certain areas.

Thanks,
- Ole

Fuhwei Lwo wrote:

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 model maps one ecore model to another.
It's different from the Eclipse implementation (Thought it was tricky to
use),

but I tried to reuse the naming of objects as much as possible.

The processor will take a source model instance and create the
corresponding target model.

Here is the URL:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all/ecore2ecore.model.parent

Cheers,
- Ole

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ecore2Ecore Model and Processor Donation

2007-03-19 Thread Ole Ersoy


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 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 
the goal, over time, is to decrease the dependence on EMF. An EMF-specific 
(Ecore) mapping model would not be appropriate at Tuscany. 

Have you considered contributing it to the EMFT (EMF Technology) project 
at Eclipse? EMFT is the intended home for new EMF-based technologies.


Frank

Ole Ersoy [EMAIL PROTECTED] wrote on 03/17/2007 07:15:38 PM:

  

Hi,

I've created an Ecore2Ecore Model and Processor.

I was wondering if this might find a home in Tuscany?

The model maps one ecore model to another. 
It's different from the Eclipse implementation (Thought it was tricky to 



  

use),
but I tried to reuse the naming of objects as much as possible.

The processor will take a source model instance and create the 
corresponding target model.


Here is the URL:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.
factory.all/ecore2ecore.model.parent

Cheers,
- Ole



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SDO Java M3 Release Candidate RC1

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 middle of a medium to large sized method. We request a slight 
refactoring of the base (EMF) code, which they agree to fix in their next 
version.
3) We can't move to the next version yet, so we add a copy of the method 
(with the change) in our subclass and then proceed as if it was already in 
the base class.

Note that we really don't want to do this in the first place because if we 
later forget to remove the override and EMF fixes some other bug in the 
same method, we won't ever pick up the fix. Unfortunately, however, we 
have no choice in the short term other than to rewrite the whole method, 
but since it's intricately tied to the rest of the base class 
implementation it really couldn't be much different. We could rewrite the 
entire class, but that completely defeats the purpose of reuse.

Does anybody know how this kind of necessary copying is addressed? I 
also wonder where is the fine line between providing a changed method vs 
a copied method with a change in a subclass? For example, what if one of 
the copied methods was only 3 lines and we changed one of them? Is that 
still a copy?

Thanks,
Frank.

Jeremy Boynes [EMAIL PROTECTED] wrote on 03/19/2007 10:27:52 AM:

 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 presume this is IBM code) relicense it under 
 AL and contribute
via the IP Clearance process
 * Do an alternative implementation, best done by someone who has not 
 seen the Eclipse code
 
 --
 Jeremy
 
 On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
 
  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 using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
  asked the EMF team if they could switch this to the IOC pattern, so we
  could inject our SDO specific metadata factories. They said they 
  would,
  but can't before EMF version 2.3 which is Java 5 dependent. Since 
  we won't
  (can't) move to EMF 2.3, our interim solution was to create 
  subclasses in
  Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
  override the methods that create metadata. The subclasses contain 
  copies
  of the base method, only using a factory instance variable instead 
  of the
  singleton. For example:
 
  class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
  protected EcoreFactory ecoreFactory;
 
  void someXSDEcoreBuilderMethod() {
  bla ... bla ... bla ...
  // replaced this line: someVariable =
  EcoreFactory.eINSTANCE.createXXX();
  someVariable = ecoreFactory.createXXX();
  bla ... bla ... bla ..
  }
 
  ... etc.
 
  }
 
  So, the question is, what kind of license do we need in these two 
  Tuscany
  classes?
 
  1. Apache.
  2. Apache + Eclipse
  3. Other?
 
  Currently, I think we just have #1. If anyone can provide guidance on
  this, it would be much appreciated.
 
  Thanks,
  Frank.
 
 
  Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:
 
  Those are the ones. You said before that you thought this might be
  generated but that you were sure Frank would confirm. He has not done
  so.
 
  What seems odd to me is that if this was generated then I would have
  expected consistent text to have been produced by the generator.
  Instead we have things like:
 
  + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
  Exp $
 
  and
 
  + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
 
  which correlate directly to headers found in files in the Eclipse
  repo. This makes the provenance of the code uncertain which is why we
  need clarification of what happened.
 
  --
  Jeremy
 
  On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
 
  I think you are freferring to commit r513560 .* *There was no code
  copied
  from eclipse.  The EMF generator puts an eclipse header in to
  generated code
  by default. That code was simply the result of using that generator
  against
  our own schemas.
 
  Regards, Kelvin.
 
 
 
 
  On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
 
  Not to be a party-pooper, but what was the outcome with the code
  copied from Eclipse?
  --
  Jeremy
 
  On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
 
  I have posted an SDO Java

SDO IP Issues, was: SDO Java M3 Release Candidate RC1


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:
  When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of  
the Program.


Distributing EPL code in source form under the Apache License is a  
violation of these EPL terms. Period.


To distribute this code under the Apache License it needs to be  
relicensed by the copyright owner. This is not an ongoing  
contribution as covered by a CCLA but a grant of software written  
elsewhere to the Foundation. There is a process for this, handled by  
the Incubator:

  http://incubator.apache.org/ip-clearance/index.html

Another alternative might be to distribute the code in binary form.  
This would involve making the necessary change elsewhere (say at  
Eclipse), releasing that derivative under the EPL in binary form.  
Tuscany would then be able to redistribute that code in its binary  
form. That's a suggestion - you probably want to talk to a lawyer and  
I would suggest running it past [EMAIL PROTECTED]



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 middle of a medium to large sized method. We request a slight
refactoring of the base (EMF) code, which they agree to fix in  
their next

version.
3) We can't move to the next version yet, so we add a copy of the  
method
(with the change) in our subclass and then proceed as if it was  
already in

the base class.

Note that we really don't want to do this in the first place  
because if we
later forget to remove the override and EMF fixes some other bug in  
the

same method, we won't ever pick up the fix. Unfortunately, however, we
have no choice in the short term other than to rewrite the whole  
method,

but since it's intricately tied to the rest of the base class
implementation it really couldn't be much different. We could  
rewrite the

entire class, but that completely defeats the purpose of reuse.

Does anybody know how this kind of necessary copying is addressed? I
also wonder where is the fine line between providing a changed  
method vs
a copied method with a change in a subclass? For example, what if  
one of
the copied methods was only 3 lines and we changed one of them? Is  
that

still a copy?

Thanks,
Frank.

Jeremy Boynes [EMAIL PROTECTED] wrote on 03/19/2007 10:27:52 AM:


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 presume this is IBM code) relicense it under
AL and contribute
   via the IP Clearance process
* Do an alternative implementation, best done by someone who has not
seen the Eclipse code

--
Jeremy

On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:


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 using those evil singletons: EcoreFactory.eINSTANCE.createXXX 
(). We
asked the EMF team if they could switch this to the IOC pattern,  
so we

could inject our SDO specific metadata factories. They said they
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since
we won't
(can't) move to EMF 2.3, our interim solution was to create
subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain
copies
of the base method, only using a factory instance variable instead
of the
singleton. For example:

class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;

void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}

... etc.

}

So, the question is, what kind of license do we need in these two
Tuscany
classes?

1. Apache.
2. Apache + Eclipse
3. Other?

Currently, I think we just have #1. If anyone can provide  
guidance on

this, it would be much appreciated.

Thanks,
Frank.


Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:


Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not

Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1

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 infringement. This 
 is not something to take lightly.

I'm sure that's true. Nobody's taking this lightly. 

In this particular case, however, both parties, the EMF contributors at 
Eclipse, and the Tuscany consumers (us) here at Apache agree that this is 
not a case of copyright infringement. So, it seems to me that a 
light-weight process for dealing with this kind of scenario is needed. If 
need be, we'll pull out this code temporarily, but I'd prefer to see some 
sensible way to deal with it without doing that.

I'm also still looking for an answer to my question from below: I also 
wonder where is the fine line between providing a changed method vs a 
copied method with a change in a subclass?

According to the strict interpretation of the two licenses, you really 
can't do much with EPL code at Apache. Something as trivial as overriding 
a base method that looks like this:

void foo() {
  x = 3;
  bar();
}

to set x to 4 instead of 3:

void foo() {
  x = 4;
  bar();
}

could be considered copyright infringement. If not, then where is the fine 
line?

Thanks,
Frank.

 
 EPL is very specific:
When the Program is made available in source code form:
  a) it must be made available under this Agreement; and
  b) a copy of this Agreement must be included with each copy of 
 the Program.
 
 Distributing EPL code in source form under the Apache License is a 
 violation of these EPL terms. Period.
 
 To distribute this code under the Apache License it needs to be 
 relicensed by the copyright owner. This is not an ongoing 
 contribution as covered by a CCLA but a grant of software written 
 elsewhere to the Foundation. There is a process for this, handled by 
 the Incubator:
http://incubator.apache.org/ip-clearance/index.html
 
 Another alternative might be to distribute the code in binary form. 
 This would involve making the necessary change elsewhere (say at 
 Eclipse), releasing that derivative under the EPL in binary form. 
 Tuscany would then be able to redistribute that code in its binary 
 form. That's a suggestion - you probably want to talk to a lawyer and 
 I would suggest running it past [EMAIL PROTECTED]
 
  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 middle of a medium to large sized method. We request a slight
  refactoring of the base (EMF) code, which they agree to fix in 
  their next
  version.
  3) We can't move to the next version yet, so we add a copy of the 
  method
  (with the change) in our subclass and then proceed as if it was 
  already in
  the base class.
 
  Note that we really don't want to do this in the first place 
  because if we
  later forget to remove the override and EMF fixes some other bug in 
  the
  same method, we won't ever pick up the fix. Unfortunately, however, we
  have no choice in the short term other than to rewrite the whole 
  method,
  but since it's intricately tied to the rest of the base class
  implementation it really couldn't be much different. We could 
  rewrite the
  entire class, but that completely defeats the purpose of reuse.
 
  Does anybody know how this kind of necessary copying is addressed? I
  also wonder where is the fine line between providing a changed 
  method vs
  a copied method with a change in a subclass? For example, what if 
  one of
  the copied methods was only 3 lines and we changed one of them? Is 
  that
  still a copy?
 
  Thanks,
  Frank.
 
  Jeremy Boynes [EMAIL PROTECTED] wrote on 03/19/2007 10:27:52 AM:
 
  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 presume this is IBM code) relicense it under
  AL and contribute
 via the IP Clearance process
  * Do an alternative implementation, best done by someone who has not
  seen the Eclipse code
 
  --
  Jeremy
 
  On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
 
  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 using those evil singletons: EcoreFactory.eINSTANCE.createXXX 
  (). We
  asked the EMF team if they could switch this to the IOC pattern, 
  so we
  could inject our SDO specific metadata

Re: Does the itest plugin support extensions?


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 back? Or are we waiting for the  
contribution service to handle extensions?


We're waiting for the contrib service. The short-term hack for the  
standalone is to add the jars to boot and edit the system.scdl file  
to include the extension's scdl. I don't believe thought that works  
for the itest plugin as there's no classpath extension.


--
Jeremy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r520115 - in /incubator/tuscany/sandbox/isilval/notification/samples/local/src: main/java/org/apache/tuscany/notification/local/ test/java/org/apache/tuscany/notification/local/