Re: Tuscany Icon
OK, I'll attach them to the wiki shortly amd place a pointer here. On 7/5/06, Jojo [EMAIL PROTECTED] wrote: Hi Kelvin, I also didn't see any attachment in the mail. Probably the mailing-list removed the binary attachment ? -- Warm regards, jojo. On 7/5/06, kelvin goodson [EMAIL PROTECTED] wrote: Odd, I see them in the email that the mailing list returned to me. Anyone else not see them. I'll attach again in the morning if so. If not I'll show them to Simon. Cheers, Kelvin. On 7/4/06, Simon Nash [EMAIL PROTECTED] wrote: Kelvin, Did you attach something to this? I don't see any icons in your email. Simon kelvin goodson wrote: Here's a couple of ideas for Tuscany logos. They're not very well polished, but with a little bit of time they could be. I was originally looking for typical Tuscan scenes a while back, but I don't think they work too well. These were done using tools from the gimp, and there's a whole host of quick things that can be done with text. On 6/7/06, ant elder [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: I think this is a really good idea to have an Apache Tuscany icon or logo. It would brighten up the web site and we could put it on posters and t-shirts... Would Dushyanth or anyone else care to submit some sample graphics, based on those images from Dushyanth's email or something else, so we have a few to chose between? Here's some examples of logo's from other Apache projects: Axis v1: http://ws.apache.org/axis/images/axis3.jpg Axis 2: http://ws.apache.org/axis2/images/axis.jpg http://ws.apache.org/axis2/images/axis.jpg Synapse: http://incubator.apache.org/synapse/images/synapse.png Geronimo: http://geronimo.apache.org/images/topleft_logo_437x64.gif http://geronimo.apache.org/images/topleft_logo_437x64.gif Tomcat: http://tomcat.apache.org/images/tomcat.gif The classic Apache feather: www.geektimes.com/images/apache-feather.gif http://www.geektimes.com/images/apache-feather.gif And here's a mailing list thread of how the Apache Axis2 logo was chosen: http://marc.theaimsgroup.com/?t=11273667002r=1w=2 http://marc.theaimsgroup.com/?t=11273667002r=1w=2 ...ant On 6/2/06, dushyanth inguva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Guys, Here are a few concepts that you can base the Apache Tuscany project icon on: http://www.giorgiozanetti.ca/centro_italia/toscana/centrobeva_300.gif http://www.montalcino-tuscany.com/Cypress_group_and_hill_2.JPG http://www.backdrops.com.au/work/lg_imgs/BW%20Tuscany.jpg http://www.galleryone.com/images/fiore/fiore-country%20road,%20tuscany.jpg http://images.amazon.com/images/P/1894703014.01.LZZZ.jpg Cheers, Dushyanth Inguva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Best Regards Kelvin Goodson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson
Re: Autowire and/or CDI support?
I've got some patches I need to apply that may fix that. One thing I need from you is to call the Connector durng the build phase ;-). I've temporarily changed method signatures of loaders to pass the parent through so I can get things like the Monitor property injector to work. I'll check my changes in when I get them in shape and then we can remove the passing of parent and put it in a recursive DeploymentContext where it belongs. Jim On Jul 4, 2006, at 9:59 PM, Jeremy Boynes wrote: I ran into something on the plane today where components were not being autowired together. I noticed there is no AutowireProcessor (or couldn't find one anyway). Is this something in progress or something I should work on? If this is in progress, will I trip over anyone if I start to explore support for constructor injection as per the proposal on the wiki? -- 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: Tuscany Icon
OK, pictures should be visible at http://wiki.apache.org/ws/Tuscany/LogoCandidates The missing attachments in my earlier note are a mystery, I guess google mail does some smarts with recognising an incoming mail that you have sent? I definitely see an incoming note from tuscany-dev with two attachments. Kelvin. On 7/5/06, kelvin goodson [EMAIL PROTECTED] wrote: OK, I'll attach them to the wiki shortly amd place a pointer here. On 7/5/06, Jojo [EMAIL PROTECTED] wrote: Hi Kelvin, I also didn't see any attachment in the mail. Probably the mailing-list removed the binary attachment ? -- Warm regards, jojo. On 7/5/06, kelvin goodson [EMAIL PROTECTED] wrote: Odd, I see them in the email that the mailing list returned to me. Anyone else not see them. I'll attach again in the morning if so. If not I'll show them to Simon. Cheers, Kelvin. On 7/4/06, Simon Nash [EMAIL PROTECTED] wrote: Kelvin, Did you attach something to this? I don't see any icons in your email. Simon kelvin goodson wrote: Here's a couple of ideas for Tuscany logos. They're not very well polished, but with a little bit of time they could be. I was originally looking for typical Tuscan scenes a while back, but I don't think they work too well. These were done using tools from the gimp, and there's a whole host of quick things that can be done with text. On 6/7/06, ant elder [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: I think this is a really good idea to have an Apache Tuscany icon or logo. It would brighten up the web site and we could put it on posters and t-shirts... Would Dushyanth or anyone else care to submit some sample graphics, based on those images from Dushyanth's email or something else, so we have a few to chose between? Here's some examples of logo's from other Apache projects: Axis v1: http://ws.apache.org/axis/images/axis3.jpg Axis 2: http://ws.apache.org/axis2/images/axis.jpg http://ws.apache.org/axis2/images/axis.jpg Synapse: http://incubator.apache.org/synapse/images/synapse.png Geronimo: http://geronimo.apache.org/images/topleft_logo_437x64.gif http://geronimo.apache.org/images/topleft_logo_437x64.gif Tomcat: http://tomcat.apache.org/images/tomcat.gif The classic Apache feather: www.geektimes.com/images/apache-feather.gif http://www.geektimes.com/images/apache-feather.gif And here's a mailing list thread of how the Apache Axis2 logo was chosen: http://marc.theaimsgroup.com/?t=11273667002r=1w=2 http://marc.theaimsgroup.com/?t=11273667002r=1w=2 ...ant On 6/2/06, dushyanth inguva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Guys, Here are a few concepts that you can base the Apache Tuscany project icon on: http://www.giorgiozanetti.ca/centro_italia/toscana/centrobeva_300.gif http://www.montalcino-tuscany.com/Cypress_group_and_hill_2.JPG http://www.backdrops.com.au/work/lg_imgs/BW%20Tuscany.jpg http://www.galleryone.com/images/fiore/fiore-country%20road,%20tuscany.jpg http://images.amazon.com/images/P/1894703014.01.LZZZ.jpg Cheers, Dushyanth Inguva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Best Regards Kelvin Goodson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson -- Best Regards Kelvin Goodson
Kevin Bauer is out of the office.
I will be out of the office starting 07/05/2006 and will not return until 07/22/2006. I will respond to your message when I return. For urgent messages please contact my backup Thomas F Mutdosch/Durham/[EMAIL PROTECTED] or my manager Jay Cagle/Raleigh/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn repository
I had some problems yesterday using my old subclipse 0.9.x plugin. Upgraded to 1.0 rechecked out for good measure and all seems fine. Cheers, Jeremy On 7/4/06, Jim Marino [EMAIL PROTECTED] wrote: Works for me (I just did an svn up). Jim On Jul 4, 2006, at 7:54 AM, kelvin goodson wrote: I'm having trouble connecting to the svn repository. Is it down? Cheers, Kelvin. -- Best Regards Kelvin Goodson - 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]
Email versus IRC
There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant
[jira] Assigned: (TUSCANY-514) Various problems building with VC7
[ http://issues.apache.org/jira/browse/TUSCANY-514?page=all ] Ed Slattery reassigned TUSCANY-514: --- Assign To: Ed Slattery Various problems building with VC7 -- Key: TUSCANY-514 URL: http://issues.apache.org/jira/browse/TUSCANY-514 Project: Tuscany Type: Bug Components: C++ Build Environment: Windows Reporter: Ed Slattery Assignee: Ed Slattery Missing directory creations. Wrong runtime library (MDd required), and a routine which doesnt compile on vc7 (!!). -- 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: Email versus IRC
I think IRC is goodness as long as 1. the log gets posted 2. formal votes are done on email Communities that meet regularly on IRC might have an issue if they dont post logs, but if the discussion is posted on email then its a very productive. Paul On 7/5/06, ant elder [EMAIL PROTECTED] wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn repository
All seemed OK when I got home and tried again, and its working from the office now. Cheers, Kelvin. On 7/5/06, Jeremy Hughes [EMAIL PROTECTED] wrote: I had some problems yesterday using my old subclipse 0.9.x plugin. Upgraded to 1.0 rechecked out for good measure and all seems fine. Cheers, Jeremy On 7/4/06, Jim Marino [EMAIL PROTECTED] wrote: Works for me (I just did an svn up). Jim On Jul 4, 2006, at 7:54 AM, kelvin goodson wrote: I'm having trouble connecting to the svn repository. Is it down? Cheers, Kelvin. -- Best Regards Kelvin Goodson - 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] -- Best Regards Kelvin Goodson
[jira] Created: (TUSCANY-515) Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs
Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs --- Key: TUSCANY-515 URL: http://issues.apache.org/jira/browse/TUSCANY-515 Project: Tuscany Type: Wish Components: Java SDO Tools Reporter: Venkatakrishnan I am working on enhancing the Java2WSDL to handle SDOs. One of the things required in this is the mapping of SDO types to XSDs. I am following the mapping rules specified in the Java SDO Spec. v2.0.1. Pg. 107 onwards. To try out, I picked up the sequences.xsd and generted the SDOs for that. Next I run each SDO type thro' the tool I have implemented to generate the XSDs. When I compare the resultant XSD with the original they are not 'equivalent' in some cases (and I do understand that they will not be equal). To get over this incompatibility and arrive at a comparable XSD, the generated SDOs must capture some additional information or maybe we must have to change in certain parts, the way it is mapped from XSDs in the first place. This might also mean that we might end up that the specs have to be changed or enhanced in the first place. Whatever be the future course I propose to track all issues related to SDO-XSD mapping under this JIRA. For each point that I observe as an issue I shall raise sub-tasks here, within. so that I do not scatter the JIRAs related to this. -- 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] Created: (TUSCANY-516) Annotating generated SDO Types for the associated 'Factory' and 'Package' generated classes
Annotating generated SDO Types for the associated 'Factory' and 'Package' generated classes --- Key: TUSCANY-516 URL: http://issues.apache.org/jira/browse/TUSCANY-516 Project: Tuscany Type: Sub-task Components: Java SDO Tools Versions: Java-Mx Reporter: Venkatakrishnan The SDO needs to be instantiated to obtain a more reliable information about it type using the 'getType' method. To minimize user inputs in aid of this instantiation, it would be good to have an annotation added to the generated SDO, pointing to the Factory class for the SDO. Work Around : Currently, the protected constructor of the input SDO class is invoked using Java Reflection APIs. This is not an ok approach as we break the access and then invoke the constructor. Also, if the input is the SDO Type Interface then this work around will fail. If having the Factory class information sound ok, then we could also have the Package class information. I am sure we are going to need this somewhere down the line. -- 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: Email versus IRC
Hi I have found the chat logs useful to catch up with the discussions. But then we must be more choosy about the sort of topics we discuss. In my opinion the chat must be reserved for subjects that simply cannot be allowed to drag over for days, over the mailing lists. It would be good if we can decide ahead of the chat, on the subjects that should be taken for discussion i.e. fix the agenda ahead of the chat. That will help partcipants come prepared as well. As for who will decide the sort of subjects to be discussed, we could either propose and vote over the mailing lists or maybe just propose and trust the chat moderator to take a call on that. - Venkat On 7/5/06, Paul Fremantle [EMAIL PROTECTED] wrote: I think IRC is goodness as long as 1. the log gets posted 2. formal votes are done on email Communities that meet regularly on IRC might have an issue if they dont post logs, but if the discussion is posted on email then its a very productive. Paul On 7/5/06, ant elder [EMAIL PROTECTED] wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-517) Show component-to-component invocation in Calculator sample
Show component-to-component invocation in Calculator sample --- Key: TUSCANY-517 URL: http://issues.apache.org/jira/browse/TUSCANY-517 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Priority: Minor We need to include a sample that shows component-to-component invocation. The Calculator sample would be a good candidate - we could have a DivideService that is invoked by the Calculator div operation. -- 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-517) Show component-to-component invocation in Calculator sample
[ http://issues.apache.org/jira/browse/TUSCANY-517?page=all ] Andrew Borley updated TUSCANY-517: -- Attachment: TUSCANY-517.patch This patch adds a DivideService. Have also updated the automake (linux) and make (windows) files, but they will need extra testing. Show component-to-component invocation in Calculator sample --- Key: TUSCANY-517 URL: http://issues.apache.org/jira/browse/TUSCANY-517 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Priority: Minor Attachments: TUSCANY-517.patch We need to include a sample that shows component-to-component invocation. The Calculator sample would be a good candidate - we could have a DivideService that is invoked by the Calculator div operation. -- 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: Email versus IRC
On Jul 5, 2006, at 3:04 AM, ant elder wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. I like it even though my travel schedule causes me to miss it at times. I find reading the logs easy enough and when I am able to attend, it's very useful. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Having the other subprojects would be a good way to have knowledge sharing. From my SCA perspective, it would be interesting for me to compare notes with the C++ people. Also, I'm interested in hearing about how DAS and SDO are going. Is the 15:30GMT on Monday time slot ok? Works for me when I can make it but I'm also happy to change it if others have difficulty with that time. What do you think? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
I can see merit in an SDO chat and I like the idea publishing the chat topics and summarising the chat log. For me that would enable me to work smarter, since I could decide ahead of time whether to attend the wider meeting or catch up later by reading the log summary. Hopefully the net time spent for me would be less, and the relevance to my core interst would be greater. What do the rest of the SDO community think? I'd be happy to summarize and post the log. If there's interest perhaps we should try 1/2 an hour a week as a starter? Cheers, Kelvin. On 7/5/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi I have found the chat logs useful to catch up with the discussions. But then we must be more choosy about the sort of topics we discuss. In my opinion the chat must be reserved for subjects that simply cannot be allowed to drag over for days, over the mailing lists. It would be good if we can decide ahead of the chat, on the subjects that should be taken for discussion i.e. fix the agenda ahead of the chat. That will help partcipants come prepared as well. As for who will decide the sort of subjects to be discussed, we could either propose and vote over the mailing lists or maybe just propose and trust the chat moderator to take a call on that. - Venkat On 7/5/06, Paul Fremantle [EMAIL PROTECTED] wrote: I think IRC is goodness as long as 1. the log gets posted 2. formal votes are done on email Communities that meet regularly on IRC might have an issue if they dont post logs, but if the discussion is posted on email then its a very productive. Paul On 7/5/06, ant elder [EMAIL PROTECTED] wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson
[jira] Created: (TUSCANY-518) Mapping Complex Type XSD that allows mixed content (mixed=true)
Mapping Complex Type XSD that allows mixed content (mixed=true) --- Key: TUSCANY-518 URL: http://issues.apache.org/jira/browse/TUSCANY-518 Project: Tuscany Type: Sub-task Components: Java SDO Tools Versions: Java-Mx Reporter: Venkatakrishnan 1. The generated SDO Type ends up with a property named 'mixed', whereas the attributed 'mixed=true' is only to be interpretted to set the 'sequenced=true' for the SDO and not to be 'tranlated' into a property of the SDO. Workaround : When mapping the SDO to XSD, we could skip properties with name as 'mixed' or skip if the property's data type is a EFeatureMapEntry. In the first case we might run into problems if there was actually a property named 'mixed' ( for example an element named 'mixed' in the xsd from which the SDOs were generated in the first place). In the second case we will be have to go one level down to Meta Modeling Facility over which the SDOs are implemented i.e EMF and in my opinion the SDO-XSD converter will go for a toss if we decide to change it is modeled over EMF. 2. According to the specs (starting from Pg 107 onwards) if isSequenced is true for an SDO, then it is to be interpretted as complex type xsd that allows mixed content and the properties of the SDO are to be placed as content inside a repeating choice i.e. xsd:choice maxOccurs=unbounded within this complex type. Hence it ends up that the following two definitions are equivalent... xsd:sequence xsd:element name=symbol type=xsd:string / xsd:element name=companyName type=xsd:string / xsd:element name=price type=xsd:decimal / xsd:element name=open1 type=xsd:decimal / xsd:element name=high type=xsd:decimal / xsd:element name=low type=xsd:decimal / xsd:element name=volume type=xsd:double / xsd:element name=change1 type=xsd:double / xsd:element maxOccurs=unbounded minOccurs=0 name=quotes type=seq:MixedQuote / /xsd:sequence xsd:choice maxOccurs=unbounded xsd:element name=symbol type=xsd:string / xsd:element name=companyName type=xsd:string / xsd:element name=price type=xsd:decimal / xsd:element name=open1 type=xsd:decimal / xsd:element name=high type=xsd:decimal / xsd:element name=low type=xsd:decimal / xsd:element name=volume type=xsd:double / xsd:element name=change1 type=xsd:double / xsd:element maxOccurs=unbounded minOccurs=0 name=quotes type=seq:MixedQuote / /xsd:choice -- 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] Created: (TUSCANY-519) Mapping xsd:choice into properties with names starting with 'group'
Mapping xsd:choice into properties with names starting with 'group' - Key: TUSCANY-519 URL: http://issues.apache.org/jira/browse/TUSCANY-519 Project: Tuscany Type: Sub-task Components: Java SDO Tools Versions: Java-Mx Reporter: Venkatakrishnan 1. The group element xsd:choice results in a property whose name starts with 'group' (e.g. group or group1 ) in the generated SDO type. Mapping this back to XSD results in the creation of a element. Workaround : Again as in the case of mixed content, we can choose to ignore properties starting with the name 'group' or properties whose type is an EFeatureMapEntry. As mentioned in the subtask 2, this is a patchy fix that will not work for all cases. 2. There is no information about the contents of the group. The hierarchy information as it existed from the original xsd from which the SDOs were generated is obscured and all contents are flattened out into the complex type that contains the xsd:choice. So if the containing complex type contains two groups of type xsd:choice there is no means to find the elements within each of these groups. The SDO type will only contain a list of properties that is a union of all elements within the choices. Am I missing out something here? -- 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: Autowire and/or CDI support?
On 7/5/06, Jim Marino [EMAIL PROTECTED] wrote: I've got some patches I need to apply that may fix that. One thing I need from you is to call the Connector durng the build phase ;-). I've temporarily changed method signatures of loaders to pass the parent through so I can get things like the Monitor property injector to work. I'll check my changes in when I get them in shape and then we can remove the passing of parent and put it in a recursive DeploymentContext where it belongs. I'd done a little refactoring on the Property processor and had added one for @Monitor - I hope we don't conflict too badly :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
Are you saying you'd prefer not to participate, or do you want us all to stop having the weekly chat? ...ant On 7/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On 7/5/06, ant elder [EMAIL PROTECTED] wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? I'm not very comfortable with using IRC for these kind of weekly meetings - it seems too much like a status meeting to me. IMO if someone needs to be on IRC to see what is going on or what people's opinions are then we are not doing a good enough job of communicating on the mailing list. To me the main benefit from IRC is its immediacy. It provides a faster form of communication than email and that can be used to bring closure to issues that are dragging along on the list. In that mode, IRC discussions tend to more impromptu, more focused, and simpler to summarize as the subject is already well known. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-515) Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs
[ http://issues.apache.org/jira/browse/TUSCANY-515?page=comments#action_12419283 ] Frank Budinsky commented on TUSCANY-515: I'm very confused by this set of issues. The SDO spec says very clearly that roundtripping from an XSD to SDO types and then back to the same XSD is not a goal of SDO. Generating XSDs from SDO types is intended to be used to create a usable XSD definition for a set of types that were created from non-XSD input sources. The listed subtatsks here are just the tip of the iceberg of issues that would need to be addressed by the spec if it was an SDO goal to support XSD-SDO-XSD rountripping. It would take many months to try to address it completely, but SDO has explicitly said it doesn't plan to. Why would users want this roundtripping anyway? Given that they've created their types from XSD, why would they need to generate a schema ... they already have a schema. Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs --- Key: TUSCANY-515 URL: http://issues.apache.org/jira/browse/TUSCANY-515 Project: Tuscany Type: Wish Components: Java SDO Tools Reporter: Venkatakrishnan I am working on enhancing the Java2WSDL to handle SDOs. One of the things required in this is the mapping of SDO types to XSDs. I am following the mapping rules specified in the Java SDO Spec. v2.0.1. Pg. 107 onwards. To try out, I picked up the sequences.xsd and generted the SDOs for that. Next I run each SDO type thro' the tool I have implemented to generate the XSDs. When I compare the resultant XSD with the original they are not 'equivalent' in some cases (and I do understand that they will not be equal). To get over this incompatibility and arrive at a comparable XSD, the generated SDOs must capture some additional information or maybe we must have to change in certain parts, the way it is mapped from XSDs in the first place. This might also mean that we might end up that the specs have to be changed or enhanced in the first place. Whatever be the future course I propose to track all issues related to SDO-XSD mapping under this JIRA. For each point that I observe as an issue I shall raise sub-tasks here, within. so that I do not scatter the JIRAs related to this. -- 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: Tuscany 153 (SDO change history on root data object)
Frank, No, calling endLogging doesn't resolve the issue. That is the pattern that the DAS is using today. I sent the XSD I used to generate the required types with the last message rather than the types for simplicity. I'll go ahead and attach the generated files and test case to T-153. Brent On 6/29/06, Frank Budinsky [EMAIL PROTECTED] wrote: Brent, I can't run the sample, because it depends on some generated classes that you haven't provided. But, my guess is the problem is that you haven't called endLogging() before printing the ChangeSummary. If you call endLogging() first, does it then include the changes? Frank. Brent Daniel [EMAIL PROTECTED] wrote on 06/29/2006 03:32:45 PM: In talking to Frank yesterday, we decided that Tuscany 153 may not be the problem that is blocking the DAS from implementing T-154. Our issue is that: 1) We can't create a dynamic root object with the same URI as the generated DataObjects because the implementation will attempt to delegate to the generated package when we create the root object, which will fail. 2) If we use a different URI, the change history does not work correctly. I assumed this was because of T-153, but Frank believes that this scenario should be working today and asked for a test case. Attached is a simple test case that shows the problem. I'll just attach an XSD instead of the generated types. [attachment Tuscany153.java deleted by Frank Budinsky/Toronto/IBM] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=all ] Brent Daniel updated TUSCANY-153: - Attachment: tuscany153.jar I'm attaching a copy of the test case that was discussed on the dev list. ChangeSummary on root data object not supported --- Key: TUSCANY-153 URL: http://issues.apache.org/jira/browse/TUSCANY-153 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: 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]
Re: Email versus IRC
Ant was just trying to be helpful by gauging what people would like to use IRC for, although I also have to say I didn't interpret Jeremy's previous mail to be advocating a ban on IRC. I think there has been a lot of heated discussion on the list lately, and it would probably be good for us all to chill out a bit and not take things to extremes... That said, I find IRC chats useful as long as substantive discussions and all decisions of import take place on the list. I like how the chats provide an unstructured forum to ask quick questions and communicate. I don't think we need the overhead of having an agenda,deciding what gets discussed, or time boxing topics (as long as people have an equal opportunity to talk). I also don't see a problem if someone wants to send a note to the list saying they would like to discuss a particular topic so people can prepare ahead of time. Jim On Jul 5, 2006, at 8:29 AM, Jeremy Boynes wrote: On 7/5/06, ant elder [EMAIL PROTECTED] wrote: Are you saying you'd prefer not to participate, or do you want us all to stop having the weekly chat? Ant, please, that's not what I said at all. I said that, IMO (for what that's worth), I see the main benefit of IRC is its use as tool to help reach consensus when discussions on the mailing list bog down. Using IRC in that manner does not require a scheduled meeting. As pointed out on the incubator thread, having a scheduled meeting can act as a deterrant to participation. For example, one reason that I am reluctant to join in some other IRC meetings is that they occur at 5:30AM my time and my desire to participate does not exceed my desire for sleep. As Jim pointed out here, people often have other commitments that may impact their ability to participate - IIRC he cited travel issues. Being async, email does not have those problems which is why it is the preferred form of communication at the ASF. -- 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: Tuscany 153 (SDO change history on root data object)
Brent, The source file was attached to the original note but I did not see the XSD. Brent Daniel wrote: Frank, No, calling endLogging doesn't resolve the issue. That is the pattern that the DAS is using today. I sent the XSD I used to generate the required types with the last message rather than the types for simplicity. I'll go ahead and attach the generated files and test case to T-153. Brent On 6/29/06, Frank Budinsky [EMAIL PROTECTED] wrote: Brent, I can't run the sample, because it depends on some generated classes that you haven't provided. But, my guess is the problem is that you haven't called endLogging() before printing the ChangeSummary. If you call endLogging() first, does it then include the changes? Frank. Brent Daniel [EMAIL PROTECTED] wrote on 06/29/2006 03:32:45 PM: In talking to Frank yesterday, we decided that Tuscany 153 may not be the problem that is blocking the DAS from implementing T-154. Our issue is that: 1) We can't create a dynamic root object with the same URI as the generated DataObjects because the implementation will attempt to delegate to the generated package when we create the root object, which will fail. 2) If we use a different URI, the change history does not work correctly. I assumed this was because of T-153, but Frank believes that this scenario should be working today and asked for a test case. Attached is a simple test case that shows the problem. I'll just attach an XSD instead of the generated types. [attachment Tuscany153.java deleted by Frank Budinsky/Toronto/IBM] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
On Jul 5, 2006, at 8:57 AM, Jim Marino wrote: Ant was just trying to be helpful by gauging what people would like to use IRC for, although I also have to say I didn't interpret Jeremy's previous mail to be advocating a ban on IRC. I did not mean to advocate that. Ironically, Ant and I were just chatting on IRC about this (which fits the impromptu, reach consensus model quite nicely :-) Summarizing my position, I'm kind of -0 on the chats in their current form, leaning to -1 if we start to add more structure and more reliance on them to the detriment of email. I'm in favour of ad-hoc decisions (appropriately summarized) and not necessarily opposed to regular meetings in some other form. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-515) Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs
[ http://issues.apache.org/jira/browse/TUSCANY-515?page=comments#action_12419305 ] Venkatakrishnan commented on TUSCANY-515: - Frank, I perfectly understand your perspective here about the 'no necessity' for this sort of round tripping. My intention is not about generating 'equal' xsds but only 'equivalent' ones without losing information and successful round-tripping is certainly not the end towards which I am working :-). Through this exercise, I am trying to understand if there are apsects of a data model encapsulated in an XSD that will go missing when encapsulated into SDOs. Take for example the case of mixed content. It is not an attribute of a type, but then it ends up as a property. Similar is the case of xsd:choice where there is not only a property named 'group' added to the SDO Type, the containing data type is also marked as open i.e. dataType.open=true. So a data model that is originally does not permit open content will now permit open content. One way by which I can identify what aspect of the original data model is missing or getting skewed is by generating the XSDs again and comparing them. I am not rigid about the equality of the definitions as along as they will produce similar xml instances. I have these issues in front of me (and may be more would crop up as you have predicted). If you mention them as genuine then I am only relieved that I have understood them rightly. But then, I would like to see if we could identify work-arounds to address them for now or should we just live with them. Thanks. Augmenting / Modifying generated Java SDO Types to enable better conversion to XSDs --- Key: TUSCANY-515 URL: http://issues.apache.org/jira/browse/TUSCANY-515 Project: Tuscany Type: Wish Components: Java SDO Tools Reporter: Venkatakrishnan I am working on enhancing the Java2WSDL to handle SDOs. One of the things required in this is the mapping of SDO types to XSDs. I am following the mapping rules specified in the Java SDO Spec. v2.0.1. Pg. 107 onwards. To try out, I picked up the sequences.xsd and generted the SDOs for that. Next I run each SDO type thro' the tool I have implemented to generate the XSDs. When I compare the resultant XSD with the original they are not 'equivalent' in some cases (and I do understand that they will not be equal). To get over this incompatibility and arrive at a comparable XSD, the generated SDOs must capture some additional information or maybe we must have to change in certain parts, the way it is mapped from XSDs in the first place. This might also mean that we might end up that the specs have to be changed or enhanced in the first place. Whatever be the future course I propose to track all issues related to SDO-XSD mapping under this JIRA. For each point that I observe as an issue I shall raise sub-tasks here, within. so that I do not scatter the JIRAs related to this. -- 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: Email versus IRC
I think a weekly one-hour scheduled IRC chat is a good idea, even though my personal record of attendance isn't too good :-( I have scheduled these into my calendar now, whoch should help. The few chats I have been on have been useful, though perhaps closer to decision-making affairs than would ideally follow the Apache model. (Sample: what are we going to do about these JIRAs?) However, it was useful to reach quick decisions on these and the chat seemed to be a reasonable way to do this. The current time is OK for me. Simon ant elder wrote: AFAICT no one has suggested a ban on IRC, what I'm trying to find out is if we should be continuing with the regularly scheduled weekly chat. If enough people don't think we should be having it then we should stop. Thats a perfectly fine thing to happen if thats what the community want, but its not going to get stopped unless those who don't think we should be having it speak up clearly. That's what this thread is about - Are people happy with having our current weekly hour long IRC chat? ...ant -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
IRC has been a useful tool for timely community brainstorming to handle issues that need quick attention. We have started to summarize the chat content on the mailing list in messages that include the IRC chat. That is very useful. It would be good to decide on chat subject before the chat session starts and publish it on mailing list. This gives a chance to people in different time zones to decide on whether they need to attend the chat or not. On 7/5/06, Simon Nash [EMAIL PROTECTED] wrote: I think a weekly one-hour scheduled IRC chat is a good idea, even though my personal record of attendance isn't too good :-( I have scheduled these into my calendar now, whoch should help. The few chats I have been on have been useful, though perhaps closer to decision-making affairs than would ideally follow the Apache model. (Sample: what are we going to do about these JIRAs?) However, it was useful to reach quick decisions on these and the chat seemed to be a reasonable way to do this. The current time is OK for me. Simon ant elder wrote: AFAICT no one has suggested a ban on IRC, what I'm trying to find out is if we should be continuing with the regularly scheduled weekly chat. If enough people don't think we should be having it then we should stop. Thats a perfectly fine thing to happen if thats what the community want, but its not going to get stopped unless those who don't think we should be having it speak up clearly. That's what this thread is about - Are people happy with having our current weekly hour long IRC chat? ...ant -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
On Jul 5, 2006, at 11:10 AM, haleh mahbod wrote: IRC has been a useful tool for timely community brainstorming to handle issues that need quick attention. Right. That was the basis for saying IRC should be an impromptu, consensus building mechanism - there's no need to wait for a scheduled time to have these types of discussions. However, if we're using IRC that way, what do we get from a scheduled weekly session? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] DAS: Add ability to manage OCC columns
The attached patch adds the ability to have the DAS manage collision
columns. Currently this is implemented with a managed attribute on
column -- there may be some room for improvement here, as having
managed and collision on Column doesn't seem all that intuitive.
Also, the first cut only supports Integer columns. We should identify
which types need to be supported. Are there any beyond numeric types
and date/timestamp?
Index: src/test/java/org/apache/tuscany/das/rdb/test/OCCTests.java
===
--- src/test/java/org/apache/tuscany/das/rdb/test/OCCTests.java (revision
418312)
+++ src/test/java/org/apache/tuscany/das/rdb/test/OCCTests.java (working copy)
@@ -55,4 +55,48 @@
throw ex;
}
}
+
+ public void testManagedOCC() throws Exception {
+ DAS das =
DAS.FACTORY.createDAS(getConfig(ManagedBooksConfig.xml), getConnection());
+ Command select = das.getCommand(select book 1);
+ DataObject root = select.executeQuery();
+ DataObject book = root.getDataObject(BOOK[1]);
+ //Change a field to mark the instance 'dirty'
+ book.setInt(QUANTITY, 2);
+ int occValue = book.getInt(OCC);
+ das.applyChanges(root);
+
+ root = select.executeQuery();
+ book = root.getDataObject(BOOK[1]);
+ assertEquals(occValue + 1, book.getInt(OCC));
+ }
+
+ public void testManagedOCCFailure() throws Exception {
+ DAS das =
DAS.FACTORY.createDAS(getConfig(ManagedBooksConfig.xml), getConnection());
+ //Read a book instance
+Command select = das.getCommand(select book 1);
+ DataObject root = select.executeQuery();
+ DataObject book = root.getDataObject(BOOK[1]);
+ //Change a field to mark the instance 'dirty'
+ book.setInt(QUANTITY, 2);
+
+
+ DAS das2 =
DAS.FACTORY.createDAS(getConfig(ManagedBooksConfig.xml), getConnection());
+ //Read a book instance
+Command select2= das2.getCommand(select book 1);
+ DataObject root2 = select2.executeQuery();
+ DataObject book2 = root2.getDataObject(BOOK[1]);
+ //Change a field to mark the instance 'dirty'
+ book2.setInt(QUANTITY, 5);
+ das2.applyChanges(root2);
+
+//Try to apply changes an catch the OCC Exception
+ try {
+ das.applyChanges(root);
+ fail(An OCCException should be thrown);
+ } catch (RuntimeException ex) {
+ if ( !ex.getMessage().equals(OCC Exception) )
+ throw ex;
+ }
+ }
}
Index: src/test/resources/ManagedBooksConfig.xml
===
--- /dev/null (revision 0)
+++ src/test/resources/ManagedBooksConfig.xml (revision 0)
@@ -0,0 +1,27 @@
+?xml version=1.0 encoding=ASCII?
+!--
+ Copyright (c) 2005 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.
+ --
+Config
xsi:noNamespaceSchemaLocation=http:///org.apache.tuscany.das.rdb/config.xsd;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+
+Command name=select book 1 SQL=select * from BOOK where BOOK_ID = 1
kind=Select/
+Command name=update book 1 SQL=update BOOK set OCC = ? where BOOK_ID =
1 kind=Update/
+
+ Table tableName=BOOK
+Column columnName=BOOK_ID primaryKey=true/
+ Column columnName=OCC collision=true managed=true/
+/Table
+
+/Config
Index: src/main/java/org/apache/tuscany/das/rdb/impl/ParameterImpl.java
===
--- src/main/java/org/apache/tuscany/das/rdb/impl/ParameterImpl.java
(revision 417540)
+++ src/main/java/org/apache/tuscany/das/rdb/impl/ParameterImpl.java
(working copy)
@@ -42,7 +42,7 @@
private int index;
private Type type;
private String name;
- private Object value;
+ protected Object value = null;
private int direction = IN;
private Converter converter;
@@ -121,4 +121,6 @@
buffer.append(\nValue: + getValue());
Re: Proposed approach for M2
Jim Marino wrote: On Jul 3, 2006, at 5:34 AM, ant elder wrote: One of the big reasons for me is summed up well in Sebastien's proposal: This will get our community members involved in building the runtime together and will lead to a wider knowledge base that makes it possible to quickly implement new functionality in the future. It will also build a community knowledge base that is ready to help new community members come on board quickly. I struggle with understanding the what and why of parts of the sandbox code and hope bringing small bits over one step at a time will help with this. Could you outline specifically what you don't understand. Perhaps we could do another code walkthrough like we did about a month ago? Why don't you like this approach? Sure it may take a bit more time but if in the long run we end up with more people understanding the runtime that seems like time well spent even if we end up with most of the trunk being just whats in the sandbox today. The key point is I like Jeremy's approach better. The thought of merging M1 with the sandbox code (Sebastien's proposal) doesn't seem to fit based on my technical knowledge of both code bases. More importantly, Jeremy's approach strike me as better. Since I have outlined my reasoning in previous posts (not just technical) why I think it is better,I won't repeat them here, as it will just confuse the ongoing threads. My proposal is not to merge M1 and the core2 sandbox. I am proposing to start a new fresh code stream and build the runtime through baby steps. We may be able to reuse some pieces of existing code, but more important is to engage our community in this exercise and integrate the new ideas that will emerge from this. Here's an example where I'm struggling with both M1 and the core2 sandbox and thinking that we can do better if we start with a new fresh stream: our (recursive) assembly metadata model. - M1 does not implement the recursive composition model and would require significant changes to support it. Core2 is an attempt to implement it but I'm not sure it's quite right, and also think that it can be simplified. - M1 used Lists to represent relationships, Core2 uses Maps, I think M1 was better since it allowed to keep the order in the relationships. - Core2 only defines implementation classes for the model, I think we should have interfaces + default implementation classes instead, like we had in M1, to allow for alternate implementations of the model. - Over usage of Java Generics breaks flexibility in some cases, for example ComponentI extends Implementation will force you to recreate an instance of Component to swap its implementation with an implementation of a different type (and lose all the wires going in/out of the component). - Core2 defines ReferenceDefinitions (without bindings) and BoundReferenceDefinitions (with bindings). IMO there are Reference types and Reference instances and both can have bindings. or Reference. - I think that Remotable should be on Interface and not Service. - Scope should be defined in the Java component implementation, separate from the core model. - Java and WSDL interfaces should be defined separate from the core model, we need to support multiple interface definition languages supported by plugins, not in the core. - Implementation should extend ComponentType IMO instead of pointing to it, and we may even be able to simplify and just remove Implementation. Also I am not sure why we need to distinguish between AtomicImplementation and CompositeImplementation. - Support for Composite Includes is missing, this is a significant part of the recursive composition model (half of it, one of the two ways to nest composites). This list is not exhaustive... Another idea would be to externalize support for Composites in a separate plugin not part of the core service model (since there may be other ways to compose services in addition to an SCA composite, with Spring or other similar programming models), I'd like to know what people think about that. I just checked in sandbox/sebastien/m2-design/model.spi a set of new interfaces. This is just an initial strawman to trigger a constructive discussion and ideas on how to best represent the recursive model. I also need help to define a scenario (not unit test cases, but an end to end sample application) to help put the recursive composition model in perspective and make sure we all understand it the same way. Comments, feedback and help are welcome... So, to turn it around a bit, as I've already outlined some of my reasons for liking Jeremy's approach more, do you have additional reasons other than you are having difficulty understanding the sandbox code and your feeling it will be a worthwhile exercise in knowledge sharing? Regarding the later, I think it's better (and more inclusive) to make a concerted effort to modularize and bring people into
Re: Tuscany Icon
The cypress on the hill motif is pretty cool and it doesn't need to be too busy - take a look at http://www.tuscanystyle.it/index.html for an example of how it can be stylized. --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tuscany Icon
I really liked the wine stain on the white background. That was pretty clever, simple, evocative, etc. Plus it'd look really cool on a white tee shirt, and it makes branding of cocktail napkin-based design documents really easy. :-) -Original Message- From: Oisin Hurley [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 4:42 PM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany Icon The cypress on the hill motif is pretty cool and it doesn't need to be too busy - take a look at http://www.tuscanystyle.it/index.html for an example of how it can be stylized. --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
Hi Jim, Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to attend the IRC chat tomorrow. In the meantime, some more quick comments. - Original Message - snip/ If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, Right, for the local scenario, I was thinking the callback instance would be put on the thread local context and the proxy would access it from there as opposed to going out over a socket and back in through a listener. Basically, it would be an optimization of the remote case. I think we can further optimize things depending on scopes, e.g. if the callback scope is module, we could possibly avoid threadlocal storage and have the proxy hold on to an instance directly. Pointing at the callback instance directly from the proxy would eliminate invocation chains and the ability to add interceptors to them, wouldn't it? Also, I'm not sure using a thread local in the core is a good idea if an intention is to allow the core to be embeddable in, for instance, a managed environment, as thread local does not necessarily mix well with thread pools. snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tuscany Icon
Cheers! -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 5:45 PM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany Icon On 05/07/06, Hawkins, Joel [EMAIL PROTECTED] wrote: I really liked the wine stain on the white background. That was pretty clever, simple, evocative, etc. Plus it'd look really cool on a white tee shirt, and it makes branding of cocktail napkin-based design documents really easy. :-) I always thought that a single cypress tree with no writing was the best... but now I really like the wine stain. I can supply custom stained shirts ;-) -- Pete The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
C++ M1 Release Candidate
I have posted a candidate for the first C++ release here. http://people.apache.org/~robbinspg/RC1 Would all interested parties take some time to review this so that we can either re-spin the release or vote on it asap. The website documentation is out of date and will be re-written to sync with what is in the release. Hopefully this will be done tomorrow. A Calculator sample is included which demonstrates deploying an SCA module, component wiring, locating and invoking C++ service from C++ component, invoking from a C++ client, and exposing a service as a web service using ws binding. Release Summary = Tuscany SCA C++ provides a runtime implementation for the Service Component Architecture 0.9 specification, written in C++ and will currently support C++ component implementation types. This is not yet a complete implementation and known restrictions are described below. Supported SCA Assembly Model features * All features are supported unless listed under the known restrictions below. See SCA Assembly Model specification. Supported language bindings * Component implementations written in C++. See SCA Client and Implementation Model specification. * Component interfaces described by C++ classes. See SCA Client and Implementation Model specification. Supported external service and entry point bindings * The web service binding is supported. This implementation will support web services which using document literal SOAP bindings conforming to the WS-I basic profile (rpc/encoded is not yet supported). Known restrictions * Subsystem: wiring, entry points and external services are not supported. * Local service interfaces cannot use overloaded operations (the SCA specification limits remote service interfaces to not using overloaded operations). * Each WSDL definition for a web service binding must be in a single WSDL document. * No load time validation of the deployed SCA application (run time validation only). * No metadata API. -- Pete
[jira] Updated: (TUSCANY-520) built script cannont handle working directory paths that contain spaces
[ http://issues.apache.org/jira/browse/TUSCANY-520?page=all ] David Wheeler updated TUSCANY-520: -- Attachment: 520-patch.txt Patch for build-dist.bat for paths that include spaces. built script cannont handle working directory paths that contain spaces --- Key: TUSCANY-520 URL: http://issues.apache.org/jira/browse/TUSCANY-520 Project: Tuscany Type: Bug Components: Build System Environment: Windows XP Reporter: David Wheeler Attachments: 520-patch.txt If the current directory path when calling build-dist contains spaces maven exits with the error: [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'and': you must specify a valid lifecycle phase, or a goal i n the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] where 'and' is the first word after the space in the path. Changing the following line from build-dist.bat from: call mvn -Dtuscany.home=%TUSCANY_HOME% %1 clean install -Dmaven.test.skip=true to call mvn -Dtuscany.home=%TUSCANY_HOME% %1 clean install -Dmaven.test.skip=true allows the script to run but the following errors occur. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.sun.xml:saaj-impl:jar:1.3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun.xml -DartifactId=saaj-impl \ -Dversion=1.3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating -M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) com.sun.xml:saaj-impl:jar:1.3 2) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.jws -DartifactId=jsr181-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating -M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 3) javax.xml:saaj-api:jar:1.3 Try downloading the file manually from: https://jax-ws.dev.java.net/files/documents/4202/24765/JAXWS_SI_20051128.j ar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=saaj-api \ -Dversion=1.3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating -M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.xml:saaj-api:jar:1.3 4) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jaxws-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating -M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-api:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 5) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.annotation -DartifactId=jsr250-ap i \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating -M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-api:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 -- 5 required artifacts are missing. for artifact: org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 from the specified remote repositories: central (http://repo1.maven.org/maven2), ibiblio (http://www.ibiblio.org/maven2), objectweb (http://maven.objectweb.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly
Re: Whats required to become a Tuscany Committer?
On Jul 5, 2006, at 4:42 PM, Raymond Feng wrote: Hi, I guess I can understand how to get credits for the committer status. As a contributor, I would like to see a well-defined measurable path which I can see how I make progresses toward the goal. It leads two questions: 1) How many points do we need to gain to become a committer? 2) How do we measure the contributions? Is it just an impression or sense from existing committers or do we run some statistics once a while? It's about trust so hard-facts don't tell all the story - it really is about what the existing committers think. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Do we plan to move to JUnit 4.1?
On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote: I'm wondering if we plan to move to JUnit 4.1? I see more flexibilities and simplicities offered by JUnit 4.x. Now I can also use the wizards from Eclipse 3.2 to take advantage of it. Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not sure if maven 2.0.4 supports it. We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the lack of maven support. Can you find out if that has changed? If it has it might be worth upgrading. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
On Jul 5, 2006, at 11:37 AM, Jeremy Boynes wrote: On Jul 5, 2006, at 11:10 AM, haleh mahbod wrote: IRC has been a useful tool for timely community brainstorming to handle issues that need quick attention. Right. That was the basis for saying IRC should be an impromptu, consensus building mechanism - there's no need to wait for a scheduled time to have these types of discussions. Of course, this kind of approach only works if people can be contacted on IRC - very few people were on the channel today and I have the impression that is fairly typical. Where do Tuscany folk hang out? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email versus IRC
+1 for including DAS related topics on the IRC Chats. - Luciano ant elder [EMAIL PROTECTED] 07/05/2006 06:47 AM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Email versus IRC There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-518) Mapping Complex Type XSD that allows mixed content (mixed=true)
[ http://issues.apache.org/jira/browse/TUSCANY-518?page=all ] Frank Budinsky resolved TUSCANY-518: Resolution: Duplicate See TUSCANY-521 Mapping Complex Type XSD that allows mixed content (mixed=true) --- Key: TUSCANY-518 URL: http://issues.apache.org/jira/browse/TUSCANY-518 Project: Tuscany Type: Sub-task Components: Java SDO Tools Versions: Java-Mx Reporter: Venkatakrishnan 1. The generated SDO Type ends up with a property named 'mixed', whereas the attributed 'mixed=true' is only to be interpretted to set the 'sequenced=true' for the SDO and not to be 'tranlated' into a property of the SDO. Workaround : When mapping the SDO to XSD, we could skip properties with name as 'mixed' or skip if the property's data type is a EFeatureMapEntry. In the first case we might run into problems if there was actually a property named 'mixed' ( for example an element named 'mixed' in the xsd from which the SDOs were generated in the first place). In the second case we will be have to go one level down to Meta Modeling Facility over which the SDOs are implemented i.e EMF and in my opinion the SDO-XSD converter will go for a toss if we decide to change it is modeled over EMF. 2. According to the specs (starting from Pg 107 onwards) if isSequenced is true for an SDO, then it is to be interpretted as complex type xsd that allows mixed content and the properties of the SDO are to be placed as content inside a repeating choice i.e. xsd:choice maxOccurs=unbounded within this complex type. Hence it ends up that the following two definitions are equivalent... xsd:sequence xsd:element name=symbol type=xsd:string / xsd:element name=companyName type=xsd:string / xsd:element name=price type=xsd:decimal / xsd:element name=open1 type=xsd:decimal / xsd:element name=high type=xsd:decimal / xsd:element name=low type=xsd:decimal / xsd:element name=volume type=xsd:double / xsd:element name=change1 type=xsd:double / xsd:element maxOccurs=unbounded minOccurs=0 name=quotes type=seq:MixedQuote / /xsd:sequence xsd:choice maxOccurs=unbounded xsd:element name=symbol type=xsd:string / xsd:element name=companyName type=xsd:string / xsd:element name=price type=xsd:decimal / xsd:element name=open1 type=xsd:decimal / xsd:element name=high type=xsd:decimal / xsd:element name=low type=xsd:decimal / xsd:element name=volume type=xsd:double / xsd:element name=change1 type=xsd:double / xsd:element maxOccurs=unbounded minOccurs=0 name=quotes type=seq:MixedQuote / /xsd:choice -- 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-516) Annotating generated SDO Types for the associated 'Factory' and 'Package' generated classes
[ http://issues.apache.org/jira/browse/TUSCANY-516?page=comments#action_12419389 ] Frank Budinsky commented on TUSCANY-516: I'm not sure I understand this request. Please provide more details and an example. Thanks. Annotating generated SDO Types for the associated 'Factory' and 'Package' generated classes --- Key: TUSCANY-516 URL: http://issues.apache.org/jira/browse/TUSCANY-516 Project: Tuscany Type: Sub-task Components: Java SDO Tools Versions: Java-Mx Reporter: Venkatakrishnan The SDO needs to be instantiated to obtain a more reliable information about it type using the 'getType' method. To minimize user inputs in aid of this instantiation, it would be good to have an annotation added to the generated SDO, pointing to the Factory class for the SDO. Work Around : Currently, the protected constructor of the input SDO class is invoked using Java Reflection APIs. This is not an ok approach as we break the access and then invoke the constructor. Also, if the input is the SDO Type Interface then this work around will fail. If having the Factory class information sound ok, then we could also have the Package class information. I am sure we are going to need this somewhere down the line. -- 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: Do we plan to move to JUnit 4.1?
Hmm, it seems that Surefire plugin 2.2 doesn't support JUnit 4.x yet. Here's the JIRA issue for the topic: http://jira.codehaus.org/browse/SUREFIRE-31 Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 05, 2006 6:10 PM Subject: Re: Do we plan to move to JUnit 4.1? On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote: I'm wondering if we plan to move to JUnit 4.1? I see more flexibilities and simplicities offered by JUnit 4.x. Now I can also use the wizards from Eclipse 3.2 to take advantage of it. Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not sure if maven 2.0.4 supports it. We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the lack of maven support. Can you find out if that has changed? If it has it might be worth upgrading. -- 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: Do we plan to move to JUnit 4.1?
Hi, We don't have problems with JDK 5 + Maven 2 and in fact the combination is used in the code base now. I'm looking for the new features such as annotation support from JUnit 4.x. Thanks, Raymond - Original Message - From: Eddie O'Neil [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 05, 2006 8:55 PM Subject: Re: Do we plan to move to JUnit 4.1? Raymond-- What aspect of JDK 5 + Maven2 support are you concerned about? I've used this combination quite a bit with good success, but I suppose it depends on what you're using it for. Eddie On 7/5/06, Raymond Feng [EMAIL PROTECTED] wrote: Hmm, it seems that Surefire plugin 2.2 doesn't support JUnit 4.x yet. Here's the JIRA issue for the topic: http://jira.codehaus.org/browse/SUREFIRE-31 Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 05, 2006 6:10 PM Subject: Re: Do we plan to move to JUnit 4.1? On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote: I'm wondering if we plan to move to JUnit 4.1? I see more flexibilities and simplicities offered by JUnit 4.x. Now I can also use the wizards from Eclipse 3.2 to take advantage of it. Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not sure if maven 2.0.4 supports it. We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the lack of maven support. Can you find out if that has changed? If it has it might be worth upgrading. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
