Re: Diagram Drafts
Hi Rick I tried to put together all the diagrams I had seen and spin up a version of the new site layout. Unfortunately my mail describing this took 7 hours to either get out of our local systems or be reflected by the Apache mail list. So apologies if we have overlapped. The work is attached to this JIRA ( https://issues.apache.org/jira/browse/TUSCANY-568). I think Pete was applying it. Regards Simon On 7/20/06, Rick [EMAIL PROTECTED] wrote: Trying to get some of this stuff together. I'm moving in the DAS stuff from Luciano but that seemed very limited and a lot missing. It also has references to microsoft mso objects that need to go. I put in Venkata diagram that is clickable to the technologies. I'll try to replace that with David's work. Is this at a state where we are relatively happy with this? I rather not do the image map a zillion times if you get my drift. kelvin goodson wrote: I've added some embrionic SDO stuff as a patch in Tuscany 568. Would some kind committer like to put it up for me please? Are we all still aiming to get this replacement live before OSCon? If so I'll put some more focus into bringing across the fundamental bulk of SDO material from the existing site, and making things prettier, but I'm reluctant to spend all my time between now and travelling to OSCon on this if the likelihood is that we won't switch over in the near term. On 7/19/06, Luciano Resende [EMAIL PROTECTED] wrote: So, If i'm guessing right, the idea is to have this diagram on the main page, and once a user clicks on a link, let's say DAS, it would go to a DAS overview page ? So we could probably make each component that is listed on the tuscany web site outline to have an overview page and redirect the user to that page when a component is clicked...As long as that page is not a text only one :) I have a proposal for the DAS content on the attached DAS overview.zip I'd need some help on updating the diagram using the same tool David is using, as it looks like MAC only... And I'll build the object diagram for DAS to be part of the DAS Overview as well... Thanks - Luciano On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Cool - thanks! On Jul 19, 2006, at 12:35 PM, David Wheeler wrote: oh, ok. Lets try this agian zipped. -David Wheeler On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote:I found out yesterday the list strips PDFs but if you zip them it goes through. Jim On Jul 19, 2006, at 12:22 PM, David Wheeler wrote: Sure thing Jim. Should be attached On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip - To unsubscribe, e-mail: [EMAIL
Re: Diagram Drafts
No problemo, looks good. Simon Laws wrote: Hi Rick I tried to put together all the diagrams I had seen and spin up a version of the new site layout. Unfortunately my mail describing this took 7 hours to either get out of our local systems or be reflected by the Apache mail list. So apologies if we have overlapped. The work is attached to this JIRA ( https://issues.apache.org/jira/browse/TUSCANY-568). I think Pete was applying it. Regards Simon On 7/20/06, Rick [EMAIL PROTECTED] wrote: Trying to get some of this stuff together. I'm moving in the DAS stuff from Luciano but that seemed very limited and a lot missing. It also has references to microsoft mso objects that need to go. I put in Venkata diagram that is clickable to the technologies. I'll try to replace that with David's work. Is this at a state where we are relatively happy with this? I rather not do the image map a zillion times if you get my drift. kelvin goodson wrote: I've added some embrionic SDO stuff as a patch in Tuscany 568. Would some kind committer like to put it up for me please? Are we all still aiming to get this replacement live before OSCon? If so I'll put some more focus into bringing across the fundamental bulk of SDO material from the existing site, and making things prettier, but I'm reluctant to spend all my time between now and travelling to OSCon on this if the likelihood is that we won't switch over in the near term. On 7/19/06, Luciano Resende [EMAIL PROTECTED] wrote: So, If i'm guessing right, the idea is to have this diagram on the main page, and once a user clicks on a link, let's say DAS, it would go to a DAS overview page ? So we could probably make each component that is listed on the tuscany web site outline to have an overview page and redirect the user to that page when a component is clicked...As long as that page is not a text only one :) I have a proposal for the DAS content on the attached DAS overview.zip I'd need some help on updating the diagram using the same tool David is using, as it looks like MAC only... And I'll build the object diagram for DAS to be part of the DAS Overview as well... Thanks - Luciano On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Cool - thanks! On Jul 19, 2006, at 12:35 PM, David Wheeler wrote: oh, ok. Lets try this agian zipped. -David Wheeler On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote:I found out yesterday the list strips PDFs but if you zip them it goes through. Jim On Jul 19, 2006, at 12:22 PM, David Wheeler wrote: Sure thing Jim. Should be attached On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip
Re: Rationale for SDO DataType Conversions
Thanks. I take the point about convenience. I think what was puzzling me was that in a number of cases there isn't any convenience. No one in the real world is ever going to do getByte on a value that was stored as a Double. But having conversions like that in the spec just clutters both the spec and the implementation. I'm not objecting to all conversions. As I said in the base note, some make perfect sense. I was just puzzled by the fact that some of the ones that SDO offers don't really deliver any value (that I can see) to the user and yet they add burden for the developers. I'll ask this in the spec mailing list as Frank suggests. Geoff. On 20/07/06, Yang ZHONG [EMAIL PROTECTED] wrote: Geoff, while providing convenience as Frank explains, the spec doesn't prevent users from converting themselves. e.g. a user can always converts from double to byte then calls setByte. Are you proposing to always force users to convert and setXxx fails with mismatched Type? On 7/20/06, Frank Budinsky [EMAIL PROTECTED] wrote: Geoff, I don't really know the answer, but my guess is that it's simply a matter of trying to provide as much convenience as possible. I think you should ask this question on the SDO spec collaboration mailing list. Frank. Geoffrey Winn [EMAIL PROTECTED] wrote on 07/20/2006 08:36:09 AM: This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff. -- Yang ZHONG
[jira] Commented: (TUSCANY-547) Discriminated types
[ http://issues.apache.org/jira/browse/TUSCANY-547?page=comments#action_12422591 ] Geoff Winn commented on TUSCANY-547: I'm looking into this. Discriminated types --- Key: TUSCANY-547 URL: http://issues.apache.org/jira/browse/TUSCANY-547 Project: Tuscany Issue Type: Improvement Components: C++ SDO Environment: all Reporter: Ed Slattery There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object. One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter. Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type. This would reduce the codebase, make it cleaner. Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Sample update
Thanks Robbie, Here's a corrected link to the parent folder of the 3 zip file attachments for the above note ... http://wiki.apache.org/ws-data/attachments/Tuscany(2f)TuscanyJava/attachments/ I've pulled them down and will have a play while I'm away next week. Cheers, Kelvin. On 7/21/06, Robbie J Minshall [EMAIL PROTECTED] wrote: Updated sdo samples and placed on the wiki at tuscany-dev@ws.apache.org - any comments are welcome. The following changes were made : - updated copyright - added package and project overview to javadoc - reworked javadoc for samples in order to increase consistancy - reworked codeSnipet examples s.t they can standalone rather than refer to each other. Determined that being able to standalone was more important than code duplication within Samples. Remaining work items - complete TODO listings - write getting started tutorial and attach to overview javadoc - screenshots for getting started and execution of samples - commit initial samples - work on best practices example set and include new samples form papers that are in progress. Robbie -- Best Regards Kelvin Goodson
[jira] Created: (TUSCANY-570) Duplicate namespace on operation element of SOAP message causes problem
Duplicate namespace on operation element of SOAP message causes problem --- Key: TUSCANY-570 URL: http://issues.apache.org/jira/browse/TUSCANY-570 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M1 Environment: Windows XP Reporter: Simon Laws This is an artefact of the Interop testing. JIRA505 (http://issues.apache.org/jira/browse/TUSCANY-505 )describes the problem associated with having xsi:type associated with the wrapper element in the SOAP body. I note that the C++ produced messages also have duplicate namespaces which may also be causing a problem as I have to remove the duplicate to move on through the interop testing. When C++ calls stock quote ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header xmlns:wsa=http://www.w3.org/2005/08/addressing; wsa:Tohttp://localhost:8081/interop-stockquote/services/StockQuoteService/wsa:To wsa:Actionhttp://www.quickstockquote.com/StockQuoteService/getQuote/wsa:Action wsa:MessageID870bf065-6849-47fb-86ad-224b81513541/wsa:MessageID /soapenv:Header soapenv:Body getQuote xsi:type=getQuote xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://www.quickstockquote.com/StockQuoteService/; xmlns:tns=http://www.quickstockquote.com/StockQuoteService/; symbolIBM/symbol /getQuote /soapenv:Body /soapenv:Envelope When Java calls stock quote ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header / soapenv:Body Service:getQuote xmlns:Service=http://www.quickstockquote.com/StockQuoteService/; symbolIBM/symbol /Service:getQuote /soapenv:Body /soapenv:Envelope Note that C++ declares the namspace http://www.quickstockquote.com/StockQuoteService/ as the default namespace and with a prefix. I haven't investigated in depth the cause of this but this is a place hold for when I (or someone else) gets round to looking. For testing I adjusted SDOXMLWritte.cpp around line 788 to prevent it writing out namespaces: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++/Java] Interop update
I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about the WSDL is the use of anonymous types. My preference is not to do this by default but of this doesn't work at present ( http://issues.apache.org/jira/browse/TUSCANY-500 ). 3/ Changed GetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp and associated StockQuoteExternal files ( http://issues.apache.org/jira/browse/TUSCANY-508) 4/ Axis2Client.cpp ln 282 LOGINFO_2 causes an edna in the case where the server being called returns an error. I changed this to a LOGINFO, i.e. no var args, and carried on. I didn't go back
Re: [C++/Java] Interop update
Simon, I reassigned TUSCANY-505 to the SCA component for further investigation. Frank. Simon Laws [EMAIL PROTECTED] wrote on 07/21/2006 07:44:35 AM: I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about the WSDL is the use of anonymous types. My preference is not to do this by default but of this doesn't work at present ( http://issues.apache.org/jira/browse/TUSCANY-500 ). 3/
Re: [C++/Java] Interop update
Hi Frank, Thanks for that. How did you do it. I looked at the JIRA and I could see how you change the category like that? Is it a committer thing? Regards Simon On 7/21/06, Frank Budinsky [EMAIL PROTECTED] wrote: Simon, I reassigned TUSCANY-505 to the SCA component for further investigation. Frank. Simon Laws [EMAIL PROTECTED] wrote on 07/21/2006 07:44:35 AM: I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about the
Re: [C++/Java] Interop update
Hi Simon, On the left side of the window, under Operations, there is a link Edit this issue. If you don't see it, then it must be only available to committers. Frank. Simon Laws [EMAIL PROTECTED] wrote on 07/21/2006 09:28:15 AM: Hi Frank, Thanks for that. How did you do it. I looked at the JIRA and I could see how you change the category like that? Is it a committer thing? Regards Simon On 7/21/06, Frank Budinsky [EMAIL PROTECTED] wrote: Simon, I reassigned TUSCANY-505 to the SCA component for further investigation. Frank. Simon Laws [EMAIL PROTECTED] wrote on 07/21/2006 07:44:35 AM: I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence
[jira] Created: (TUSCANY-571) Remove reference to EPackage for Type look up
Remove reference to EPackage for Type look up - Key: TUSCANY-571 URL: http://issues.apache.org/jira/browse/TUSCANY-571 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx The current use of EPackage to get Types associated with a URI should be replaced with an SDO-only alternative -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=all ] Kelvin Goodson updated TUSCANY-153: --- Attachment: do_cs_2.patch Frank, here's the first drop of this function we spoke about. ChangeSummary on root data object not supported --- Key: TUSCANY-153 URL: http://issues.apache.org/jira/browse/TUSCANY-153 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: do_cs_2.patch, tuscany153.jar The RDB DAS intends to produce data graphs without using a DataGraph instance and this requires us to attach a change history to the root DataObject. It seems that this capability is not yet implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12422675 ] Kelvin Goodson commented on TUSCANY-153: By the way, in the patch I just sent, I asked the patch creation tool to pay respect to the fact that I had deleted ./model/impl/ChangeSummaryTypeImpl.java, but I can't see an artefact in the patch to that effect, so if not deleted this file will show lots of compiler errors. ChangeSummary on root data object not supported --- Key: TUSCANY-153 URL: http://issues.apache.org/jira/browse/TUSCANY-153 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: do_cs_2.patch, tuscany153.jar The RDB DAS intends to produce data graphs without using a DataGraph instance and this requires us to attach a change history to the root DataObject. It seems that this capability is not yet implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++ SCA] Language bindings embedding the runtime
Hi, I've been loosely thinking about what it will take to provide extra language bindings to Tuscany SCA C++ and how that relates to providing the runtime as an extension within a language. I've put my early thoughts up on the wiki here: http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes I guess with the new spec there will be quite a lot of changes, so this may all become redundant, but I was just thinking how I'd like to see Python or Ruby components running alongside C++ ones (and, of course, Java ones too!) :-) Cheers Andy
Re: Chianti extension manual
Hi, Jim. Forgot to mention that I had an early version on this topic. I uploaded it to http://wiki.apache.org/ws/Tuscany/TuscanyJava/Extending/Manual. Maybe you can take a look to see if it helps. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 12, 2006 6:04 PM Subject: Chianti extension manual I've started a manual for extending Chianti. It's obviously very rough and missing many pieces but comments and contributions are welcome. If you plan on editing it, please let me know so we don't collide. Also, this is a good point to raise the question of how we want to construct user manuals. I seem to recall Hibernate having a good process which results in the output of multiple formats, including pdf, single page html, and multi-page html. Any suggestions? For the time being, I've left it in Word but plan to switch to a more open format. Jim - 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: Async Java Target Invoker
Hi Ignacio, The test case failure is due to the assertion problem that was outlined in another threead (just change MAVEN_OPTS to have -ea). I'll submit the patch as soon as I clear out another checkin I have on my machine and will take a look at the monitor problem as well. Thanks, Jim On Jul 20, 2006, at 9:06 AM, Ignacio Silva-Lepe wrote: I have an initial pass at a replacement for one-way async support using a target invoker rather than an interceptor. I have been able to test it in chianti and ported it to the latest trunk. For some reason having to do with SCA SPI test failures, I can't successfully build the man trunk yet so I haven't yet verified the target invoker there. In any case, in the interest of having something go into the trunk sooner rather than later, here's the patch. Notice that the target invoker should be using a monitor to flag an error during invoke on a separate thread. However, trying to use a monitor I get the build error (in chianti) below. So, I have commented out use of a monitor for now. Running localwire.LocalWireTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.511 sec FA ILURE! testMessage(localwire.LocalWireTestCase) Time elapsed: 0.501 sec ERROR! org.apache.tuscany.spi.builder.BuilderConfigException: No builder registered for implementation [org.apache.tuscany.core.implementation.java.JavaImplementation] Context stack trace: [TargetComponent] at org.apache.tuscany.core.builder.BuilderRegistryImpl.build (BuilderRegi stryImpl.java:93) at org.apache.tuscany.core.implementation.system.builder.SystemComposite Builder.build(SystemCompositeBuilder.java:97) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build (BuilderRegi stryImpl.java:99) at org.apache.tuscany.core.deployer.DeployerImpl.build (DeployerImpl.java :125) at org.apache.tuscany.core.deployer.DeployerImpl.deploy (DeployerImpl.jav a:91) at org.apache.tuscany.core.launcher.Launcher.bootApplication (Launcher.ja va:195) at org.apache.tuscany.test.SCATestCase.setUp (SCATestCase.java:40) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java: 124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.j ava:747) Results : Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 AsyncJavaTargetInvokerPatch.txt - 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]
Jennifer M Zorza is out of the office.
I will be out of the office starting 07/21/2006 and will not return until 07/24/2006. I will not have access to my mail, so I will respond to your message when I return. For emergencies- please contact Joan Karol, for SCA testing issues- please contact Mark Pagliaro, and for WLM/Clustering issues- please contact Rimas Rekasius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-427) Test case files need to end with TestCase to be executed
[ http://issues.apache.org/jira/browse/TUSCANY-427?page=all ] Frank Budinsky resolved TUSCANY-427. Resolution: Fixed Fixed in revision 424369. Test case files need to end with TestCase to be executed Key: TUSCANY-427 URL: http://issues.apache.org/jira/browse/TUSCANY-427 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-Mx Reporter: Fuhwei Lwo Priority: Minor Attachments: TestUtil.txt TypeRoundTripTest.java in sdo/impl project and StaticSequenceNoEmfTest.java were never executed because their file names are not ending with TestCase so they were not ran during the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletLauncher, was: svn commit: r424013...
On Jul 20, 2006, at 5:14 PM, Ken Tam wrote: On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 20, 2006, at 11:16 AM, [EMAIL PROTECTED] wrote: +/** + * Default application SCDL path used if no applicationScdlPath param is specified + * + * REVIEW: this doesn't work as expected right now because we are using the webapp classloader + * directly, which doesn't include the root of the webapp. + */ +public static final String DEFAULT_APPLICATION_SCDL_PATH = WEB-INF/default.scdl; + You can get the URL of the resource from the ServletContext e.g. URL scdl = servletContextEvent.getServletContext().getResource(/ WEB-INF/default.scdl); note the leading / is required. Thought about having a ServletLauncher that extends of Launcher and overrides bootRuntime() to use a different mechanism for SCDL resolution (ie, ServletContext.getResource, not the application classloader, which is the current implied contract for Launcher), but.. I was worried about was doing this to load the initial SCDL, but still having the rest of the code (thinking specifically about the code that handles SCDL includes) use the application classloader and thus resolve differently (or just fail).. haven't gotten around to drilling into that code to see whether it supports different strategies for doing resource loading. I think we need to be careful of the distinction between resource loading and artifact loading. At the top level here we are specifying how the primordial SCDL artifact will be loaded - we are defining that it is a resource in WEB-INF and so using a (ServletContext based) resource loader to load it is OK. However, that SCDL will contain references to other artifacts that may not be resources that are part of the webapp or which may not even be physical resources at all. There are certain types of artifact that we know that we will need to deal with because they are referenced by the SCA specifications (e.g Java classes, WSDLs) ; there are other types that will be contributed as part of Tuscany extensions (e.g. Groovy scripts). I think some form of artifact repository will be needed but we should work out the form and the API implementations can use to access it. I've hinted before at possibly basing something on Maven's repository and would be curious what people think. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dave Spriet/Toronto/IBM is out of the office.
I will be out of the office starting 21/07/2006 and will not return until 30/07/2006. I will respond to your message when I return. My backup while I am on vacation is as follows: XPath builder - Shane and Cecilia WESB Mapping support - Cecilia MB PMR/Service - Dorian WESB UTE/WESB Extensions in WID - Ming/Shane Manager issues: Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Assembly class diagram
Pete Robbins wrote: Looks interesting. One quick comment: what is Object in C++ terms? ;-) Good question. I was trying to keep the class diagram language-independent with types like String, QName, NCName, AnyURI, and Object, and using Object for Component property values. If I understand the SCA spec correctly, the value of a component property can be a primitive type, a string, an SDO DataObject or another data-binding-specific representation of a complex type. In most programming languages primitive types are not Objects, so my usage of Object here was not quite correct. I'll define an Any type to represent these property values in the class diagram (actually corresponding to the xsd:any used by the spec to define these types). In the C++ runtime, will that translate to a void *? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Scenarios: was Using Scenarios
I believe there is some agreement about using scenarios so I've started a new thread as the old was getting a little long I got round to taking a look at the scenarios page on the wiki. Hope I'm looking at the right place ( http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios#preview). This may be a bit controversial but I'd like to have a few descriptions, scenarios, samples (call them what you will) that take more of a business problem view on the value of SCA. From there we can show the path to the individual technical use cases mentioned. For example, we may expect the technical reader to understand why JSON or Celtix are useful but we want the reader (either inside or outside the project) to understand why there is value in SCA in making these pluggable bindings. I.e. what role is SCA playing? Any how I've done some very brief sketches. I'm completely happy if these live on a separate page so they don't mess up the technical scenarios. I'm also happy to put some effort in to expand these thoughts if the team aren't dead set against them. Help and other thoughts most welcome of course.
Re: Scenarios: was Using Scenarios
Thanks Simon, I think this would be useful. Perhaps we should also link to SCA whitepapers on osoa.org once they are published? One thing I would like to make sure we do is maintain the technical scenarios with easy navigation to them without having to click through business scenarios. I think the current layout suits that so as long as the technical ones don't become buried behind a pile of click-throughs. We may want to separate the two scenarios types into two pages if they become too numerous to fit on one. Jim On Jul 21, 2006, at 10:24 AM, Simon Laws wrote: I believe there is some agreement about using scenarios so I've started a new thread as the old was getting a little long I got round to taking a look at the scenarios page on the wiki. Hope I'm looking at the right place ( http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios#preview). This may be a bit controversial but I'd like to have a few descriptions, scenarios, samples (call them what you will) that take more of a business problem view on the value of SCA. From there we can show the path to the individual technical use cases mentioned. For example, we may expect the technical reader to understand why JSON or Celtix are useful but we want the reader (either inside or outside the project) to understand why there is value in SCA in making these pluggable bindings. I.e. what role is SCA playing? Any how I've done some very brief sketches. I'm completely happy if these live on a separate page so they don't mess up the technical scenarios. I'm also happy to put some effort in to expand these thoughts if the team aren't dead set against them. Help and other thoughts most welcome of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira permissions, was: [C++/Java] Interop update
On Jul 21, 2006, at 6:41 AM, Frank Budinsky wrote: Hi Simon, On the left side of the window, under Operations, there is a link Edit this issue. If you don't see it, then it must be only available to committers. It may be available to folk in the tuscany-developers group which includes committers but also other active contributors as well. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Project groupIds
I was fixing up the DAS pom's recently and noticed that the groupId was set to org.apache.tuscany.das which seemed quite sensible. What do people think about changing the groupIds for sca and sdo to o.a.t.sca and o.a.t.sdo respectively? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Assembly class diagram
On 7/21/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Looks interesting. One quick comment: what is Object in C++ terms? ;-) Good question. I was trying to keep the class diagram language-independent with types like String, QName, NCName, AnyURI, and Object, and using Object for Component property values. If I understand the SCA spec correctly, the value of a component property can be a primitive type, a string, an SDO DataObject or another data-binding-specific representation of a complex type. In most programming languages primitive types are not Objects, so my usage of Object here was not quite correct. I'll define an Any type to represent these property values in the class diagram (actually corresponding to the xsd:any used by the spec to define these types). In the C++ runtime, will that translate to a void *? That's what I thought when Pete posed the question, but this still leaves the issue of how to deal with the pointer when it needs to be used somewhere - there's no way of knowing how to deal with/get the value because it isn't typed in any way. One way to get round this would be to have a typed thing struct or similar which would consist of a void * pointer and an enum to define the type, but then, we're starting to head into SDO territory here.. ;-) Andy
[C++] Configuring an Eclipse C++ IDE for Tuscany Development
I just finished configuring a Tuscany C++ development environment on my Linux machine with the Eclipse C++ Tools. It's very easy to set up and the C++ tools work pretty well. I thought it would be useful to share the steps I went through on Redhat Linux. 1. Download and install Eclipse 3.2 and the C/C++ Development tools - Point your Web browser to http://www.eclipse.org/callisto/c-dev.php for the Eclipse C++ / CDT home page. - Download the Eclipse 3.2 Platform Runtime (33 Mb) from http://download3.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/callisto.php - Run tar xzf eclipse-platform-3.2-linux-gtk.tar.gz to extract the eclipse runtime - Make sure you have a Java JRE 1.4.2 or higher, it is required to run eclipse. - Run eclipse/eclipse to start eclipse - From the top menu bar click help / software updates / find an install - In the install dialog select search for new features to install, click next - In sites to include... select Callisto Discovery Site, click next - In select the features to install, select Callisto Discovery Site / C and C++ development, click next - Read and accept the Eclipse license agreement, press finish, this will download and install the CDT plugins - Restart your Eclipse workbench 2. Create Eclipse C/C++ projects for the SDO and SCA runtimes SDO - From the top menu bar, select Window / Open Perspective / Other / C/C++ to open the C/C++ development perspective - Select File / New / Standard Make C++ Project - In the New Project dialog, choose a Project name: sdo - Uncheck Use default location, click Browse and select the tuscany/cpp/sdo folder (where you have checked out the Tuscany C++ SDO code), click Next - In the Make Builder tab, change the following: - Check Stop on first build error - Check Build on resource save, and change the Make build target to blank (instead of the default all) - Change the Incremental Build target to install (instead of all) - In the C++ Index tab, select Fast C/C++ Indexer - Press finish, wait for the workspace to build. Note: With this setup Eclipse will not generate the makefiles, it will only run make to build/rebuild the projects. The makefiles still need to be generated from the command line using automake, configure etc. It's probably better to do this from the command line anyway, but you don't need to do it very often, when you change folder structures for example. SCA Repeat the same steps to create an sca project. After you complete these steps, you should have a nice working C++ development environment, loaded with the Tuscany C++ code. The C++ editor supports code assist, syntax highlighting, some refactoring, when you make changes to your code, builds get triggered automatically in the background and any errors are nicely reported in the C++ editor. The debugger fronts gdb, works well and allows me to step through the Tuscany runtime, inspect variables etc. Hope this helps. Happy coding... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Which work manager?
Which work manager implementation are we actually using? If it's Meeraj's, can we remove the dependencies on the Geronimo implementation? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
With more than 72hrs since the refreshed distro and 4 +1 votes I have asked the incubator PMC to vote for this release. Cheers, Pete
Restoring files in svn?
I've been looking into restoring the DAS companyweb sample that got deleted with the move to chianti. I can copy the files from the last revision before it was deleted using svn cp -r revision, but I'm having problems creating a patch file from it as the svn diff show up empty. Is there an easy way to do this? I suppose I could delete all the version information and add in the new files, but that seems like the wrong approach. Is it possible for a committer to copy the old revision and then commit? When I check the status after the copy it looks like all the files are there and show up as added files. Thanks, Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletLauncher, was: svn commit: r424013...
I think we need to be careful of the distinction between resource loading and artifact loading. At the top level here we are specifying how the primordial SCDL artifact will be loaded - we are defining that it is a resource in WEB-INF and so using a (ServletContext based) resource loader to load it is OK. However, that SCDL will contain references to other artifacts that may not be resources that are part of the webapp or which may not even be physical resources at all. Right, understand the resource/artifact distinction here -- my problem was that I had been under the impression that the classloader injected onto the module implementation was used to load the SCDL (and actually added a comment to that effect.. oops), and so was worried that by using a different mechanism at the top-level for a SCDL file would run into problems when it hit includes. As I grovel through the code I see that SCDL file references are tracked via URLs and included SCDLs have their URL built relative to a parent URL, so the module impl's injected classloader is a red herring. Working on understanding the deployment code; here's a snippet that's unclear to me: In DeployerImpl.deploy(CompositeComponent? parent, CompositeDefinitionI componentDefinition) : DeploymentContext deploymentContext = new RootDeploymentContext(null, xmlFactory, moduleScope, null) For the case where componentDefinition.getImplementation() is an instance of SystemCompositeImplementation, shouldn't the SCDL URL be passed into the RootDeploymentContext? (as opposed to null) There are certain types of artifact that we know that we will need to deal with because they are referenced by the SCA specifications (e.g Java classes, WSDLs) ; there are other types that will be contributed as part of Tuscany extensions (e.g. Groovy scripts). I think some form of artifact repository will be needed but we should work out the form and the API implementations can use to access it. I've hinted before at possibly basing something on Maven's repository and would be curious what people think. I hope to have some thoughts on this later when I free up some brain cycles :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Launcher properties, was: svn commit: r424013 ...
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Jul 20, 2006, at 11:16 AM, [EMAIL PROTECTED] wrote:
public class Launcher {
+// REVIEW: ([EMAIL PROTECTED]) Perhaps this should be
null / have no default?
+// It seems to me it would very unusual (ie, uncommonly-
simplistic) for the system classloader to be the desired
+// application loader, and we might be better off requiring it
to be injected.
I would suggest we convert the launcher to a JavaBean and set these
values as properties. Using a JavaBean should make initialization
across classloaders easier.
+1, I'll take a cut at it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project groupIds
So right now sca doesn't define a groupId and is parented to tuscany-project w/ groupId o.a.t.. would this mean sca would continue to be parented to tuscany-project, but define a new groupId? What difference would this make? (I don't really get how maven treats this hierarchy to understand what the pros/cons are here) On 7/21/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I was fixing up the DAS pom's recently and noticed that the groupId was set to org.apache.tuscany.das which seemed quite sensible. What do people think about changing the groupIds for sca and sdo to o.a.t.sca and o.a.t.sdo respectively? -- 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: Project groupIds
On Jul 21, 2006, at 2:06 PM, Ken Tam wrote: So right now sca doesn't define a groupId and is parented to tuscany-project w/ groupId o.a.t.. That is so last night ... ;-) In r424080 I disinherited the project from its parent (like the other sdo and das poms) so that people could build sca without needed to build from the root first (or doing mvn -N at the root anyway) would this mean sca would continue to be parented to tuscany-project, but define a new groupId? What difference would this make? (I don't really get how maven treats this hierarchy to understand what the pros/cons are here) There is no significance to the heirarchy, it is just way of partitioning it up. This would mean that sdo, das and sca would all be peers under o.a.t rather than giving sca some perceived precedence in the root. We already have sub-hierarchies for containers, databinding, samples, ... -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Restoring files in svn?
I will copy these back. -- Jeremy On Jul 21, 2006, at 1:24 PM, Brent Daniel wrote: I've been looking into restoring the DAS companyweb sample that got deleted with the move to chianti. I can copy the files from the last revision before it was deleted using svn cp -r revision, but I'm having problems creating a patch file from it as the svn diff show up empty. Is there an easy way to do this? I suppose I could delete all the version information and add in the new files, but that seems like the wrong approach. Is it possible for a committer to copy the old revision and then commit? When I check the status after the copy it looks like all the files are there and show up as added files. Thanks, Brent - 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: Project groupIds
Ken-- Maven basically uses the groupId as a way to hierarchically name artifacts in a Maven repository. So, if something has a groupId of tuscany, it would show up in a Maven2 repository as: /tuscany/artifactId If the groupId is org.apache.tuscany, it shows up as: /org/apache/tuscany/artifactId Personally, I'm a fan of containing artifacts from a project under nested directories like this as it makes the grouping of related artifacts more obvious. Eddie On 7/21/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 21, 2006, at 2:06 PM, Ken Tam wrote: So right now sca doesn't define a groupId and is parented to tuscany-project w/ groupId o.a.t.. That is so last night ... ;-) In r424080 I disinherited the project from its parent (like the other sdo and das poms) so that people could build sca without needed to build from the root first (or doing mvn -N at the root anyway) would this mean sca would continue to be parented to tuscany-project, but define a new groupId? What difference would this make? (I don't really get how maven treats this hierarchy to understand what the pros/cons are here) There is no significance to the heirarchy, it is just way of partitioning it up. This would mean that sdo, das and sca would all be peers under o.a.t rather than giving sca some perceived precedence in the root. We already have sub-hierarchies for containers, databinding, samples, ... -- 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]
Using osgi plugin to generate manifests
We current specify manifests for some of the jars that enable them to be used as OSGi bundles. These (IIRC) are based on some sent in near the start of the year. One problem I think we face is in tracking the content of these to keep them current. I did some experimentation with the maven-osgi-plugin from Apache Felix which allows the OSGi manifest entries to be automatically generated - attached is a delta to the POM for the sca-api module that generates the manifest rather than relying on the one in the source tree. Can someone more OSGi literate than me please check that this is a reasonable manifest and see if this is a better approach? Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Restoring files in svn?
Should be back now ... -- Jeremy On Jul 21, 2006, at 1:24 PM, Brent Daniel wrote: I've been looking into restoring the DAS companyweb sample that got deleted with the move to chianti. I can copy the files from the last revision before it was deleted using svn cp -r revision, but I'm having problems creating a patch file from it as the svn diff show up empty. Is there an easy way to do this? I suppose I could delete all the version information and add in the new files, but that seems like the wrong approach. Is it possible for a committer to copy the old revision and then commit? When I check the status after the copy it looks like all the files are there and show up as added files. Thanks, Brent - 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: Using osgi plugin to generate manifests
The attachment is missing. :-) Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 21, 2006 2:41 PM Subject: Using osgi plugin to generate manifests We current specify manifests for some of the jars that enable them to be used as OSGi bundles. These (IIRC) are based on some sent in near the start of the year. One problem I think we face is in tracking the content of these to keep them current. I did some experimentation with the maven-osgi-plugin from Apache Felix which allows the OSGi manifest entries to be automatically generated - attached is a delta to the POM for the sca-api module that generates the manifest rather than relying on the one in the source tree. Can someone more OSGi literate than me please check that this is a reasonable manifest and see if this is a better approach? Thanks -- 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: Using osgi plugin to generate manifests
You may need to zip the attachments since it looks as if the list stripped them. Jim On Jul 21, 2006, at 2:41 PM, Jeremy Boynes wrote: We current specify manifests for some of the jars that enable them to be used as OSGi bundles. These (IIRC) are based on some sent in near the start of the year. One problem I think we face is in tracking the content of these to keep them current. I did some experimentation with the maven-osgi-plugin from Apache Felix which allows the OSGi manifest entries to be automatically generated - attached is a delta to the POM for the sca-api module that generates the manifest rather than relying on the one in the source tree. Can someone more OSGi literate than me please check that this is a reasonable manifest and see if this is a better approach? Thanks -- 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: Using osgi plugin to generate manifests
Sometimes they work and sometimes they don't ... let's try this
Index: pom.xml
===
--- pom.xml (revision 424385)
+++ pom.xml (working copy)
@@ -18,13 +18,19 @@
modelVersion4.0.0/modelVersion
groupIdorg.osoa/groupId
artifactIdsca-api-r0.95/artifactId
+version1.0-SNAPSHOT/version
+packagingosgi-bundle/packaging
nameSCA API/name
-version1.0-SNAPSHOT/version
+descriptionAPI classes for the Service Component Architecture/
description
prerequisites
maven2.0.4/maven
/prerequisites
+organization
+nameThe Apache Software Foundation/name
+urlhttp://www.apache.org/url
+/organization
licenses
license
nameThe Apache Software License, Version 2.0/name
@@ -40,9 +46,9 @@
urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
/repository
snapshotRepository
- idapache-snapshot-repository/id
- nameApache SNAPSHOT Repository/name
- urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
+idapache-snapshot-repository/id
+nameApache SNAPSHOT Repository/name
+urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
/snapshotRepository
/distributionManagement
@@ -61,6 +67,13 @@
/dependency
/dependencies
+pluginRepositories
+pluginRepository
+idapache-snapshot-repository/id
+nameApache SNAPSHOT Repository/name
+urlhttp://people.apache.org/repo/m2-snapshot-
repository/url
+/pluginRepository
+/pluginRepositories
build
plugins
plugin
@@ -72,12 +85,18 @@
/configuration
/plugin
plugin
-groupIdorg.apache.maven.plugins/groupId
-artifactIdmaven-jar-plugin/artifactId
+groupIdorg.apache.felix.plugins/groupId
+artifactIdmaven-osgi-plugin/artifactId
+extensionstrue/extensions
configuration
-archive
-manifestFilesrc/main/resources/META-INF/
MANIFEST.MF/manifestFile
-/archive
+osgiManifest
+bundleName${pom.name}/bundleName
+bundleDescription${pom.description}/
bundleDescription
+bundleVendor${pom.organization.name}/
bundleVendor
+bundleLocalizationplugin/bundleLocalization
+bundleSymbolicNameorg.osoa.sca/
bundleSymbolicName
+exportPackageorg.osoa.sca,
org.osoa.sca.annotations/exportPackage
+/osgiManifest
/configuration
/plugin
/plugins
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using osgi plugin to generate manifests
Several questions:
1) What's going to happen if a 3rd party dependency is not OSGi bundled?
2) How does it deal with Require-Bundle? It seems that it can populate
Import-Package automatically.
3) Can you post a sample MANIFEST.MF generated by the plugin?
I found this document useful:
http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+2.0
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, July 21, 2006 3:00 PM
Subject: Re: Using osgi plugin to generate manifests
Sometimes they work and sometimes they don't ... let's try this
Index: pom.xml
===
--- pom.xml (revision 424385)
+++ pom.xml (working copy)
@@ -18,13 +18,19 @@
modelVersion4.0.0/modelVersion
groupIdorg.osoa/groupId
artifactIdsca-api-r0.95/artifactId
+version1.0-SNAPSHOT/version
+packagingosgi-bundle/packaging
nameSCA API/name
-version1.0-SNAPSHOT/version
+descriptionAPI classes for the Service Component Architecture/
description
prerequisites
maven2.0.4/maven
/prerequisites
+organization
+nameThe Apache Software Foundation/name
+urlhttp://www.apache.org/url
+/organization
licenses
license
nameThe Apache Software License, Version 2.0/name
@@ -40,9 +46,9 @@
urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
/repository
snapshotRepository
- idapache-snapshot-repository/id
- nameApache SNAPSHOT Repository/name
- urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
+idapache-snapshot-repository/id
+nameApache SNAPSHOT Repository/name
+urlscp:///www/people.apache.org/repo/m2-snapshot-
repository/url
/snapshotRepository
/distributionManagement
@@ -61,6 +67,13 @@
/dependency
/dependencies
+pluginRepositories
+pluginRepository
+idapache-snapshot-repository/id
+nameApache SNAPSHOT Repository/name
+urlhttp://people.apache.org/repo/m2-snapshot-
repository/url
+/pluginRepository
+/pluginRepositories
build
plugins
plugin
@@ -72,12 +85,18 @@
/configuration
/plugin
plugin
-groupIdorg.apache.maven.plugins/groupId
-artifactIdmaven-jar-plugin/artifactId
+groupIdorg.apache.felix.plugins/groupId
+artifactIdmaven-osgi-plugin/artifactId
+extensionstrue/extensions
configuration
-archive
-manifestFilesrc/main/resources/META-INF/
MANIFEST.MF/manifestFile
-/archive
+osgiManifest
+bundleName${pom.name}/bundleName
+bundleDescription${pom.description}/
bundleDescription
+bundleVendor${pom.organization.name}/
bundleVendor
+bundleLocalizationplugin/bundleLocalization
+bundleSymbolicNameorg.osoa.sca/
bundleSymbolicName
+exportPackageorg.osoa.sca,
org.osoa.sca.annotations/exportPackage
+/osgiManifest
/configuration
/plugin
/plugins
-
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: Using osgi plugin to generate manifests
On Jul 21, 2006, at 3:25 PM, Raymond Feng wrote: Several questions: 1) What's going to happen if a 3rd party dependency is not OSGi bundled? 2) How does it deal with Require-Bundle? It seems that it can populate Import-Package automatically. 3) Can you post a sample MANIFEST.MF generated by the plugin? Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: jboynes Build-Jdk: 1.5.0_06 Extension-Name: sca-api-r0.95 Specification-Title: API classes for the Service Component Architecture Specification-Vendor: The Apache Software Foundation Implementation-Vendor: The Apache Software Foundation Implementation-Title: sca-api-r0.95 Implementation-Version: 1.0-SNAPSHOT Export-Package: org.osoa.sca.annotations, org.osoa.sca Bundle-Version: 1.0.SNAPSHOT Bundle-Vendor: The Apache Software Foundation Bundle-Name: SCA API Bundle-Classpath: . Bundle-Localization: plugin Bundle-Description: API classes for the Service Component Architecture Bundle-SymbolicName: org.osoa.sca I found this document useful: http://docs.safehaus.org/display/OSGI/ OSGi+Plugin+for+Maven+2.0 That's as much as I know as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-572) Tuscany SCA C++ fails to compile under Ubuntu
Tuscany SCA C++ fails to compile under Ubuntu - Key: TUSCANY-572 URL: http://issues.apache.org/jira/browse/TUSCANY-572 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M1 Environment: Ubuntu 6.0.6 Reporter: David Wheeler SDO C++ compiles, but make install fails to copy the header files into the deploy/include directory. Manually copying the header files results in SCA C++ running into an infinite loop while compiling, make[4]: Leaving directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' make[4]: Entering directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' cp ./MyValue/MyValue.h ./testSCASystem/modules/MyValueServiceModule cp ./MyValue/MyValueImpl.h ./testSCASystem/modules/MyValueServiceModule cp ./MyValue/StockQuoteService.h ./testSCASystem/modules/MyValueServiceModule cp ./CustomerInfo/CustomerInfo.h ./testSCASystem/modules/MyValueServiceModule cp ./CustomerInfo/CustomerInfoImpl.h ./testSCASystem/modules/MyValueServiceModule java -jar ../../../tools/scagen/bld/scagen.jar -dir testSCASystem/modules/MyValueServiceModule -output tmp cp tmp/CustomerInfoImpl*.* CustomerInfo cp tmp/MyValueImpl*.* MyValue cd ../../.. \ CONFIG_FILES=runtime/core/test/Makefile CONFIG_HEADERS= /bin/sh ./config.status config.status: creating runtime/core/test/Makefile config.status: executing default-1 commands make[4]: Leaving directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' make[4]: Entering directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' cp ./MyValue/MyValue.h ./testSCASystem/modules/MyValueServiceModule cp ./MyValue/MyValueImpl.h ./testSCASystem/modules/MyValueServiceModule cp ./MyValue/StockQuoteService.h ./testSCASystem/modules/MyValueServiceModule cp ./CustomerInfo/CustomerInfo.h ./testSCASystem/modules/MyValueServiceModule cp ./CustomerInfo/CustomerInfoImpl.h ./testSCASystem/modules/MyValueServiceModule java -jar ../../../tools/scagen/bld/scagen.jar -dir testSCASystem/modules/MyValueServiceModule -output tmp cp tmp/CustomerInfoImpl*.* CustomerInfo cp tmp/MyValueImpl*.* MyValue cd ../../.. \ CONFIG_FILES=runtime/core/test/Makefile CONFIG_HEADERS= /bin/sh ./config.status config.status: creating runtime/core/test/Makefile config.status: executing default-1 commands make[4]: Leaving directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' make[4]: Entering directory `/home/dwheeler/tuscany/cpp/sca/runtime/core/test' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project groupIds
Eddie: Yeah, I figured it was something like that based on inspection of the repo structure, but what confused me was how parenting relationships fit into this (it's also probably time for me to blow away big chunks of my local repo as it's accumulated a lot of stale cruft due to changes in the build :). So if you're parented to something with a groupId, it looks like you inherit that groupId but show up as a peer of your parent in the repo.. presumably defining your own groupId means you override what you get from your parent? Jeremy: Makes sense re: disconnecting the parent.. have we got the spec jars published in a repo somewhere so folks can actually build only in java/sca? Or at minimum do they still need to do a build in specs or at the root once anyway? On 7/21/06, Eddie O'Neil [EMAIL PROTECTED] wrote: Ken-- Maven basically uses the groupId as a way to hierarchically name artifacts in a Maven repository. So, if something has a groupId of tuscany, it would show up in a Maven2 repository as: /tuscany/artifactId If the groupId is org.apache.tuscany, it shows up as: /org/apache/tuscany/artifactId Personally, I'm a fan of containing artifacts from a project under nested directories like this as it makes the grouping of related artifacts more obvious. Eddie On 7/21/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 21, 2006, at 2:06 PM, Ken Tam wrote: So right now sca doesn't define a groupId and is parented to tuscany-project w/ groupId o.a.t.. That is so last night ... ;-) In r424080 I disinherited the project from its parent (like the other sdo and das poms) so that people could build sca without needed to build from the root first (or doing mvn -N at the root anyway) would this mean sca would continue to be parented to tuscany-project, but define a new groupId? What difference would this make? (I don't really get how maven treats this hierarchy to understand what the pros/cons are here) There is no significance to the heirarchy, it is just way of partitioning it up. This would mean that sdo, das and sca would all be peers under o.a.t rather than giving sca some perceived precedence in the root. We already have sub-hierarchies for containers, databinding, samples, ... -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project groupIds
On Jul 21, 2006, at 4:06 PM, Ken Tam wrote: Eddie: Yeah, I figured it was something like that based on inspection of the repo structure, but what confused me was how parenting relationships fit into this (it's also probably time for me to blow away big chunks of my local repo as it's accumulated a lot of stale cruft due to changes in the build :). So if you're parented to something with a groupId, it looks like you inherit that groupId but show up as a peer of your parent in the repo.. presumably defining your own groupId means you override what you get from your parent? You inherit most things from your parent unless you override them - groupId behaves just like the other properties so, yes. Jeremy: Makes sense re: disconnecting the parent.. have we got the spec jars published in a repo somewhere so folks can actually build only in java/sca? Or at minimum do they still need to do a build in specs or at the root once anyway? No, we need to start doing that. It's not just the spec jars - for example, databinding-sdo will need SDO snapshots published. Until we do that users will need to build from the top. (which should still build everything). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving system SCDLs into separate module under java\sca
Right now there's a set of SCDL files that define one particular basic runtime (used by the launchers), but it's packaged with the command-line launcher module (meaning that the SCDL and classes like MainLauncherBooter always come together). I propose adding the following structure and moving the current SCDL files into it: java\sca\scdl | +-basic-system |+ // current set of system SCDL files (system.scdl, loader.scdl, etc) | +- // other system definitions as they develop Each scdl module would result in a JAR, and distributions could include the appropriate one as desired. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving system SCDLs into separate module under java\sca
On Jul 21, 2006, at 4:34 PM, Ken Tam wrote: Right now there's a set of SCDL files that define one particular basic runtime (used by the launchers), but it's packaged with the command-line launcher module (meaning that the SCDL and classes like MainLauncherBooter always come together). I propose adding the following structure and moving the current SCDL files into it: java\sca\scdl | +-basic-system |+ // current set of system SCDL files (system.scdl, loader.scdl, etc) | +- // other system definitions as they develop Each scdl module would result in a JAR, and distributions could include the appropriate one as desired. How much of these do you think will be common and reusable? For example, the runtime for the launcher and the test modules are similar but slightly different (the test version does not have a directory-based extender). I think the webapp one may be similar now but will quickly diverge as we add more web-like features (like a jsp implementation). I am concerned that in attempting to make things shareable we break them down into very small chunks that end up making it harder for users (as they have to deal with all the small chunks). Instead, how about putting the included definitions into the core jar so that they become includable composites inside it. Then the launcher, servlet, whatever, host can reference them in the same way they can reference classes? This would mean extending the Include loader to be able to locate things by searching the classpath rather than just using relative URLs but that would be easy to do and generally useful. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-568) add graphical SDO content to sandbox website
[ http://issues.apache.org/jira/browse/TUSCANY-568?page=comments#action_12422802 ] Luciano Resende commented on TUSCANY-568: - I'm attaching the updated version of the DAS overview with DAS diagram and DAS Class diagram with some text overview. add graphical SDO content to sandbox website Key: TUSCANY-568 URL: http://issues.apache.org/jira/browse/TUSCANY-568 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: sdo_mainpage.zip, site-author.zip, site-publish.zip Adding a patch for fleshing out the new website's SDO page. This patch doesn't add all the existing website information, so it's not sufficient, but it's a start. I'll do more when I am confident that there's enough momentum to switch to the new version of the website before OSCon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-568) add graphical SDO content to sandbox website
[ http://issues.apache.org/jira/browse/TUSCANY-568?page=comments#action_12422808 ] Luciano Resende commented on TUSCANY-568: - Could someone please help me deleting das.zip with timestamp : 21/Jul/06 06:08 PM add graphical SDO content to sandbox website Key: TUSCANY-568 URL: http://issues.apache.org/jira/browse/TUSCANY-568 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: das.zip, das.zip, sdo_mainpage.zip, site-author.zip, site-publish.zip Adding a patch for fleshing out the new website's SDO page. This patch doesn't add all the existing website information, so it's not sufficient, but it's a start. I'll do more when I am confident that there's enough momentum to switch to the new version of the website before OSCon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
