Problem with cts pom?
After running svn update earlier this week, I am unable to run the cts due to the following error. I know that changes were made to the pom under TUSCANY-1195 so does this mean there are different instructions for running the cts now? Thanks, Andy. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.tuscany:cts:pom:1.0-SNAPSHOT Reason: Cannot find parent: org.apache.tuscany:parent for project: org.apache.tuscany:cts:pom:1.0-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany:parent for project: org.apache. tuscany:cts:pom:1.0-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:373)
Re: Language independent interface definition work
ant elder wrote: I've started on the language independent interface definition work that has been talked about on several threads. So it doesn't impact anything i've created separate modules idl, idl-java and idl-wsdl and with this new flat build structure it seemed appropriate to put them in the trunk sca folder. Nothing else is using these projects and right now they're pretty empty, i'll start copying the various existing classes to here and go from there. ...ant Ant, I've added pretty basic language independent representations of Interface and Operation to the sca/idl module for now as I needed something to represent service interfaces and operations in the scdl4j models. Feel free to change them when you start adding stuff to the idl module. I'll adjust scdl4j later to use what you'll come up with. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Jeremy, I started another DISCUSS thread to "keep talking", you still need to let everyone know what you think of this VOTE. thanks, dims On 3/29/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: > Hi Jeremy, > > Here is a problem that most of us are facing with the Trunk and is > hindering > us to effectively contribute to the trunk. I see there is one > solution that > has been proposed to making this simpler with some compromises. If > this is > not agreeable what is the alternative for those of us who are > waiting for a > solution to this. Whats the simple way for any of us - including > somebody > getting in afresh - to quickly jump in and start contributing > without having > to worry about the build intricacies. Should we consider Bert's > suggestion? At the moment, this is a straight up/down binary vote on a fairly vague proposal, one that some people have specific technical concerns over. There are other proposals out there but we seem to have lost sight of that. IMO, yes, we should consider Bert's proposal, and mine for assemblies, and anything else anyone can think of that is less divisive. > Theres been may a time when you have helped us out of various > technical > difficulties. Here is yet another time I request for help from you > for a > way out of this. Thanks. My suggestion is, keep talking. The important thing here is about seeing if we can work together to reach consensus. What the technical outcome is really doesn't matter. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Jim, I started another DISCUSS thread to "look at these", you still need to let everyone know what you think of this VOTE. thanks, dims On 3/29/07, Jim Marino <[EMAIL PROTECTED]> wrote: On Mar 29, 2007, at 10:28 AM, Jeremy Boynes wrote: > On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: > >> Hi Jeremy, >> >> Here is a problem that most of us are facing with the Trunk and is >> hindering >> us to effectively contribute to the trunk. I see there is one >> solution that >> has been proposed to making this simpler with some compromises. >> If this is >> not agreeable what is the alternative for those of us who are >> waiting for a >> solution to this. Whats the simple way for any of us - including >> somebody >> getting in afresh - to quickly jump in and start contributing >> without having >> to worry about the build intricacies. Should we consider Bert's >> suggestion? > > At the moment, this is a straight up/down binary vote on a fairly > vague proposal, one that some people have specific technical > concerns over. There are other proposals out there but we seem to > have lost sight of that. IMO, yes, we should consider Bert's > proposal, and mine for assemblies, and anything else anyone can > think of that is less divisive. > I'd prefer we look at these as well. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] Next version - What should be in it
Folks, Let's keep the ball rolling...Can someone please come up with a master list of "extensions, bindings, services, samples" which can then help decide what's going to get into the next release. Please start a wiki page to document the master list. Once we are done documenting the list. We can figure out which ones are MUST, which ones are nice to have, which ones are out of scope. Then we can work backwards to figure out How tightly or loosely coupled each piece is/should be and how we could decouple them if necessary using interfaces/spi/whatever... Quote from Bert Lamb: "I think there should be a voted upon core set of extensions, bindings, services, samples, whatever that should be part of a monolithic build." http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html Quote from Ant Elder: The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html Thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany Unpack issues
Hi, I'm one of the Maven developers next-door at apache and the main developer for the maven-dependency-plugin. We've had a few requests recently from Tuscany users who have problems with the instructions or with the pom. (I haven't found the instructions yet so I can't be positive) You can see this thread for more info: http://www.nabble.com/mvn-dependency%3Aunpack-tf3436260s177.html#a9580702 It seems that the instructions indicate to run "mvn dependency:unpack", however the POM isn't setup correctly to do this. I recently added a FAQ to the site as well as more examples for this use case here: http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#question I figured I'd pop in to see if we can try to get this fixed up so the users don't have a bad experience both with Tuscany and Maven. Let me know if there's anything I can do to help. -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working with Tuscany SDOs reflectively
Hey Frank, Yes - I can see how trying to change the specification, at least in the next couple of days, might be a long shot :-) I guess I'll just put a SDOUtil method in to separate the "EAttributes" from the "EReferences". That way when the SDOs are stored in ApacheDS, the DAS is not calling isDataType every time it processes a SDO property. Incidentally, terminology wise, would it be correct for me to call EAttributes simple properties and EReferences complex properties? Thanks, - Ole Frank Budinsky wrote: Hi Ole, It will probably be hard to convince people to add the extra lists to the SDO specification. It was intentionally designed to have one simple list. Adding some methods in Tuscany (in class SDOUtil) to return just the dataType or non-dataType properties is possible, but as SDO is now being standardized and there are multiple implementations of it, it's really best to avoid using implementation-specific APIs, if possible. getType().getProperties() returns all the properties (including from the base types) - it's like EMF's getEAllStructuralFeatures(). getType().getDeclaredProperties() returns just the locally defined properties - like EMF's getEStructuralFeatures(). Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 03:04:52 PM: Super - Thanks Frank. This may be something I should be brining up to the SDO Specification guys, but it seems like Ecore's way of separating the EAttributes and the EReferences into separate lists will be more efficient from the perspective of of looking for various class members. For instance sometimes I'm only interested in the EAttributes, and with the EMF API I have access to only the List containing the EAttributes, so the time it takes to iterate through this list is shorter than the time it takes to iterate through all the EStructuralFeatures, which it seems like what I would be doing with the SDO API... Any thoughts? Could we perhaps add something to the Tuscany SDO implementation that gives us the ability to iterate through the isDataType() members of the SDO object and also the non isDataType() members. In addition, Ecore has the eObject.eClass().getEAllEReferences or EAttributes... giving us the inherited members as well. Is this what the SDO object returns when calling getType().getProperties() except in return in effect all the EStructuralFeatures? Thanks, - Ole Frank Budinsky wrote: In SDO there's a list of properties (simple and complex combined) that you can get like this: List properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 01:59:05 PM: Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EList attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EList references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - 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] - 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: [Discussion] Tuscany kernel modulization
Hi Sebastien I think it would be worth splitting contribution in two parts. - Contribution metadata: What's described in sca-contribution.xml and the relationships with the assembly and interface definition models (e.g. the list of deployables pointing to assembly composites, maybe also pointers to the interfaces containing in the contribution and the ones imported from others) plus the mechanisms for parsing that contribution file. - Contribution service: the SPI to add/remove/list etc. contributions in an SCA domain. Contribution metadata would be in the metadata layer. Contribution service in the system services layer. I think what you are describing here is very similar with the design I have on the latest implementation of the contribution services available in java/sca/runtime/services/contribution. I have also updated the wiki page [1] with latest design being used on the Contribution services if people would like to get more information. [1] - http://cwiki.apache.org/confluence/display/TUSCANY/Deployment On 3/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Raymond Feng wrote: > Hi, > > By reading through a bunch of e-mails on this mailing list and adding > my imagination, I put together a conceptual diagram at the following > wiki page to illustrate the kernel modulization. > > http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions > > > This diagram is merely for the discussion purpose and it only reflects > my understandings so far. By no means it is meant to be complete and > accurate. But I hope we can use it as the starting point for the > technical discussion. > > Going through this exercise, I start to see values of the efforts > which would lead to greater adoption of Tuscany/SCA by various > embedders including other Apache projects and simplication of the > kernel that the community can work together. You might take the > following items as my crazy brainstorming: > > 1) Allow different ways to populate the assembly model: from SCDL, > from other Domain Specific Languages (DSL) or even from another model > such as the Spring context. On the hand, make it possible to convert > the SCA assembly model to be executed by other frameworks such as Spring. > > 2) Improve the federation story so that we can plugin different > federation mechanisms, such as P2P discovery-based or repository-based > schemes. > > 3) Bootstrap the Tuscany kernel without the Java container in case > that either the hosting runtime is resource-constrained (for example, > cellular phones or network appliances) or it doesn't need to the > support for POJO (for example, scripting for Web 2.0). > > 4) Provide more flexibility to integrate with different hosting > environments with a subset of kernel modules. > ... > > I guess I throw out enough seeds for thoughts and now it's your turn :-). > > Thanks, > Raymond > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Raymond, This diagram looks pretty good to me. I have a few comments and thoughts: I think it would be worth splitting contribution in two parts. - Contribution metadata: What's described in sca-contribution.xml and the relationships with the assembly and interface definition models (e.g. the list of deployables pointing to assembly composites, maybe also pointers to the interfaces containing in the contribution and the ones imported from others) plus the mechanisms for parsing that contribution file. - Contribution service: the SPI to add/remove/list etc. contributions in an SCA domain. Contribution metadata would be in the metadata layer. Contribution service in the system services layer. I would also place the SCDL loader framework and any other Domain Specific Language people want to use to define an SCA assembly in the metadata layer as well. What to you think about turning kernel extensions (e.g support for Java components, Axis2 Bindings, WSDL/XSD interface definitions) into vertical boxes on the side of the diagram, to help show that they contribute to the different layers. For example, support for Java components contributes extensions to several layers: - the metadata layer (model representing the Java artifacts, support for the SCDL and elements, and introspection of Java5 annotations) - the databinding support (with bindings to beans and the various databinding technologies supported in Java application code) - the invocation framework (with proxy/invocation handling and dispatching of calls to a Java component) It's just an idea, maybe colors will also help show this dimension better. I also have some questions: - I'm not sure where the runtime builders belong. What do people think? - What about the modules under Pluggable Federations? a lot of good work has been done in that space recently, does anybody have any comments on how it's decomposed in modules in the
Re: Working with Tuscany SDOs reflectively
Hi Ole, It will probably be hard to convince people to add the extra lists to the SDO specification. It was intentionally designed to have one simple list. Adding some methods in Tuscany (in class SDOUtil) to return just the dataType or non-dataType properties is possible, but as SDO is now being standardized and there are multiple implementations of it, it's really best to avoid using implementation-specific APIs, if possible. getType().getProperties() returns all the properties (including from the base types) - it's like EMF's getEAllStructuralFeatures(). getType().getDeclaredProperties() returns just the locally defined properties - like EMF's getEStructuralFeatures(). Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 03:04:52 PM: > Super - Thanks Frank. > > This may be something I should be brining up to the SDO Specification guys, > but it seems like Ecore's way of separating > the EAttributes and the EReferences into separate lists will > be more efficient from the perspective of of looking for various > class members. > > For instance sometimes I'm only interested in the EAttributes, and with > the EMF > API I have access to only the List containing the EAttributes, so the > time it takes > to iterate through this list is shorter than the time it takes to iterate > through all the EStructuralFeatures, which it seems like what I would be > doing with the > SDO API... > > Any thoughts? > > Could we perhaps add something to the Tuscany SDO implementation that > gives us the ability to iterate through the isDataType() members of the > SDO object > and also the non isDataType() members. > > In addition, Ecore has the eObject.eClass().getEAllEReferences or > EAttributes... > giving us the inherited members as well. Is this what the SDO object > returns > when calling > > getType().getProperties() > > except in return in effect all the EStructuralFeatures? > > Thanks, > - Ole > > > > Frank Budinsky wrote: > > In SDO there's a list of properties (simple and complex combined) that you > > can get like this: > > > > List properties = userSDO.getType().getProperties(); > > > > If you are interested in the simple ones, you need to do something like > > this when iterating through the list: > > > > if (property.getType().isDataType()) ... > > > > Frank. > > > > Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 01:59:05 PM: > > > > > >> Hi, > >> > >> I asked this question a little differently before referring to EMF's > >> > > ecore, > > > >> and I'll try again by restating what I wish to do. > >> > >> Suppose I have an SDO instance > >> > >> Class name UserSDO, > >> > >> instance userSDO > >> > >> I would like to get a list of all the non-complex object members of > >> userSDO > >> > >> So for instance if userSDO has some String members > >> like userName and userPassword > >> > >> I would like a list of these. > >> > >> Do I just use regular java reflection or does > >> the Tuscany SDO API have something similar to > >> EMF's EClass. > >> > >> If I were using EMF I could > >> do > >> EClass eClass = userSDO.eClass(); > >> > >> Then to get the members I would do > >> EList attributes = eClass.getEAttributes(); > >> > >> If I wanted the complext object references I would > >> do > >> > >> EList references eClass.getEReferences(); > >> > >> Does the Tuscany SDO API have something similar? > >> > >> Thanks, > >> - 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add a simple embedded runtime for Tuscany dummies
Hi, It's now checked in under r523826 and r523828. You can find the code at java/sca/runtime/embedded. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 28, 2007 9:38 AM Subject: Re: Add a simple embedded runtime for Tuscany dummies Venkata Krishnan wrote: Hi, I whole-heartedly admit to the comfort of being able to run and debug within IDE. Its really very useful to get a grasp of how the runtime works. For example, if one were to understand the role of loaders, builders, the wire service and the invocation pattern, running a sample test or an iTest from within an IDE and debugging it gives a real fair idea of all of this. Raymond thanks and I hope to check this out later during the day. - Venkat On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, I know we have removed SCATestCase from the trunk, but I always find it very useful and convenient for me to run test cases or samples from inside the IDE directly (by right-clicking on the class and select "Run..." or "Debug"), especially for debugging and testing purposes. I put together a simple "embedded runtime" based on the idea of SCATestCase so that we can bootstrap Tuscany system and the application code from the same classpath in case that class isolations are not of interest. It's built on top of the current kernel in trunk. You can find the code at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/runtime/embedded/ . There are two things you can try: * calculator.CalculatorClient is a sample with main() * org.apache.tuscany.api.SCARuntimeTestCase is a JUNIT test case. I think it can complement the other runtimes we have in trunk such as standalone and itest. I would like to check it in under java/runtime if you agree with me. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it's very useful, and really easy to use. Here are a few suggestions to improve your Calculator sample and the test case: - I think it would be good to rename application.composite to .composite - change the call to SCARuntime.start() to SCARuntime.start(composite file>), as this version of the start method seems the most useful to show - and add test cases exercising the few variations of SCARuntime.start(...) -- Jean-Sebastien - 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: Working with Tuscany SDOs reflectively
Super - Thanks Frank. This may be something I should be brining up to the SDO Specification guys, but it seems like Ecore's way of separating the EAttributes and the EReferences into separate lists will be more efficient from the perspective of of looking for various class members. For instance sometimes I'm only interested in the EAttributes, and with the EMF API I have access to only the List containing the EAttributes, so the time it takes to iterate through this list is shorter than the time it takes to iterate through all the EStructuralFeatures, which it seems like what I would be doing with the SDO API... Any thoughts? Could we perhaps add something to the Tuscany SDO implementation that gives us the ability to iterate through the isDataType() members of the SDO object and also the non isDataType() members. In addition, Ecore has the eObject.eClass().getEAllEReferences or EAttributes... giving us the inherited members as well. Is this what the SDO object returns when calling getType().getProperties() except in return in effect all the EStructuralFeatures? Thanks, - Ole Frank Budinsky wrote: In SDO there's a list of properties (simple and complex combined) that you can get like this: List properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 01:59:05 PM: Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EList attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EList references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - 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]
SCA TESTING common testing environement or packaging
Hi. For SDO we contributed to the SDO CTS allowing tuscany to consume our test cases. In the CTS we took the approach of a vendor independent component of tests (java/cts/sdo2.1) and a vendor specific impl (java/cts/sdo2.1-tuscany) which uses the tests and handled initialization etc. This has worked well for us. We are now looking at some sca testing and I am hoping that we can contribute our test cases back to tuscany as well. In general our tests are very similar to the format of the itests where there is an application which lifecycle is managed by the testing infrastructure and junit is used to test it's functionality. We have our own automation environment for handling the lifecycles of applications and test execution ( one day it would be really nice if this could be expressed in a general way so that ithe description could be portable between automation environments ). I think there is a good opportunity to work on a environment for tests that can be used and contributed to by implementations of the sca specification. This could be as simple as agreeing on some generic packaging schemes ( we used test.sdo... for the cts ) that would save constant refactoring when we contribute tests back to tuscany or could even involve a common description for the lifecycle of tests and sca applications. What are people's thoughts on this ? cheers, Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-1147.patch Here's the two-line fix, which should be an improvement on the previous one-line fix. I ran the tests and they worked for me. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1147.patch, Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- 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: Working with Tuscany SDOs reflectively
In SDO there's a list of properties (simple and complex combined) that you can get like this: List properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 01:59:05 PM: > Hi, > > I asked this question a little differently before referring to EMF's ecore, > and I'll try again by restating what I wish to do. > > Suppose I have an SDO instance > > Class name UserSDO, > > instance userSDO > > I would like to get a list of all the non-complex object members of > userSDO > > So for instance if userSDO has some String members > like userName and userPassword > > I would like a list of these. > > Do I just use regular java reflection or does > the Tuscany SDO API have something similar to > EMF's EClass. > > If I were using EMF I could > do > EClass eClass = userSDO.eClass(); > > Then to get the members I would do > EList attributes = eClass.getEAttributes(); > > If I wanted the complext object references I would > do > > EList references eClass.getEReferences(); > > Does the Tuscany SDO API have something similar? > > Thanks, > - 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]
Working with Tuscany SDOs reflectively
Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EList attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EList references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
On Mar 29, 2007, at 10:28 AM, Jeremy Boynes wrote: On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: Hi Jeremy, Here is a problem that most of us are facing with the Trunk and is hindering us to effectively contribute to the trunk. I see there is one solution that has been proposed to making this simpler with some compromises. If this is not agreeable what is the alternative for those of us who are waiting for a solution to this. Whats the simple way for any of us - including somebody getting in afresh - to quickly jump in and start contributing without having to worry about the build intricacies. Should we consider Bert's suggestion? At the moment, this is a straight up/down binary vote on a fairly vague proposal, one that some people have specific technical concerns over. There are other proposals out there but we seem to have lost sight of that. IMO, yes, we should consider Bert's proposal, and mine for assemblies, and anything else anyone can think of that is less divisive. I'd prefer we look at these as well. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unpack issues with Tuscany
Hi, I'm one of the Maven developers next-door at apache and the main developer for the maven-dependency-plugin. We've had a few requests recently from Tuscany users who have problems with the instructions or with the pom. (I haven't found the instructions yet so I can't be positive) You can see this thread for more info: http://www.nabble.com/mvn-dependency%3Aunpack-tf3436260s177.html#a9580702 It seems that the instructions indicate to run "mvn dependency:unpack", however the POM isn't setup correctly to do this. I recently added a FAQ to the site as well as more examples for this use case here: http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#question I figured I'd pop in to see if we can try to get this fixed up so the users don't have a bad experience both with Tuscany and Maven. Let me know if there's anything I can do to help. -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: Hi Jeremy, Here is a problem that most of us are facing with the Trunk and is hindering us to effectively contribute to the trunk. I see there is one solution that has been proposed to making this simpler with some compromises. If this is not agreeable what is the alternative for those of us who are waiting for a solution to this. Whats the simple way for any of us - including somebody getting in afresh - to quickly jump in and start contributing without having to worry about the build intricacies. Should we consider Bert's suggestion? At the moment, this is a straight up/down binary vote on a fairly vague proposal, one that some people have specific technical concerns over. There are other proposals out there but we seem to have lost sight of that. IMO, yes, we should consider Bert's proposal, and mine for assemblies, and anything else anyone can think of that is less divisive. Theres been may a time when you have helped us out of various technical difficulties. Here is yet another time I request for help from you for a way out of this. Thanks. My suggestion is, keep talking. The important thing here is about seeing if we can work together to reach consensus. What the technical outcome is really doesn't matter. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
On 3/29/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: If I understand your clarification correctly, this vote is about putting out a single release with a certain number of modules in it, and with each module having the same version number. In particular, this vote does not set a cast-in-stone precedent about how future releases will be put together. Also, it is assumed that consensus will eventually be able to be reached about what the modules in the release will be (without this assumption, this vote seems pointless to me). While it is not clear to me that this is the best approach to follow from an open source project point of view, with the constraints and assump- tions above it seems to me to be reasonably safe to vote +1. So, if the constraints and assumptions above are true, then here's my +1. Thanks On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote: > > I wasn't clear enough when starting this vote, let me try to fix that: > > I intended this vote to *be* the short term reality, I.e. about getting a > release out from trunk with everyone contributing. > > It may well be right that a single module version doesn't scale, in the > longer term maybe we need to adopt one the many proposals that has been > made > on this subject. We can revisit all this once we've managed to get the > next > release out. > > The specifics of what extensions are included in this release is left out > of > this vote and can be decided in the release plan discussion. All this vote > is saying is that all the modules that are to be included in this next > release will have the same version and that a top level pom.xml will exist > to enable building all those modules at once. We don't have so many > extensions planed for the next release so i think this will scale ok for > now. > > Does that help at all? Would anyone more vote for this now? > > If there isn't a reasonably large majority one way or the other I'm fine > with forgetting this vote and going back to the drawing board for a > different approach. I'd really prefer not to have to do that though as we > need to start finding some ways to make progress, so lets keep this going > till tomorrow to see how the votes look then. > > ...ant > > On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > Hi, Bert. > > > > I think I'm with you on the proposal. The rule of the game should be > very > > simple as follows: > > > > Let's agree on a set of modules that are supposed to work together for > the > > next target (a release or a demo), then define an assembly and pom.xmlto > > enforce the cohesions. > > > > Thanks, > > Raymond > > > > - Original Message - > > From: "Bert Lamb" < [EMAIL PROTECTED]> > > To: > > Sent: Wednesday, March 28, 2007 1:28 PM > > Subject: Re: [VOTE] Use single version for all Java/SCA modules and > enable > > building all modules together > > > > > > > Would something like what I outlined in this email[1] be more amenable > > > to people voting against this proposal? > > > > > > -Bert > > > > > > [1] > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html > > > > > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > >> I have expressed my views on all modules sharing the same version and > a > > >> top > > >> down build in quite a bit of detail in my previous emails on the same > > >> subject. Unfortunately, I will have to vote -1 on this. > > >> > > >> Meeraj > > >> > > >> > > >> >From: Jim Marino <[EMAIL PROTECTED]> > > >> >Reply-To: tuscany-dev@ws.apache.org > > >> >To: tuscany-dev@ws.apache.org > > >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules and > > >> >enable > > >> >building all modules together > > >> >Date: Wed, 28 Mar 2007 12:19:53 -0700 > > >> > > > >> > > > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote: > > >> > > > >> >>Here's the vote on this I said [1] I'd start to get closure on this > > >> >>issue. > > >> >> > > >> >>The proposal is to have top-level pom for the Java SCA project that > > >> >>enables > > >> >>building all the modules together - kernel, services, runtimes, > > >> >>extensions > > >> >>etc, and for that to work all those modules need to use the same > > >> >>version > > >> >>name. > > >> >> > > >> >>Here's my +1. > > >> >> > > >> >> ...ant > > >> >> > > >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > > >> >>msg16024.html > > >> > > > >> > > > >> > > > >> >There has been no proposal for how to resolve the issue > > about building > > >> >extensions using multiple versions of kernel and how modules on > > >> >different > > >> >release schedules requiring different levels of kernel or plugins > > will > > >> >be > > >> >handled. > > >> > > > >> >Until we can come up with a solution for these issues, I feel I > > have to > > >> >vote against the proposal. > > >> > > > >> >-1 > > >> > > > >> >Jim > > >> > > > >> > >- > > >> >To unsubscribe, e-mail: [EMAIL P
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
If I understand your clarification correctly, this vote is about putting out a single release with a certain number of modules in it, and with each module having the same version number. In particular, this vote does not set a cast-in-stone precedent about how future releases will be put together. Also, it is assumed that consensus will eventually be able to be reached about what the modules in the release will be (without this assumption, this vote seems pointless to me). While it is not clear to me that this is the best approach to follow from an open source project point of view, with the constraints and assump- tions above it seems to me to be reasonably safe to vote +1. So, if the constraints and assumptions above are true, then here's my +1. Thanks On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote: I wasn't clear enough when starting this vote, let me try to fix that: I intended this vote to *be* the short term reality, I.e. about getting a release out from trunk with everyone contributing. It may well be right that a single module version doesn't scale, in the longer term maybe we need to adopt one the many proposals that has been made on this subject. We can revisit all this once we've managed to get the next release out. The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. We don't have so many extensions planed for the next release so i think this will scale ok for now. Does that help at all? Would anyone more vote for this now? If there isn't a reasonably large majority one way or the other I'm fine with forgetting this vote and going back to the drawing board for a different approach. I'd really prefer not to have to do that though as we need to start finding some ways to make progress, so lets keep this going till tomorrow to see how the votes look then. ...ant On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, Bert. > > I think I'm with you on the proposal. The rule of the game should be very > simple as follows: > > Let's agree on a set of modules that are supposed to work together for the > next target (a release or a demo), then define an assembly and pom.xmlto > enforce the cohesions. > > Thanks, > Raymond > > - Original Message - > From: "Bert Lamb" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, March 28, 2007 1:28 PM > Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable > building all modules together > > > > Would something like what I outlined in this email[1] be more amenable > > to people voting against this proposal? > > > > -Bert > > > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html > > > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > >> I have expressed my views on all modules sharing the same version and a > >> top > >> down build in quite a bit of detail in my previous emails on the same > >> subject. Unfortunately, I will have to vote -1 on this. > >> > >> Meeraj > >> > >> > >> >From: Jim Marino <[EMAIL PROTECTED]> > >> >Reply-To: tuscany-dev@ws.apache.org > >> >To: tuscany-dev@ws.apache.org > >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules and > >> >enable > >> >building all modules together > >> >Date: Wed, 28 Mar 2007 12:19:53 -0700 > >> > > >> > > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote: > >> > > >> >>Here's the vote on this I said [1] I'd start to get closure on this > >> >>issue. > >> >> > >> >>The proposal is to have top-level pom for the Java SCA project that > >> >>enables > >> >>building all the modules together - kernel, services, runtimes, > >> >>extensions > >> >>etc, and for that to work all those modules need to use the same > >> >>version > >> >>name. > >> >> > >> >>Here's my +1. > >> >> > >> >> ...ant > >> >> > >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > >> >>msg16024.html > >> > > >> > > >> > > >> >There has been no proposal for how to resolve the issue > about building > >> >extensions using multiple versions of kernel and how modules on > >> >different > >> >release schedules requiring different levels of kernel or plugins > will > >> >be > >> >handled. > >> > > >> >Until we can come up with a solution for these issues, I feel I > have to > >> >vote against the proposal. > >> > > >> >-1 > >> > > >> >Jim > >> > > >> >- > >> >To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > >> _ > >> Match.com - Click Here To Find Singles In Your Area Today! > >> http://msnuk.match.com/ > >> > >> > >> ---
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
This vote makes much more sense to me know and sounds a bit like what I was trying to propose, so I'm all for it and it gets my non-binding vote :) +1 (non-binding) -Bert On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote: I wasn't clear enough when starting this vote, let me try to fix that: I intended this vote to *be* the short term reality, I.e. about getting a release out from trunk with everyone contributing. It may well be right that a single module version doesn't scale, in the longer term maybe we need to adopt one the many proposals that has been made on this subject. We can revisit all this once we've managed to get the next release out. The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. We don't have so many extensions planed for the next release so i think this will scale ok for now. Does that help at all? Would anyone more vote for this now? If there isn't a reasonably large majority one way or the other I'm fine with forgetting this vote and going back to the drawing board for a different approach. I'd really prefer not to have to do that though as we need to start finding some ways to make progress, so lets keep this going till tomorrow to see how the votes look then. ...ant On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, Bert. > > I think I'm with you on the proposal. The rule of the game should be very > simple as follows: > > Let's agree on a set of modules that are supposed to work together for the > next target (a release or a demo), then define an assembly and pom.xml to > enforce the cohesions. > > Thanks, > Raymond > > - Original Message - > From: "Bert Lamb" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, March 28, 2007 1:28 PM > Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable > building all modules together > > > > Would something like what I outlined in this email[1] be more amenable > > to people voting against this proposal? > > > > -Bert > > > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html > > > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > >> I have expressed my views on all modules sharing the same version and a > >> top > >> down build in quite a bit of detail in my previous emails on the same > >> subject. Unfortunately, I will have to vote -1 on this. > >> > >> Meeraj > >> > >> > >> >From: Jim Marino <[EMAIL PROTECTED]> > >> >Reply-To: tuscany-dev@ws.apache.org > >> >To: tuscany-dev@ws.apache.org > >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules and > >> >enable > >> >building all modules together > >> >Date: Wed, 28 Mar 2007 12:19:53 -0700 > >> > > >> > > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote: > >> > > >> >>Here's the vote on this I said [1] I'd start to get closure on this > >> >>issue. > >> >> > >> >>The proposal is to have top-level pom for the Java SCA project that > >> >>enables > >> >>building all the modules together - kernel, services, runtimes, > >> >>extensions > >> >>etc, and for that to work all those modules need to use the same > >> >>version > >> >>name. > >> >> > >> >>Here's my +1. > >> >> > >> >> ...ant > >> >> > >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > >> >>msg16024.html > >> > > >> > > >> > > >> >There has been no proposal for how to resolve the issue > about building > >> >extensions using multiple versions of kernel and how modules on > >> >different > >> >release schedules requiring different levels of kernel or plugins > will > >> >be > >> >handled. > >> > > >> >Until we can come up with a solution for these issues, I feel I > have to > >> >vote against the proposal. > >> > > >> >-1 > >> > > >> >Jim > >> > > >> >- > >> >To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > >> _ > >> Match.com - Click Here To Find Singles In Your Area Today! > >> http://msnuk.match.com/ > >> > >> > >> - > >> 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: [
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
I wasn't clear enough when starting this vote, let me try to fix that: I intended this vote to *be* the short term reality, I.e. about getting a release out from trunk with everyone contributing. It may well be right that a single module version doesn't scale, in the longer term maybe we need to adopt one the many proposals that has been made on this subject. We can revisit all this once we've managed to get the next release out. The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. We don't have so many extensions planed for the next release so i think this will scale ok for now. Does that help at all? Would anyone more vote for this now? If there isn't a reasonably large majority one way or the other I'm fine with forgetting this vote and going back to the drawing board for a different approach. I'd really prefer not to have to do that though as we need to start finding some ways to make progress, so lets keep this going till tomorrow to see how the votes look then. ...ant On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Bert. I think I'm with you on the proposal. The rule of the game should be very simple as follows: Let's agree on a set of modules that are supposed to work together for the next target (a release or a demo), then define an assembly and pom.xml to enforce the cohesions. Thanks, Raymond - Original Message - From: "Bert Lamb" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 28, 2007 1:28 PM Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together > Would something like what I outlined in this email[1] be more amenable > to people voting against this proposal? > > -Bert > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> I have expressed my views on all modules sharing the same version and a >> top >> down build in quite a bit of detail in my previous emails on the same >> subject. Unfortunately, I will have to vote -1 on this. >> >> Meeraj >> >> >> >From: Jim Marino <[EMAIL PROTECTED]> >> >Reply-To: tuscany-dev@ws.apache.org >> >To: tuscany-dev@ws.apache.org >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules and >> >enable >> >building all modules together >> >Date: Wed, 28 Mar 2007 12:19:53 -0700 >> > >> > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote: >> > >> >>Here's the vote on this I said [1] I'd start to get closure on this >> >>issue. >> >> >> >>The proposal is to have top-level pom for the Java SCA project that >> >>enables >> >>building all the modules together - kernel, services, runtimes, >> >>extensions >> >>etc, and for that to work all those modules need to use the same >> >>version >> >>name. >> >> >> >>Here's my +1. >> >> >> >> ...ant >> >> >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ >> >>msg16024.html >> > >> > >> > >> >There has been no proposal for how to resolve the issue about building >> >extensions using multiple versions of kernel and how modules on >> >different >> >release schedules requiring different levels of kernel or plugins will >> >be >> >handled. >> > >> >Until we can come up with a solution for these issues, I feel I have to >> >vote against the proposal. >> > >> >-1 >> > >> >Jim >> > >> >- >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> _ >> Match.com - Click Here To Find Singles In Your Area Today! >> http://msnuk.match.com/ >> >> >> - >> 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]
SPI reorg (was: Re: [Discussion] Tuscany kernel modulization
On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: One reason the SPI module is so large is that it does define many the interfaces for the components in you diagram. I think there is room for a reorganization there to clarify the usage of those interfaces. I would propose we start with that ... There have been several emails now which I think show some agreement that we can do some SPI refactoring. Here's something that could be a start of this work: One area is the extension SPI, on our architecture diagram [1] thats the "Extensions" box at the top right. In the past we've had a lot of problems with extensions continually getting broken as the SPIs keep changing. This has made maintaining extensions to be in a working state a big job and it has led to some donated extension just being abandoned. One of the reasons for this is that the SPIs more reflect the requirements of the Tuscany runtime than the requirements of the extension being contributed. For example, a container extension needs to enable creating, initializing, invoking and destroying a component, along with exposing the components services, references and properties. Those things have remained pretty constant even though the SCA specs and Tuscany runtime and SPI have undergone significant changes. I think we should be able to create SPIs for these type of functions which clearly represent the requirements of a particular extension type, and that doing this would go along way to making things more stable. All this code is there in the current SPI so its mainly just a mater of refactoring parts out into separate bits with clearly defined function and adding adapter code so the runtime can use them. You can even envisage that if this is successful it could define a runtime extension SPI for all the extensible areas of SCA assembly which could eventually be standardized to provide portable SCA extensions in a way similar to JBI. What do people think, is this worth looking at? If so I'd like to make an attempt at doing it for bindings and components using the Axis2 binding and script container as guinea pigs. This should be pretty transparent to the rest of the kernel as other than the adapter code it could all be separate modules. Comments? ...ant [1] http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions
[jira] Commented: (TUSCANY-1183) XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485134 ] Andy Grove commented on TUSCANY-1183: - Kelvin - yes, that was my intention. I'll be sure to add them in future. Thanks, Andy. > 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, XSDChoiceTest-1183b.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]
[jira] Commented: (TUSCANY-1191) Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485133 ] Andy Grove commented on TUSCANY-1191: - Kelvin - yes, that was my intention. Thanks. > Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and > Property > --- > > Key: TUSCANY-1191 > URL: https://issues.apache.org/jira/browse/TUSCANY-1191 > Project: Tuscany > Issue Type: Test > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: XMLWithoutSchemaTest.java, XMLWithoutSchemaTest.java > > > This test checks various compliance points relating to section 9.10 -- 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] Commented: (TUSCANY-1181) XSDSerializationTest is Tuscany-specific
[
https://issues.apache.org/jira/browse/TUSCANY-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485126
]
Kelvin Goodson commented on TUSCANY-1181:
-
Having trouble applying the patch. When I look at XSDHelperTest.java I get an
error dialog from Tortoise SVN to say the file "Has no URL" - can you
investigate please
> XSDSerializationTest is Tuscany-specific
>
>
> Key: TUSCANY-1181
> URL: https://issues.apache.org/jira/browse/TUSCANY-1181
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: Tuscany-1181.patch
>
>
> XSDSerializationTest contains assertions like the following that expect 2
> types to be created from simple.xsd, which just contains a single type called
> "Quote".
> assertEquals("XSDHelper.define() did not create the expected number of
> Types", 2, types.size());
> Presumably the current assertion is based on DocumentRoot being in the types
> list.
> It would be better to check that the "Quote" type is in the list rather than
> just checking the size of the list.
--
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] Resolved: (TUSCANY-1191) Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1191. - Resolution: Fixed Added new test case. I added an ASL license header to the test case, I'm sure you intended to do this but could you again for the record indicate that this was so please. > Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and > Property > --- > > Key: TUSCANY-1191 > URL: https://issues.apache.org/jira/browse/TUSCANY-1191 > Project: Tuscany > Issue Type: Test > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: XMLWithoutSchemaTest.java, XMLWithoutSchemaTest.java > > > This test checks various compliance points relating to section 9.10 -- 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] Commented: (TUSCANY-1183) XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485121 ] Kelvin Goodson commented on TUSCANY-1183: - Andy I realised I hadn't checked for license headers in the new files before committing, and when I looked back they weren't there. I have added them on the basis that you ticked the "grant license" button when attaching to the JIRA. I'm sure you intended to include the headers, but just for the record could you please indicate that this was so. > 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, XSDChoiceTest-1183b.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]
[jira] Resolved: (TUSCANY-1183) XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1183. - Resolution: Fixed Applied b version of zip file to add 2 new tests to CTS (BTW, a quick tip -- its clearer if you add the attachment with the same name as the one it replaces, since the JIRA system then greys out the original) > 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, XSDChoiceTest-1183b.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]
[jira] Resolved: (TUSCANY-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()
[ https://issues.apache.org/jira/browse/TUSCANY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1177. - Resolution: Fixed Applied patch that removes the expectation that SDO implementations should provide a DocumentRoot type > CTS should not expect DocumentRoot to be included in results from > XSDHelper.define() > > > Key: TUSCANY-1177 > URL: https://issues.apache.org/jira/browse/TUSCANY-1177 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: 1177.patch > > > DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML > documents without an XSD. All mentioned of DocumentRoot were removed from SDO > 2.1 and the CTS should not be expecting DocumentRoot to be returned by > XSDHelper.define(). -- 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] Resolved: (TUSCANY-1176) DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties
[ https://issues.apache.org/jira/browse/TUSCANY-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1176. - Resolution: Fixed Applied patch to remove expectation of visibility of EMF properties > DynamicTypesFromSchemaTestCase should not expect "mixed" and "text" properties > -- > > Key: TUSCANY-1176 > URL: https://issues.apache.org/jira/browse/TUSCANY-1176 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Reporter: Andy Grove > Attachments: 1176.patch > > > DynamicTypesFromSchemaTestCase currently fails if a call to > getInstanceProperties does not return "mixed" or "text" properties. I see no > mention of these properties in the SDO for Java 2.1 specification. The "text" > property was mentioned in SDO 2.0.1 but then removed for SDO 2.1. -- 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]
