Re: Build structure - having cake and still eating
Hi Jeremy For the assembly proposal, are you suggesting something like : https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/sca/distribution/tss-sample/ -- Luciano Resende http://people.apache.org/~lresende On 3/22/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Jeremy, Please take a look at axis2 poms and geronimo poms. you don't need to install the parent pom before building modules. you can specify relative path to the parent. -- dims On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: OK. If we're going to hold the vote, I'll pull the candidate artifacts. We can republish them later. That does mean that everyone will need to install the sca parent pom from the tag in SVN before any of the modules in trunk will build. -- Jeremy On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote: Jeremy, I'd like to see some progress on the community front! Let's see this approach agreed upon and fleshed out a bit more. thanks, dims On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: Jeremy. This sounds like a simpler approach than what is there now. I like the idea but a question. 1) move everything that does not logical depend on org.apache.tuscany:sca:1.0-incubating to contrib from your previous definition do you mean those things that are not considered to be independent. Or do you mean things that could be independent but just aren't packaged that way now. I assume that you mean the latter as your next point is to go ahead and make them independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. Also is the global parent version 1.0-incubating or 1.0-incubating- SNAPSHOT. I note that now you have it without SNAPSHOT but its children with SNAPSHOT. Are you just saying that the global parent doesn't get packaged/ released per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- 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] - 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: Maven info
Jeremy, thanks for the pointer; I printed that book out a while ago and have used it for getting a basic understanding of Maven, but what I tend to find is that the devil is in the detail, and the book doesn't go that deep. I've been frustrated recently by behaviour that doesn't seem to tally with what detailed documentation I have been able to find, Asking on the maven users' list has not produced any response -- http://mail-archives.apache.org/mod_mbox/maven-users/200703.mbox/[EMAIL PROTECTED] If anyone has any ideas on the problem I posed there I would be very grateful. Currently I document a manual step in the build process, as I have spent too much time getting nowhere. Regards, Kelvin. On 22/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: For those not really familiar with Maven there is a lot of good information in this book: http://www.mergere.com/m2book_download.jsp -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mule and Tuscany?
I just noticed this in a recent TSS article: Mule is talking with Tuscanyhttp://cwiki.apache.org/TUSCANY/project for an SCA implementation. [1]. Does anyone know more about that? If this is being considered it would be really helpful to bring it to the list and having the Mule guys participate in some of the on going modularity discussions. ...ant [1] http://www.theserverside.com/news/thread.tss?thread_id=44750
[jira] Updated: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec
[ https://issues.apache.org/jira/browse/TUSCANY-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Murray updated TUSCANY-578: - Attachment: 578.patch 578.zip I have attached a test case (contained in 578.zip) that verifies each of the explicitly identified Exceptions in the spec. I have also attached a patch for several of the issues that were identified using the test case. There were some issues identified that I do not think can be corrected in a manner with small enough of an impact given the nature of the correction being made. Those issues are: ** Altering read-only property through Sequence interface throws wrong Exception. Expected Behavior: UnsupportedOperationException is thrown Observed Behavior: RuntimeException Cause: In BasicFeatureMap, if (!eStructuralFeature.isChangeable()) a RuntimeException is thrown. Problem: That is EMF code. It is bad form to catch RuntimeException (somewhat analogous to catching Exception), so it would be unwise to try to catch this in SDO code simply to throw UnsupportedOperationException. ** Expected Exceptions from the List interface. Expected Behavior: (e.g. List.get(-1) should throw an IndexOutOfBoundsException) Observed Behavior: (e.g. List.get(-1) throws NullPointerException, in some cases) Note: Similar statements hold for using the List interface to alter a read-only Property Problem: The List method calls fall directly into the EMF List implementations. There is not an SDO layer with which we could try to catch various Exceptions and throw the one indicated in our spec. ** DataObject.get(property) with an invalid property does not throw the appropriate Exception in the static case. Note: This test case is done using property1 from type1, and dataObject2 of type2. Calling dataObject2.get(property1) should throw the appropriate Exception, and does so in the dynamic cases. Expected Behavior: IllegalArgumentException is thrown Observed Behavior: No Exception is thrown. Instead, the get() is performed using the Property index (index in the other type) of the invalid property. The property in type2 (the DataObject) that happens to have the same index value as property1 in type1 is not meaningful, but that is what is used. Cause: eDerivedStructuralFeatureID(eFeature) should return -1 and does so in the dynamic case. However in the static case this method is handled by BasicEObjectImpl., which determines the containingClass but never uses it in any way. The containingClass should be used to determine that the property is not valid for that class. Problem: This is EMF code. Please let me know your thoughts on the outstanding issues. If you agree that they cannot be reasonably corrected, and you agree that the test case covers the complete set of explicitly identified Exceptions then please mark the Jira fixed. Exceptions thrown by SDO runtime not the same as defined in the spec Key: TUSCANY-578 URL: https://issues.apache.org/jira/browse/TUSCANY-578 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Brian Murray Priority: Minor Fix For: Java-SDO-Mx Attachments: 578.patch, 578.zip, DataObjectUtil.patch On page 27 of V2.01 of the spec, specific exceptions are listed for certain kinds of errors. In some cases, a different exception is thrown (each case will be added as a subtask). Either the specification or the implementation should be updated. -- 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]
Language independent interface definition work
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
Re: Planning kernel release 2.0
On Mar 23, 2007, at 3:29 AM, ant elder wrote: On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: snip/ I don't think the SPI is quite as stable as Dave would like but we should be able to improve things after alpha2. I think we should target an SPI freeze for the beta (June you were suggesting), at least for incompatible changes. To do that we need to have built a couple of bindings/containers on top of it. I definitely agree we need to get the SPI more stable and that having more containers and bindings using it will help a lot. I'd like help with this and to add the Axis2 binding and jsr-223 script container to the list of extensions already mentioned for this release, i've already started work fixing these for the latest trunk code. I'd also like to add the modularity stuff been discussed on other threads to the content of this release. With the current state of the trunk and spi and all the extensions needing work to get going again this seems like the perfect time to get the trunk code to a state that everyone is happy using. ...ant IMO having scripting support is an important thing. At the ServerSide, one of the things that people liked was the idea of multiple language support and having Groovy and Javascript is a nice differentiator. One distinction I would make though is what we are talking about is a kernel release while extensions would be released separately. As part of the extension releases, if people wanted, there could be distributions that package required extensions for various scripting runtimes. The kernel release would be highly modular and its distributions would include the extensions required for particular host environments. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mule and Tuscany?
On Mar 23, 2007, at 5:17 AM, ant elder wrote: I just noticed this in a recent TSS article: Mule is talking with Tuscanyhttp://cwiki.apache.org/TUSCANY/project for an SCA implementation. [1]. Does anyone know more about that? If this is being considered it would be really helpful to bring it to the list and having the Mule guys participate in some of the on going modularity discussions. ...ant [1] http://www.theserverside.com/news/thread.tss?thread_id=44750 I ran into Ross Mason briefly at ServerSide but we have not yet had the chance to talk in any depth. Basically the conversation was we should figure a way to work together. Of course, we would do this on the list :-) Fortunately, Meeraj is an active user of Mule as well. Meeraj can probably speak more to this, but based on past discussions, I believe some of what is driving his modularity goals has been shaped by experiences using frameworks/infrastructure such as Mule and Spring. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
C++ questions from the ServerSide
Someone inquired about the C++ questions at the ServerSide and I wanted to respond but can't remember where it was originally stated due to the avalanche of emails to the list. Someone specifically asked about the C++ programming model and if it was going to incorporate some of the same design patterns such as dependency injection. I started with the usual disclaimer that I have not been tracking the C++ spec closely but my understanding was many of the Java features would also make their way into the C++ spec, but in the form natural to the language itself. I added I believe scopes would also be incorporated. My impression based on the question and the context in which it was raised, was that people were interested in having C++ support as part a federated architecture. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote: Hi Jeremy For the assembly proposal, are you suggesting something like : https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ sca/distribution/tss-sample/ Something like that, yeah. You want to rely on things that are as stable as possible, preferably things that have been released. I would not have included pom/parent and buildtools as those are available from the release repo. Generally you want to include as few unstable dependencies as possible. Also, I noticed you have a assembly descriptor in your project but you also include distribution/sca/demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: requires and policySets attribute support
When processing the intents at each level and putting them into the model. Would it be a better idea to push them the whole way down to the operation model object or to leave them at the various levels in the model and have the merge of the intents performed later? Jean-Sebastien Delfino wrote: Mark I. Dinges wrote: I was going to start working on the annotation processing for @Requires. Has anyone started working on it yet? Looking at the current processing of the DataType annotation, it looks like we want to create a PolicyJavaInterfaceProcessor class and register it with the JavaInterfaceProcessorRegistryImpl. This way it will be call during the introspection of the Java implementation. PolicyJavaInterfaceProcessor would handle the @Requires and @PolicySets annotations. Initial implementation will only handle the @Requires. Any suggestions, comments, or recommendations? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I don't think that anyone has started to work on this, so Thanks for volunteering :) What you describe sounds good to me. I suggest to implement this in a self contained policy annotation support module as it'll make it easier to integrate. You may want to check the Intent class as I'm not sure it's in sync yet with the SCA 1.0 spec. You'll need to handle both interfaces and implementation classes, which both can have @Requires. I would expect @Requires on a Java implementation class and its interfaces to translate to Intent metadata in the ComponentType model describing the implementation. A Java interface can also be specified in a service or reference for a particular component (independent of the implementation class and the interfaces it implements). You may have to handle that too and translate @Requires to Intent metadata in the Component model describing the particular component (somehow refining the Intents specified on the implementation). This is something to investigate as I couldn't find a clear description of the behavior in this case in the SCA Java CI spec. Let us know if you run into any issues or questions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ questions from the ServerSide
On 3/23/07, Jim Marino [EMAIL PROTECTED] wrote:
Someone inquired about the C++ questions at the ServerSide and I
wanted to respond but can't remember where it was originally stated
due to the avalanche of emails to the list. Someone specifically
asked about the C++ programming model and if it was going to
incorporate some of the same design patterns such as dependency
injection. I started with the usual disclaimer that I have not been
tracking the C++ spec closely but my understanding was many of the
Java features would also make their way into the C++ spec, but in the
form natural to the language itself. I added I believe scopes would
also be incorporated.
My impression based on the question and the context in which it was
raised, was that people were interested in having C++ support as part
a federated architecture.
Jim
Hi Jim,
Your statement sounds about right to me - the C++ spec mostly follows
the Java spec aside from where language specifics don't make sense, or
an alternative would be more natural. So you'll see many classes that
have the same names, methods etc in the C++ and Java specs, but some
things that are hard to do in C++ (like injection) are not (currently)
included. The spec does include scopes (stateless, request,
conversation, and composite) which (I think) mirror those in the Java
spec.
I believe the Client API differs slightly between C++ and Java, but
mostly things are the same. We even do annotations! (via C++ comments
that would need preprocessing/code generation) e.g:
// @scope(composite)
class LoanServiceImpl : public LoanService {
In Tuscany, the Native runtime does not match the 1.0 spec in lots of
aspects at the moment - the spec added quite a lot of function between
0.95 (where Tuscany Native is currently at) and 1.0. C++ support as
part of the Tuscany federated architecture would (IMO) be a cool thing
I think I remember someone saying they took a look at the C++ JXTA
implementation, but I'm not sure who that was..
HTH
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-917) XMLHelper.load() should demand-create global properties not defined in the SDO type system
[ https://issues.apache.org/jira/browse/TUSCANY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-917: --- Patch Info: [Patch Available] looking at Fuhwei's attached test case XMLHelper.load() should demand-create global properties not defined in the SDO type system -- Key: TUSCANY-917 URL: https://issues.apache.org/jira/browse/TUSCANY-917 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: 917-testcase.patch Currently, when you invoke XMLHelper.save(), it would serialize the non-defined global properties. However, the doc cannot be deserialized by XMLHelper.load() method. -- 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-917) XMLHelper.load() should demand-create global properties not defined in the SDO type system
[ https://issues.apache.org/jira/browse/TUSCANY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483622 ] Kelvin Goodson commented on TUSCANY-917: I can not apply the attached patch. It gives the error The chunk size did not match the number of added/removed lines! Can you investigate please? XMLHelper.load() should demand-create global properties not defined in the SDO type system -- Key: TUSCANY-917 URL: https://issues.apache.org/jira/browse/TUSCANY-917 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: 917-testcase.patch Currently, when you invoke XMLHelper.save(), it would serialize the non-defined global properties. However, the doc cannot be deserialized by XMLHelper.load() method. -- 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-917) XMLHelper.load() should demand-create global properties not defined in the SDO type system
[ https://issues.apache.org/jira/browse/TUSCANY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-917: --- Attachment: 917-testcase.patch Uploaded a new one. Try it. XMLHelper.load() should demand-create global properties not defined in the SDO type system -- Key: TUSCANY-917 URL: https://issues.apache.org/jira/browse/TUSCANY-917 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: 917-testcase.patch, 917-testcase.patch Currently, when you invoke XMLHelper.save(), it would serialize the non-defined global properties. However, the doc cannot be deserialized by XMLHelper.load() method. -- 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-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 ] Andy Grove updated TUSCANY-1191: Attachment: XMLWithoutSchemaTest.java 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 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] Created: (TUSCANY-1192) Preserve demand created global properties
Preserve demand created global properties - Key: TUSCANY-1192 URL: https://issues.apache.org/jira/browse/TUSCANY-1192 Project: Tuscany Issue Type: New Feature Affects Versions: Java-SDO-M3 Reporter: Kelvin Goodson Fix For: Java-SDO-Mx TUSCANY-917 addressed the issue of demand creating global properties when needed for an xmlHelper.load operation, but the property is ephemeral and is therefore not available for use after the load operation. This JIRA is opened to alter behaviour such that the demand created property is available in the applications metadata after the load operation. -- 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-1192) Preserve demand created global properties
[ https://issues.apache.org/jira/browse/TUSCANY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1192: Component/s: Java SDO Implementation Preserve demand created global properties - Key: TUSCANY-1192 URL: https://issues.apache.org/jira/browse/TUSCANY-1192 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Kelvin Goodson Fix For: Java-SDO-Mx TUSCANY-917 addressed the issue of demand creating global properties when needed for an xmlHelper.load operation, but the property is ephemeral and is therefore not available for use after the load operation. This JIRA is opened to alter behaviour such that the demand created property is available in the applications metadata after the load operation. -- 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-917) XMLHelper.load() should demand-create global properties not defined in the SDO type system
[ https://issues.apache.org/jira/browse/TUSCANY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-917. Resolution: Duplicate Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 The fix for TUSCANY-1082 seems to have resolved this. I have opened TUSCANY-1192 to address the issue of the preservation of the demand created property after the load operation. XMLHelper.load() should demand-create global properties not defined in the SDO type system -- Key: TUSCANY-917 URL: https://issues.apache.org/jira/browse/TUSCANY-917 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: 917-testcase.patch, 917-testcase.patch Currently, when you invoke XMLHelper.save(), it would serialize the non-defined global properties. However, the doc cannot be deserialized by XMLHelper.load() method. -- 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: Maven info
Hi, I just run mvn package assembly:assembly under sdo and it includes the following JARs. I use maven 2.0.5. 0 Fri Mar 23 08:54:04 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ 111085 Fri Mar 23 08:54:04 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/tusca ny-sdo-tools-1.0-incubator-SNAPSHOT.jar 409457 Fri Mar 23 08:54:02 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/tusca ny-sdo-impl-1.0-incubator-SNAPSHOT.jar 191999 Fri Mar 09 10:22:40 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/codeg en-2.2.2.jar 70701 Fri Mar 09 10:22:32 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -change-2.2.2.jar 750098 Fri Mar 09 10:22:30 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -2.2.2.jar 773884 Fri Mar 09 10:22:46 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/codeg en-ecore-2.2.2.jar 703630 Fri Mar 09 10:22:20 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/xsd-2 .2.2.jar 156396 Fri Mar 09 10:22:24 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/commo n-2.2.2.jar 170628 Fri Mar 09 10:22:12 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -xmi-2.2.2.jar 32872 Fri Mar 09 10:22:22 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/sdo-a pi-r2.1-1.0-incubator-20070309.181303-3.jar I don't see asm stuff at all. The only thing wierd is that the sdo-api-r2.1 is timestamped. BTW, asm 3.0 is available now, you might to upgrade to it from 3.0-RC1. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, March 23, 2007 2:32 AM Subject: Re: Maven info Jeremy, thanks for the pointer; I printed that book out a while ago and have used it for getting a basic understanding of Maven, but what I tend to find is that the devil is in the detail, and the book doesn't go that deep. I've been frustrated recently by behaviour that doesn't seem to tally with what detailed documentation I have been able to find, Asking on the maven users' list has not produced any response -- http://mail-archives.apache.org/mod_mbox/maven-users/200703.mbox/[EMAIL PROTECTED] If anyone has any ideas on the problem I posed there I would be very grateful. Currently I document a manual step in the build process, as I have spent too much time getting nowhere. Regards, Kelvin. On 22/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: For those not really familiar with Maven there is a lot of good information in this book: http://www.mergere.com/m2book_download.jsp -- Jeremy - 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: requires and policySets attribute support
Mark I. Dinges wrote: When processing the intents at each level and putting them into the model. Would it be a better idea to push them the whole way down to the operation model object or to leave them at the various levels in the model and have the merge of the intents performed later? Jean-Sebastien Delfino wrote: Mark I. Dinges wrote: I was going to start working on the annotation processing for @Requires. Has anyone started working on it yet? Looking at the current processing of the DataType annotation, it looks like we want to create a PolicyJavaInterfaceProcessor class and register it with the JavaInterfaceProcessorRegistryImpl. This way it will be call during the introspection of the Java implementation. PolicyJavaInterfaceProcessor would handle the @Requires and @PolicySets annotations. Initial implementation will only handle the @Requires. Any suggestions, comments, or recommendations? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I don't think that anyone has started to work on this, so Thanks for volunteering :) What you describe sounds good to me. I suggest to implement this in a self contained policy annotation support module as it'll make it easier to integrate. You may want to check the Intent class as I'm not sure it's in sync yet with the SCA 1.0 spec. You'll need to handle both interfaces and implementation classes, which both can have @Requires. I would expect @Requires on a Java implementation class and its interfaces to translate to Intent metadata in the ComponentType model describing the implementation. A Java interface can also be specified in a service or reference for a particular component (independent of the implementation class and the interfaces it implements). You may have to handle that too and translate @Requires to Intent metadata in the Component model describing the particular component (somehow refining the Intents specified on the implementation). This is something to investigate as I couldn't find a clear description of the behavior in this case in the SCA Java CI spec. Let us know if you run into any issues or questions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Mark, I would suggest to start with a model as an accurate representation of the input assembly (without pushing intents down to the operation level, and also without trying to reconcile intents at the constrainingType, componentType, implementation, component, composite level), and defer the determination of the intents at each concrete operation level to a later point, to the runtime build phase for example. This will avoid duplication of the intent info at each level and will give you the ability to determine the actual intents with all the info from the various places (the 5 levels I listed above) in hand, later. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven info
I see the same thing as Raymond (except for the timestamped api), What maven release you are using ? I believe Raymond and I are using maven-2.0.5. -- Luciano Resende http://people.apache.org/~lresende On 3/23/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I just run mvn package assembly:assembly under sdo and it includes the following JARs. I use maven 2.0.5. 0 Fri Mar 23 08:54:04 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT /lib/ 111085 Fri Mar 23 08:54:04 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/tusca ny-sdo-tools-1.0-incubator-SNAPSHOT.jar 409457 Fri Mar 23 08:54:02 PDT 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/tusca ny-sdo-impl-1.0-incubator-SNAPSHOT.jar 191999 Fri Mar 09 10:22:40 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/codeg en-2.2.2.jar 70701 Fri Mar 09 10:22:32 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -change-2.2.2.jar 750098 Fri Mar 09 10:22:30 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -2.2.2.jar 773884 Fri Mar 09 10:22:46 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/codeg en-ecore-2.2.2.jar 703630 Fri Mar 09 10:22:20 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/xsd-2 .2.2.jar 156396 Fri Mar 09 10:22:24 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/commo n-2.2.2.jar 170628 Fri Mar 09 10:22:12 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/ecore -xmi-2.2.2.jar 32872 Fri Mar 09 10:22:22 PST 2007 tuscany-sdo-1.0-incubator-SNAPSHOT/lib/sdo-a pi-r2.1-1.0-incubator-20070309.181303-3.jar I don't see asm stuff at all. The only thing wierd is that the sdo-api-r2.1 is timestamped. BTW, asm 3.0 is available now, you might to upgrade to it from 3.0-RC1. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, March 23, 2007 2:32 AM Subject: Re: Maven info Jeremy, thanks for the pointer; I printed that book out a while ago and have used it for getting a basic understanding of Maven, but what I tend to find is that the devil is in the detail, and the book doesn't go that deep. I've been frustrated recently by behaviour that doesn't seem to tally with what detailed documentation I have been able to find, Asking on the maven users' list has not produced any response -- http://mail-archives.apache.org/mod_mbox/maven-users/200703.mbox/[EMAIL PROTECTED] If anyone has any ideas on the problem I posed there I would be very grateful. Currently I document a manual step in the build process, as I have spent too much time getting nowhere. Regards, Kelvin. On 22/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: For those not really familiar with Maven there is a lot of good information in this book: http://www.mergere.com/m2book_download.jsp -- Jeremy - 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
I'm looking into revising samples. On 3/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Looking back at the samples, it's clear they haven't been significantly revisited since M2 at the 2.0.1 level. It's going to take a little time to put these straight. They have also been affected by generator template bugs which are now being fixed, so this will sort the issues that Yang pointed out. Regards, Kelvin. On 20/03/07, Yang ZHONG [EMAIL PROTECTED] wrote: Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] 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/ 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. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG -- Yang ZHONG
[jira] Resolved: (TUSCANY-901) jar Manifests require Application-Vendor-Id
[ https://issues.apache.org/jira/browse/TUSCANY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-901. Resolution: Fixed Fixed in revision 521832 jar Manifests require Application-Vendor-Id --- Key: TUSCANY-901 URL: https://issues.apache.org/jira/browse/TUSCANY-901 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-M3 The mailing list thread here http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that our jar manifest files should have this field -- 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-901) jar Manifests require Implementation-Vendor-Id
[ https://issues.apache.org/jira/browse/TUSCANY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-901: --- Summary: jar Manifests require Implementation-Vendor-Id (was: jar Manifests require Application-Vendor-Id) Fixed JIRA title, comment on last release was absence of Implementation-Vendor-Id not Application-Vendor-Id jar Manifests require Implementation-Vendor-Id -- Key: TUSCANY-901 URL: https://issues.apache.org/jira/browse/TUSCANY-901 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-M3 The mailing list thread here http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that our jar manifest files should have this field -- 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-1193) unable to create data objects from dynamic metadata that match data objects created from XSD metadata
unable to create data objects from dynamic metadata that match data objects created from XSD metadata - Key: TUSCANY-1193 URL: https://issues.apache.org/jira/browse/TUSCANY-1193 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-M2 I have been unable to create data objects using dynamic metadata with the same information content as data objects created from XSD metadata. The problem is apparent for XSD elements that have maxOccurs greater than one when the element has repeated values. Frank Budinsky responded to my posting on tuscany-dev with this statement: It seems that the dynamic API is creating properties with EMF's EStructuralFeature.isUnique == true, while XSDEcoreBuilder sets it to false. I guess we should always set it to false (for DataTypes), to be consistent. I believe that both should be false for consistency and so that data objects can accurately represent the content of XML files. I will attach a test case that demonstrates the problem and can verify its correction. -- 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-1193) unable to create data objects from dynamic metadata that match data objects created from XSD metadata
[ https://issues.apache.org/jira/browse/TUSCANY-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1193: - Attachment: DynamicTypesComparisonTestCase.jar This jar is intended to be extracted from the Tuscany\java directory. The content is a test case for demonstrating the problem or verifying its correction. unable to create data objects from dynamic metadata that match data objects created from XSD metadata - Key: TUSCANY-1193 URL: https://issues.apache.org/jira/browse/TUSCANY-1193 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-M2 Attachments: DynamicTypesComparisonTestCase.jar I have been unable to create data objects using dynamic metadata with the same information content as data objects created from XSD metadata. The problem is apparent for XSD elements that have maxOccurs greater than one when the element has repeated values. Frank Budinsky responded to my posting on tuscany-dev with this statement: It seems that the dynamic API is creating properties with EMF's EStructuralFeature.isUnique == true, while XSDEcoreBuilder sets it to false. I guess we should always set it to false (for DataTypes), to be consistent. I believe that both should be false for consistency and so that data objects can accurately represent the content of XML files. I will attach a test case that demonstrates the problem and can verify its correction. -- 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]
SDO: Agree on XSD for CTS?
I'd like to get some agreement on/review of the XSD we're using for the CTS. There have been a few instances where we thought there was a problem only to find that the CTS was invalid/incorrect in some way. (Or was unnecessarily complicated.) Below is the XSD I'm proposing. Please let me know if you'd like to see any changes. (Please do give some thought to additions you'd like to see. Are there areas that you think could not be hit given this XSD?) Note that this is slightly different than the XSD currently in the CTS and will require some updating of the CTS test cases. (For example, the test for the presence of a baseType is currently done on the same Type for which many Sequence tests are done. You can see in the XSD below that these have been separated.) I will make the corresponding changes when I introduce the XSD changes. Thank you, Brian -- ?xml version=1.0 encoding=UTF-8? !-- * Copyright (c) 2005-2006 The Apache Software Foundation or its licensors, as applicable. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. -- xsd:schema xmlns:sdo=commonj.sdo xmlns:api= http://www.example.com/api_test; xmlns:xsd=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.com/api_test; xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/ xsd:element name=apiTestElem type=api:APITest/ xsd:complexType mixed=false name=APITest xsd:sequence xsd:element name=stringVal type=xsd:string/ xsd:element name=booleanVal type=xsd:boolean/ xsd:element name=booleanVal2 type=xsd:boolean/ xsd:element name=byteVal type=xsd:byte/ xsd:element name=stringVal2 type=xsd:string/ xsd:element name=decimalVal type=xsd:decimal/ xsd:element name=decimalVal2 sdo:aliasName=dec2 type=xsd:decimal/ xsd:element name=intVal type=xsd:int/ xsd:element name=floatVal type=xsd:float/ xsd:element name=doubleVal type=xsd:double/ xsd:element name=dateVal type=xsd:dateTime/ xsd:element name=shortVal type=xsd:short/ xsd:element name=longVal type=xsd:long/ xsd:element maxOccurs=unbounded minOccurs=0 name=children type=api:APITest/ xsd:element name=bytesVal type=xsd:hexBinary/ xsd:element name=integerVal type=xsd:integer/ xsd:element name=charVal type=api:char/ xsd:element name=sequencedElem type=api:Sequenced/ xsd:element name=extendedElem type=api:Extended/ /xsd:sequence /xsd:complexType xsd:complexType name=Sequenced mixed=true xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Numbers type=xsd:int/ xsd:element maxOccurs=unbounded minOccurs=0 name=Letters type=xsd:string/ /xsd:sequence /xsd:complexType xsd:simpleType name=char xsd:restriction base=xsd:string xsd:length value=1/ /xsd:restriction /xsd:simpleType xsd:complexType abstract=true name=Abstract xsd:sequence xsd:element name=firstName type=xsd:string/ xsd:element name=lastName type=xsd:string/ /xsd:sequence /xsd:complexType xsd:complexType name=Extended sdo:aliasName=Ext2 xsd:complexContent xsd:extension base=api:Abstract xsd:sequence xsd:element name=nickName type=xsd:string/ xsd:element name=middleName type=xsd:string/ /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema
Re: SDO: Agree on XSD for CTS?
Looks like a good start to me. The mixed=false attribute isn't needed since it's the default. Frank. Brian Murray [EMAIL PROTECTED] 03/23/2007 03:03 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject SDO: Agree on XSD for CTS? I'd like to get some agreement on/review of the XSD we're using for the CTS. There have been a few instances where we thought there was a problem only to find that the CTS was invalid/incorrect in some way. (Or was unnecessarily complicated.) Below is the XSD I'm proposing. Please let me know if you'd like to see any changes. (Please do give some thought to additions you'd like to see. Are there areas that you think could not be hit given this XSD?) Note that this is slightly different than the XSD currently in the CTS and will require some updating of the CTS test cases. (For example, the test for the presence of a baseType is currently done on the same Type for which many Sequence tests are done. You can see in the XSD below that these have been separated.) I will make the corresponding changes when I introduce the XSD changes. Thank you, Brian -- ?xml version=1.0 encoding=UTF-8? !-- * Copyright (c) 2005-2006 The Apache Software Foundation or its licensors, as applicable. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. -- xsd:schema xmlns:sdo=commonj.sdo xmlns:api= http://www.example.com/api_test; xmlns:xsd= http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.com/api_test; xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/ xsd:element name=apiTestElem type=api:APITest/ xsd:complexType mixed=false name=APITest xsd:sequence xsd:element name=stringVal type=xsd:string/ xsd:element name=booleanVal type=xsd:boolean/ xsd:element name=booleanVal2 type=xsd:boolean/ xsd:element name=byteVal type=xsd:byte/ xsd:element name=stringVal2 type=xsd:string/ xsd:element name=decimalVal type=xsd:decimal/ xsd:element name=decimalVal2 sdo:aliasName=dec2 type=xsd:decimal/ xsd:element name=intVal type=xsd:int/ xsd:element name=floatVal type=xsd:float/ xsd:element name=doubleVal type=xsd:double/ xsd:element name=dateVal type=xsd:dateTime/ xsd:element name=shortVal type=xsd:short/ xsd:element name=longVal type=xsd:long/ xsd:element maxOccurs=unbounded minOccurs=0 name=children type=api:APITest/ xsd:element name=bytesVal type=xsd:hexBinary/ xsd:element name=integerVal type=xsd:integer/ xsd:element name=charVal type=api:char/ xsd:element name=sequencedElem type=api:Sequenced/ xsd:element name=extendedElem type=api:Extended/ /xsd:sequence /xsd:complexType xsd:complexType name=Sequenced mixed=true xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Numbers type=xsd:int/ xsd:element maxOccurs=unbounded minOccurs=0 name=Letters type=xsd:string/ /xsd:sequence /xsd:complexType xsd:simpleType name=char xsd:restriction base=xsd:string xsd:length value=1/ /xsd:restriction /xsd:simpleType xsd:complexType abstract=true name=Abstract xsd:sequence xsd:element name=firstName type=xsd:string/ xsd:element name=lastName type=xsd:string/ /xsd:sequence /xsd:complexType xsd:complexType name=Extended sdo:aliasName=Ext2 xsd:complexContent xsd:extension base=api:Abstract xsd:sequence xsd:element name=nickName type=xsd:string/ xsd:element name=middleName type=xsd:string/ /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should XMLHelper support DataGraph and how
Yang, XMLHelper doesn't need to support saving and loading DataGraph at this point. In the future, we are going to replace the implementation of DataGraph to one that is a DataObject, so then it will serialize without any special code. That's the direction the SDO spec is going on this issue. Frank. Yang ZHONG [EMAIL PROTECTED] 03/23/2007 03:55 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Should XMLHelper support DataGraph and how 2-1. Should XMLHelper support both saving and loading DataGraph? Spec 2.1 page 11 (2 Architecture) says Data graphs can be serialized to XML, typically by the XMLHelper or by an XML DAS. It may imply XMLHelper should support saving DataGraph. At the same time, spec 2.1 page 45 (3.11 XMLHelper) says An XMLHelper converts XML streams to and from graphs of DataObjects. There might be readers intepreting that XMLHelper should support loading DataGraph. 2-2. How to support DataGraph if XMLHelper should? Currently, we use SDOXMLResourceImpl to save/load DataObject and DataGraphResourceFactoryImpl.DataGraphResourceImpl to save/load DataGraph. It's trivial for XMLHelper to pick a ResourceImpl to save corresponding to input object. However, it's not trivial for XMLHelper to pick a ResourceImpl to load corresponding to input stream. I have 2 solutions; let me know your preference; alternatives will be appreciated. 2-2.1. Merge DataGraphResourceImpl capability into SDOXMLResourceImpl It takes longer to implement. However, we can eliminate DataGraphResourceFactoryImpl afterwards. 2-2.2. Parse stream portion and use corresponding ResourceImpl It takes shorter to implement. However, the solution isn't trivial since stream may not support reset, where the parsed portion has to be recorded and played back. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Do annotations on interfaces or superclasses play a role for SCA Java CI?
Hi,
If I have component implementation class like this:
Case 1:
public class MyServiceImpl implements MyService {
private YourService yourService;
public void setYourService(YourService yourService) {
this.yourService = yourService;
}
}
public interface MyService {
@Reference
void setYourService(YourService yourService);
}
Q1: Should yourService be treated as a reference?
Case 2:
public class MyServiceImpl extends MyServiceBaseImpl {
public void setYourService(YourService yourService) {
super.setYourService(yourService);
// Do addtional things here
}
}
public class MyServiceBaseImpl {
protected YourService yourService;
@Reference
public void setYourService(YourService yourService) {
this.yourService = yourService;
}
}
Q2: Should yourService be treated as a reference?
Am I crazy?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I did was
just finding the error and patching it, so I just modified a line of
code and got to know that the problem was not on the dissemination of
messages by JXTA but on the peer name being used to dispatch the name
to.
So, I saw that the problem was that the sender of the message was trying
to send a msg to a peer called slave (as seeing in the following
exception that was being displayed on the browser after pressing the
Contribute SCDL button):
org.apache.tuscany.spi.services.discovery.DiscoveryException:
Unrecognized runtime slave
What I did was just commenting a line of code out and hardcoding the
name of the runtime in the JxtaDiscoveryService class (when the runtime
is registering itself):
/**
* Configures the platform.
*
*/
private void configure() throws DiscoveryException {
try {
//String runtimeId = getRuntimeInfo().getRuntimeId();
String runtimeId = slave;
configurator.setName(runtimeId);
configurator.setHome(new File(runtimeId));
if (configurator.exists()) {
File pc = new File(configurator.getHome(),
PlatformConfig);
configurator.load(pc.toURI());
configurator.save();
} else {
configurator.save();
}
} catch (IOException ex) {
throw new DiscoveryException(ex);
} catch (CertificateException ex) {
throw new DiscoveryException(ex);
}
}
After doing that, the SCDL was successfully processed.
So, as you can see, the problem was not completely solved (the runtimeId
is hardcoded). But, at least I found why the messages were not being
delivered.
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 12:39 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
Mario,
I will try to be as detailed as I can, if you need further info, pls
ask.
Tuscany code structure is roughly organized into kernel, runtime,
services
and extensions. There are other modules like plugins, console etc, which
are
not relavant in the context of this discussion. There is also a contrib
module, where we keep artifacts that are not ready to go, it is
important in
the context of this discussion because the JXTA impl is currently in
contrib, because of some issues we are investigating with some patented
code
with BouncyCastle.
tuscany-spi in kernel, contains the key model classes and service
provider
interfaces for Tuscany. Some of these are implemented by core in kernel
and
some of them are implemented outside kernel. DiscoveryService is an SPI
defined in tuscany-spi that is used by the runtime fabric for enabling
communication between multiple profiles participating in a logical SCA
domain. A profile is basically a group of services, both system and
user,
that are managed together. Multiple profiles make up a logical SCA
domain.
You can run profiles in the same VM or different VMs.
Discovery service provides basically one method,
1. Targeted delivery of a message to a given profile.
However, the JXTA impl, also provides a listener for receiving those
messages and so does the JMS impl. JMS is not a real option for us, as
long
term we want to enable multi-fabric profiles in the same domain, Java
and
C++ for example. This is where JXTA fits in nicely.
Profile names are important, as the JXTA implementation of the discovery
service uses the profile names as logical endpoints and use them to map
to
JXTA peer ids. The JXTA implementation uses a peer group specific to the
domain in which the profile is participating. The domain name is defined
in
/etc/runtime.properties of the profile. We do that to restrict
communication
between the profiles only in the same domain. We use PDP (Peer Discovery
Protocol), for maintaining a view of all profiles available in the
domain
and PRP (Peer Rsolver Protocol) for sending directed messages. PDP
Re: Build structure - having cake and still eating
Jeremy So, having these assemblies modules sounded interesting to me until the moment you said you want to base them on deployed artifacts... we have never had a habit of publishing SNAPSHOTS for all possible artifacts, and even the members of the community that are proposing this approach are failing to deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this. You also mentioned before that we have M2 experience of a top down build not working, I'm not sure about all the details that comes to your mind when you say that, but I remember some build brakes (and I think this is acceptable in trunk, right ?) and we could set some conventions like, modules that are unstable at the moment would be removed from the maven profile (and maybe a JIRA would be created)... later on, when the module is back to it's stability, whoever fixed the issue would close the JIRA (if any) and put the module back to the stable profile. Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure both can co-exist together in perfect harmony, and it would definitely be a good solution for members of the community that are interested only in a subset of Tuscany (e.g some embedder that only requires the kernel, and a Spring extension for example), and these assembly modules could be created as needed These profiles would probably make the user experience of someone that comes to evaluate Tuscany trunk much easier, as already mentioned by Mario [1], and help others to be more productive as already expressed on various other threads [2][3]. If I understand your concerns, having the convention of moving unstable modules out of the maven profile should help, but maybe you could explain what worries you, that you are fighting so hard not to allow people to build different modules with a simple mvn command. Nevertheless, it's good practice to build before committ, right ? [1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15894.html [2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html [3] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15303.html On 3/23/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote: Hi Jeremy For the assembly proposal, are you suggesting something like : https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ sca/distribution/tss-sample/ Something like that, yeah. You want to rely on things that are as stable as possible, preferably things that have been released. I would not have included pom/parent and buildtools as those are available from the release repo. Generally you want to include as few unstable dependencies as possible. Also, I noticed you have a assembly descriptor in your project but you also include distribution/sca/demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: Should XMLHelper support DataGraph and how
Yang, the sample used to show how to load the datagraph XML with the XMLHelper and then pull the data graph (i.e., graph of DataObject's) out of it. This didn't create a DataGraph, but it was still an interesting example. That should still be possible, isn't it? Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 03/23/2007 05:12:27 PM: Thanks to Frank; I'll remove using XMLHelper to load DataGraph from the samples (of the Release Candidate). On 3/23/07, Frank Budinsky [EMAIL PROTECTED] wrote: Yang, XMLHelper doesn't need to support saving and loading DataGraph at this point. In the future, we are going to replace the implementation of DataGraph to one that is a DataObject, so then it will serialize without any special code. That's the direction the SDO spec is going on this issue. Frank. Yang ZHONG [EMAIL PROTECTED] 03/23/2007 03:55 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Should XMLHelper support DataGraph and how 2-1. Should XMLHelper support both saving and loading DataGraph? Spec 2.1 page 11 (2 Architecture) says Data graphs can be serialized to XML, typically by the XMLHelper or by an XML DAS. It may imply XMLHelper should support saving DataGraph. At the same time, spec 2.1 page 45 (3.11 XMLHelper) says An XMLHelper converts XML streams to and from graphs of DataObjects. There might be readers intepreting that XMLHelper should support loading DataGraph. 2-2. How to support DataGraph if XMLHelper should? Currently, we use SDOXMLResourceImpl to save/load DataObject and DataGraphResourceFactoryImpl.DataGraphResourceImpl to save/load DataGraph. It's trivial for XMLHelper to pick a ResourceImpl to save corresponding to input object. However, it's not trivial for XMLHelper to pick a ResourceImpl to load corresponding to input stream. I have 2 solutions; let me know your preference; alternatives will be appreciated. 2-2.1. Merge DataGraphResourceImpl capability into SDOXMLResourceImpl It takes longer to implement. However, we can eliminate DataGraphResourceFactoryImpl afterwards. 2-2.2. Parse stream portion and use corresponding ResourceImpl It takes shorter to implement. However, the solution isn't trivial since stream may not support reset, where the parsed portion has to be recorded and played back. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should XMLHelper support DataGraph and how
XMLHelper uses registered model to instantiate DataObject, which is DataGraphTypeImpl corresponding to sdo:datagraph. DataGraphTypeImpl does *not* implement DataGraph interface. Our DataGraph implementation is DataGraphImpl instead, which does *not* implement DataObject interface required by XMLHelper. Yes, it's still possible. 2-2.1 and 2-2.2 may be easier to implement if we want to support loading DataGraph by XMLHelper. Which one do you prefer? Or alternative? On 3/23/07, Frank Budinsky [EMAIL PROTECTED] wrote: Yang, the sample used to show how to load the datagraph XML with the XMLHelper and then pull the data graph (i.e., graph of DataObject's) out of it. This didn't create a DataGraph, but it was still an interesting example. That should still be possible, isn't it? Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 03/23/2007 05:12:27 PM: Thanks to Frank; I'll remove using XMLHelper to load DataGraph from the samples (of the Release Candidate). On 3/23/07, Frank Budinsky [EMAIL PROTECTED] wrote: Yang, XMLHelper doesn't need to support saving and loading DataGraph at this point. In the future, we are going to replace the implementation of DataGraph to one that is a DataObject, so then it will serialize without any special code. That's the direction the SDO spec is going on this issue. Frank. Yang ZHONG [EMAIL PROTECTED] 03/23/2007 03:55 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Should XMLHelper support DataGraph and how 2-1. Should XMLHelper support both saving and loading DataGraph? Spec 2.1 page 11 (2 Architecture) says Data graphs can be serialized to XML, typically by the XMLHelper or by an XML DAS. It may imply XMLHelper should support saving DataGraph. At the same time, spec 2.1 page 45 (3.11 XMLHelper) says An XMLHelper converts XML streams to and from graphs of DataObjects. There might be readers intepreting that XMLHelper should support loading DataGraph. 2-2. How to support DataGraph if XMLHelper should? Currently, we use SDOXMLResourceImpl to save/load DataObject and DataGraphResourceFactoryImpl.DataGraphResourceImpl to save/load DataGraph. It's trivial for XMLHelper to pick a ResourceImpl to save corresponding to input object. However, it's not trivial for XMLHelper to pick a ResourceImpl to load corresponding to input stream. I have 2 solutions; let me know your preference; alternatives will be appreciated. 2-2.1. Merge DataGraphResourceImpl capability into SDOXMLResourceImpl It takes longer to implement. However, we can eliminate DataGraphResourceFactoryImpl afterwards. 2-2.2. Parse stream portion and use corresponding ResourceImpl It takes shorter to implement. However, the solution isn't trivial since stream may not support reset, where the parsed portion has to be recorded and played back. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: Build structure - having cake and still eating
On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote: Jeremy So, having these assemblies modules sounded interesting to me until the moment you said you want to base them on deployed artifacts... we have never had a habit of publishing SNAPSHOTS for all possible artifacts, and even the members of the community that are proposing this approach are failing to deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this. Ideally the deployed artifacts they would depend on would be stable released ones - this is directly inline with the stability goals expressed by the likes of Dave Booz. In general, aggregations should not depend on SNAPSHOTs or a head revision except where absolutely necessary. Mario's pain was caused because we had not put together an assembly of the modules needed for the demo. It was the wee hours of the morning, I hope you understand. Once the dust settled, the modular, independent nature of what we had allowed us to put together a very simple assembly for building exactly that (independent of any other activity in trunk). You can see this here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- demo You also mentioned before that we have M2 experience of a top down build not working, I'm not sure about all the details that comes to your mind when you say that, but I remember some build brakes (and I think this is acceptable in trunk, right ?) No, not really. and we could set some conventions like, modules that are unstable at the moment would be removed from the maven profile (and maybe a JIRA would be created)... later on, when the module is back to it's stability, whoever fixed the issue would close the JIRA (if any) and put the module back to the stable profile. The problem of this approach is that it couples everything together through the parent pom. Even if a separate parent is used, the reactor will attempt to use common dependency versions across the modules. This means that modules get coupled together based on the versions of their dependencies and so we lose the independence between them. Basically, unless they all use the same version then they won't all build. Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure both can co-exist together in perfect harmony, and it would definitely be a good solution for members of the community that are interested only in a subset of Tuscany (e.g some embedder that only requires the kernel, and a Spring extension for example), and these assembly modules could be created as needed These profiles would probably make the user experience of someone that comes to evaluate Tuscany trunk much easier, as already mentioned by Mario [1], and help others to be more productive as already expressed on various other threads [2][3]. This is where we disagree. Doing what you suggest couples all modules at a single monolithic version level. That may be desirable in a commercial product but is not a way to scale an open source community. One of the problems we have is that the documentation on the build and the pom structure is misleading and confusing users. I wanted to clean that up by removing bad poms such as java/pom.xml but was overruled. If I understand your concerns, having the convention of moving unstable modules out of the maven profile should help, but maybe you could explain what worries you, that you are fighting so hard not to allow people to build different modules with a simple mvn command. Nevertheless, it's good practice to build before committ, right ? Please can we not make this personal - I am not fighting hard not to allow anything. I am trying to find a middle ground that allows people who need to build groups of modules to do so and at the same time preserve the independence between the modules. I do not know of a way to make what you want work with independently versioned modules. I have proposed something that people seemed to be able to live with and which I believe works. Let's hear technically viable alternatives. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
OK, I give up on this, and I'll try not bring this subject up anymore !!! I'll continue with my hijacked java/pom.xml and update it as needed, I just feel sorry for the new people that will come to the Tuscany community and will fill the same pain as Mario and others. Just in case others might benefit from this, here are the profiles I have in my hijacked java/pom.xml that is working at the moment and building sca or sdo or das. profiles !-- profile to build sdo -- profile idsdo/id modules modulesdo/module /modules /profile !-- profile to build das -- profile iddas/id modules moduledas/module /modules /profile !-- profile to build sca -- profile idsca/id modules !-- support modules -- modulepom/parent/module modulepom/sca/module modulebuildtools/module !-- spec -- modulespec/sca-api-r1.0/module !-- sca modules -- modulesca/kernel/module modulesca/runtime/module modulesca/services/module modulesca/console/module modulesca/jms-discovery/module modulesca/http.jetty/module !-- samples -- modulesca/core-samples/module modulesca/core-samples/standalone/calculator/module modulesca/core-samples/standalone/loanapplication/module !-- integration tests -- modulesca/integration-test/module !-- unstbale modules that are left out of the build modulesca/core-samples/webapp/webcalc/module -- /modules /profile /profiles -- Luciano Resende http://people.apache.org/~lresende On 3/23/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote: Jeremy So, having these assemblies modules sounded interesting to me until the moment you said you want to base them on deployed artifacts... we have never had a habit of publishing SNAPSHOTS for all possible artifacts, and even the members of the community that are proposing this approach are failing to deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this. Ideally the deployed artifacts they would depend on would be stable released ones - this is directly inline with the stability goals expressed by the likes of Dave Booz. In general, aggregations should not depend on SNAPSHOTs or a head revision except where absolutely necessary. Mario's pain was caused because we had not put together an assembly of the modules needed for the demo. It was the wee hours of the morning, I hope you understand. Once the dust settled, the modular, independent nature of what we had allowed us to put together a very simple assembly for building exactly that (independent of any other activity in trunk). You can see this here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- demo You also mentioned before that we have M2 experience of a top down build not working, I'm not sure about all the details that comes to your mind when you say that, but I remember some build brakes (and I think this is acceptable in trunk, right ?) No, not really. and we could set some conventions like, modules that are unstable at the moment would be removed from the maven profile (and maybe a JIRA would be created)... later on, when the module is back to it's stability, whoever fixed the issue would close the JIRA (if any) and put the module back to the stable profile. The problem of this approach is that it couples everything together through the parent pom. Even if a separate parent is used, the reactor will attempt to use common dependency versions across the modules. This means that modules get coupled together based on the versions of their dependencies and so we lose the independence between them. Basically, unless they all use the same version then they won't all build. Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure both can co-exist together in perfect harmony, and it would definitely be a good solution for members of the community that are interested only in a subset of Tuscany (e.g some embedder that only requires the kernel, and a Spring extension for example), and these assembly modules could be created as needed These profiles would probably make the user experience of someone that comes to evaluate Tuscany trunk much easier, as already mentioned by Mario [1], and help others to be more productive as already expressed on various other threads [2][3]. This is where we disagree. Doing what you suggest couples all modules at a single monolithic version level. That may be desirable in a commercial product but is not a way to scale an open source community. One of the
Re: Build structure - having cake and still eating
On 3/24/07, Luciano Resende [EMAIL PROTECTED] wrote: OK, I give up on this, and I'll try not bring this subject up anymore !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are independently versioned modules worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? ...ant
Re: Build structure - having cake and still eating
+1 to move back to single version and a project you can build from the top with mvn On 3/23/07, ant elder [EMAIL PROTECTED] wrote: On 3/24/07, Luciano Resende [EMAIL PROTECTED] wrote: OK, I give up on this, and I'll try not bring this subject up anymore !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are independently versioned modules worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? ...ant -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Objective of the following sandbox - tuscany/sandbox/sebastien/java
Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? 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]
Back on the trunk
Folks, My 2 cents. Am looking for some serious commitment from everyone to work together on the branch. Please be civil, courteous to each other. It means don't just revert someone else's check-in because you don't like it. It also means don't use -1 just because you can. Please don't go off on a tangent (sandbox/branch) at the drop of a hat. I hope everyone puts on their best behavior and do not engage in name calling. Please address everyone one as an individual and don't guess about someone's intentions. All of us wear multiple hats. If you want to know something from someone, just ask them directly. Please don't look for conspiracy scenarios. For the time being assume that everyone is starting fresh. I know it is too much to ask for after so much bad blood. Please don't let everyone's efforts go down the drain. Finally, everyone please get back on the trunk and get cranking. If we don't come together now as a community, we never will. 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]
Re: Should XMLHelper support DataGraph and how
I don't understand why 2-2.1 or 2-2.2 is needed. I just want to load the XML with XMLHelper. It will create DataGraphTypeImpl - that's fine - it doesn't matter that it does not implement the DataGraph interface. You can still get to the company object after loading it. That's all I want for now. Doesn't that work? In the future, DataGraphTypeImpl will implement the DataGraph interface, but for now it doesn't matter. Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 03/23/2007 06:08:13 PM: XMLHelper uses registered model to instantiate DataObject, which is DataGraphTypeImpl corresponding to sdo:datagraph. DataGraphTypeImpl does *not* implement DataGraph interface. Our DataGraph implementation is DataGraphImpl instead, which does *not* implement DataObject interface required by XMLHelper. Yes, it's still possible. 2-2.1 and 2-2.2 may be easier to implement if we want to support loading DataGraph by XMLHelper. Which one do you prefer? Or alternative? On 3/23/07, Frank Budinsky [EMAIL PROTECTED] wrote: Yang, the sample used to show how to load the datagraph XML with the XMLHelper and then pull the data graph (i.e., graph of DataObject's) out of it. This didn't create a DataGraph, but it was still an interesting example. That should still be possible, isn't it? Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 03/23/2007 05:12:27 PM: Thanks to Frank; I'll remove using XMLHelper to load DataGraph from the samples (of the Release Candidate). On 3/23/07, Frank Budinsky [EMAIL PROTECTED] wrote: Yang, XMLHelper doesn't need to support saving and loading DataGraph at this point. In the future, we are going to replace the implementation of DataGraph to one that is a DataObject, so then it will serialize without any special code. That's the direction the SDO spec is going on this issue. Frank. Yang ZHONG [EMAIL PROTECTED] 03/23/2007 03:55 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Should XMLHelper support DataGraph and how 2-1. Should XMLHelper support both saving and loading DataGraph? Spec 2.1 page 11 (2 Architecture) says Data graphs can be serialized to XML, typically by the XMLHelper or by an XML DAS. It may imply XMLHelper should support saving DataGraph. At the same time, spec 2.1 page 45 (3.11 XMLHelper) says An XMLHelper converts XML streams to and from graphs of DataObjects. There might be readers intepreting that XMLHelper should support loading DataGraph. 2-2. How to support DataGraph if XMLHelper should? Currently, we use SDOXMLResourceImpl to save/load DataObject and DataGraphResourceFactoryImpl.DataGraphResourceImpl to save/load DataGraph. It's trivial for XMLHelper to pick a ResourceImpl to save corresponding to input object. However, it's not trivial for XMLHelper to pick a ResourceImpl to load corresponding to input stream. I have 2 solutions; let me know your preference; alternatives will be appreciated. 2-2.1. Merge DataGraphResourceImpl capability into SDOXMLResourceImpl It takes longer to implement. However, we can eliminate DataGraphResourceFactoryImpl afterwards. 2-2.2. Parse stream portion and use corresponding ResourceImpl It takes shorter to implement. However, the solution isn't trivial since stream may not support reset, where the parsed portion has to be recorded and played back. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Build structure - having cake and still eating
Luciano, Your hijacked version of pom portrays all the issues associated with a top down pom with a single version in a complex project. You have included the modules you want to build. It may not be of any use to me, if I want to build a separate set of modules. So what is the point in committing your pom to the source tree, if it is of use to only yourself? Then the solution would be to build the whole thing. That would never scale for complexity. Why would I want to build the whole kitchen sink, if I am interested in building only a subset that is pertinent to the task I am working on? A single version and top down build that builds everything, IMHO, would create unnecessary coupling in complex projects. If we rely on a top down build that builds everything, regardless of area of the project we are working on, I would say we lack clarity in terms of how the project is architecturally modularized. And for new comers to build samples, I agree with Jeremy that the best thing to do is use mvn assemblies based on published artifacts. On a side note, I think you should never give up :) IMHO we should have these constructive discussions, as long as they are in the best interest of the community and the project. ta Meeraj -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: 24 March 2007 00:05 To: tuscany-dev@ws.apache.org Subject: Re: Build structure - having cake and still eating OK, I give up on this, and I'll try not bring this subject up anymore !!! I'll continue with my hijacked java/pom.xml and update it as needed, I just feel sorry for the new people that will come to the Tuscany community and will fill the same pain as Mario and others. Just in case others might benefit from this, here are the profiles I have in my hijacked java/pom.xml that is working at the moment and building sca or sdo or das. profiles !-- profile to build sdo -- profile idsdo/id modules modulesdo/module /modules /profile !-- profile to build das -- profile iddas/id modules moduledas/module /modules /profile !-- profile to build sca -- profile idsca/id modules !-- support modules -- modulepom/parent/module modulepom/sca/module modulebuildtools/module !-- spec -- modulespec/sca-api-r1.0/module !-- sca modules -- modulesca/kernel/module modulesca/runtime/module modulesca/services/module modulesca/console/module modulesca/jms-discovery/module modulesca/http.jetty/module !-- samples -- modulesca/core-samples/module modulesca/core-samples/standalone/calculator/module modulesca/core-samples/standalone/loanapplication/module !-- integration tests -- modulesca/integration-test/module !-- unstbale modules that are left out of the build modulesca/core-samples/webapp/webcalc/module -- /modules /profile /profiles -- Luciano Resende http://people.apache.org/~lresende On 3/23/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote: Jeremy So, having these assemblies modules sounded interesting to me until the moment you said you want to base them on deployed artifacts... we have never had a habit of publishing SNAPSHOTS for all possible artifacts, and even the members of the community that are proposing this approach are failing to deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this. Ideally the deployed artifacts they would depend on would be stable released ones - this is directly inline with the stability goals expressed by the likes of Dave Booz. In general, aggregations should not depend on SNAPSHOTs or a head revision except where absolutely necessary. Mario's pain was caused because we had not put together an assembly of the modules needed for the demo. It was the wee hours of the morning, I hope you understand. Once the dust settled, the modular, independent nature of what we had allowed us to put together a very simple assembly for building exactly that (independent of any other activity in trunk). You can see this here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- demo You also mentioned before that we have M2 experience of a top down build not working, I'm not sure about all the details that comes to your mind when you say that, but I remember some build brakes
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Davanum Srinivas wrote: Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims Dims, In the sandbox, I am trying to demonstrate a modular Tuscany kernel that can support what I described in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html I'm working on this in sandbox/sebastien/java/sca/modules. Basically I'm trying to come up with a set of black-box modules, with minimum SPIs, minimum inter-dependencies, covering the following aspects: - modules/assembly - SCA core assembly model - modules/policy - SCA Policy model - modules/scdl - SCDL support (reading/writing the model from/to SCDL) - modules/builder - A prototype of a different API to the assembly model (showing how the same model can implement multiple interfaces) - modules/java and java-scdl - SCA Java model and SCDL support for it - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL support for it - modules/crud and crud-scdl - a prototype of a simplistic SCA component implementation type, to help validate the pluggability into the model and the SCDL support - modules/http http-tomcat and http-jetty - embedded Tomcat and Jetty, I want to experiment with a binding (probably based on HTTP) and I'm not sure which to pick between Tomcat and Jetty for that so I pulled these two modules in as well and put in modules/http a small ServletHost interface that will help integrate them. I'm also just starting to prototype a variant implementation of the assembly model, to see how a fairly different model implementation can be swapped without breaking the other pieces (using the assembly model API interfaces). So this first set of modules covers part of the SCA metadata/model story. Next I'd like to start looking at the execution runtime and see how the execution part of kernel/core can be split in multiple modules as well. I'd like to see how the SCA Java component support can be extracted as a separate module for example. I also copied to my sandbox a top-down build structure including end to end samples and integration tests, which I'd like to use to validate that these ideas and this assembly of modules hold together. So, as I said in the above thread, I'd like feedback, ideas or help with this work. People have asked for a more concrete proposal and more details, the proposal is starting to take shape, and I'm happy to continue to work on it wherever the community feel it should be done. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
