RE: Repo config, was: Question on the Tuscany dependency extension in SCDL
Pls see comments below -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12 October 2006 02:37 To: tuscany-dev@ws.apache.org Subject: Repo config, was: Question on the Tuscany dependency extension in SCDL On Oct 11, 2006, at 4:57 PM, Simon Nash wrote: Thanks. Using the local maven repo is convenient for maven users, and adding full maven support (transitive dependency resolution and automatic downloading) to the standalone environment is a significant improvement for these users. However, I'm a bit concerned about requiring all users of the standalone environment to use maven downloading or have a local maven repo in order to get these dependencies resolved. For M2 it's probably best to do it this way for both the webapp and standalone environments and document how this works. (I will add this to the Basic Instructions document that I'm writing.) After M2 I'd like to consider what we could do for users who for whaetever reason aren't bought into maven. The online repo is a good resource even if you are not using Maven as a build system. For example, someone using Ant can download jars or whatever by hand from one place rather than having to look at a number of different download sites. MavenProxy and other mirror systems also allow it to be replicated inside a firewall and populated with an organization's proprietary resources. For the webapp, the download service (I believe) also looks in the war first under /WEB-INF/tuscany/repository/ so people who want everything packaged in one archive can still do so. They don't have to use the war plugin to get those resources there, any decent build tool/IDE should be able to do that. And, of course, that's just the default impl for the ArtifactRepository - a user can replace it with one of their choosing. That's right, at least in theory :-) I would imagine the same thing would work in the standalone environment if we replaced the current simple impl with the full Maven-based one that the webapp uses. I think the impl just looks relative to the baseURL returned from the RuntimeInfo so it should work the same way. There's an option in the assembly plugin to copy artifacts and their dependencies into a repo structure in the assembly so that should be easy to set up as well. This would be worth exploring as a way of including extensions in the distro. +1 These are all config changes. I'm with you that anything more complex should happen after M2. We'll probably need to make a whole bunch of changes anyway when the spec starts to settle on a deployment story. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: companyWeb readme - Fwd: [jira] Assigned: (TUSCANY-827) Update companyweb readme.htm
Hey Luciano, I went ahead and made some updates the readme. I updated some M1 references to M2, removed some of the conversational style (ie, I, my, etc), and removed the references to steps' in the appendix because that seemed confusing, I started from your patch so it should contain your updates. Brent On 10/12/06, Luciano Resende [EMAIL PROTECTED] wrote: HI Brent Could you take a look at the updated version of the companyweb readme and see if that looks better. - Luciano Resende -- Forwarded message -- From: Luciano Resende (JIRA) tuscany-dev@ws.apache.org Date: Oct 11, 2006 5:45 PM Subject: [jira] Assigned: (TUSCANY-827) Update companyweb readme.htm To: tuscany-dev@ws.apache.org [ http://issues.apache.org/jira/browse/TUSCANY-827?page=all ] Luciano Resende reassigned TUSCANY-827: --- Assignee: Luciano Resende Update companyweb readme.htm Key: TUSCANY-827 URL: http://issues.apache.org/jira/browse/TUSCANY-827 Project: Tuscany Issue Type: Improvement Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Attachments: tuscany827.lresende.20061011.txt, tuscany827.lresende.20061011.zip Need to update the readme.htm based on the feedback from DAS M2 RC2 http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00268.html -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weak wiki-fu
Here's what seems to be everything you could ever want to know about linking on the moinmoin wiki implementation. http://moinmoin.wikiwikiweb.de/HelpOnLinking?highlight=%28%5EHelp.%2A%29 Cheers, Kelvin. On 11/10/06, Kevin Williams [EMAIL PROTECTED] wrote: I am having some trouble setting up links between pages in our wiki. When linking to child pages I have followed examples I have seen on our wiki and do something like this: * [wiki:/Convention_over_configuration Convention over configuration] So, the syntax is : [wiki:/some_child_page child page alias]. This works great when I want to link to a child page. But, I often want to link to a page somewhere else in the hierarchy and I was hoping I could refer to a peer page like this: * [wiki:../some_peer_page peer page alias] But, this does not work. The only way I have found to link to a non-child page is to use the full URL like this: * [ http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/Improved_logging Logging] This works but makes the link appear to be to an external page rather than a page within our own wiki. I think I must be missing something due to my weak wiki-fu. Any help would be appreciated. -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime Implementation not found when running sample Webapps
Ken was working on some fixes for the webapp runtime stuff but his HD crashed last week. I'm not sure what status the actual committed source code is in, but it was working (or pretty close) when I tried it last week. andy At 23:35 11/10/2006, Bert Lamb wrote: I just updated to HEAD today (clean source tree, clean local maven repo) and I am trying to run the helloworldjsonrpc and the helloworldws samples and I am getting the following when trying to deploy them in Tomcat. My gut is telling me that the tuscany war plugin has misplaced a jar or something, but I am not sure how to track that down. Any ideas? SEVERE: Runtime Implementation not found org.apache.tuscany.runtime.webapp.TuscanyInitException: Runtime Implementation n ot found at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:75) at org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextIniti alized(TuscanyContextListener.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698 ) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442 ) at org.apache.catalina.core.StandardService.start(StandardService.java:4 50) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709 ) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.ClassNotFoundException: org.apache.tuscany.runtime.webapp.W ebappRuntimeImpl at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:68) ... 25 more Oct 11, 2006 6:29:58 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Exception sending context initialized event to listener instance of clas s org.apache.tuscany.runtime.webapp.TuscanyContextListener org.apache.tuscany.runtime.webapp.TuscanyInitException: Runtime Implementation n ot found at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:75) at org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextIniti alized(TuscanyContextListener.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698 ) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
Re: SDO Java: Getting Involved -- Tests/Samples
Tom, Welcome to Tuscany! that's great! Thanks for offering to get involved. How should we proceed? I'd be most happy to assist you to integrate what you have to offer. We currently have a small collection of tests using the junit framework (see https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/) but there's significant scope for enhancement. BTW I'm going to make my response Java centric as Andrew has offered to help look at the C++ side of things. How about this for a proposal for how to proceed? I have opened a JIRA (this is our issue or bug tracking system if you are not familiar with these things --- please tell me if you are already an expert). The JIRA can be seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you can upload attachments to the JIRA, so we could perhaps use that to first attach a typical RogueWave test or two. I guess it's likely that there will be some modifications that need to be made with regards to setting up the test within our environment, but that way we could play and discuss how we might proceed with more tests. How does that sound? Best Regards, Kelvin. On 11/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Tom, Coming from the C++ side of Tuscany, I know we'd certainly be interested in those C++ SDO tests - please get involved! Cheers Andrew On 10/11/06, T Gould [EMAIL PROTECTED] wrote: Kelvin - We at Rogue Wave have been developing an SDO product, HydraSDO, and have a seires of tests that might be easiliy modified so as to exercise your Java SDO product. We would be very interested in providing our tests as well as helping create a test environment (unless this has already been done) to futher test the SDO product. Additionally, we also have C++ tests. tom gould --- As the Java M2 release is imminent it occured to me that it would be really useful if there are users out there who are putting our code through its paces that you may be developing samples/tests which could usefully be contributed back to the Tuscany project and make it more robust. If you are in such a position it would be really great to hear from you. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stabilizing M2 for release
At 00:49 12/10/2006, Jeremy Boynes wrote: I am not sure on whether javascript, jsonrpc, ruby or spring fall in this category or the next - opinions? Spring is stable enough IMO. I have some changes planned, but probably not in time for M2 and the existing code works ok (and is mostly structured ok). andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java: Getting Involved -- Tests/Samples
Reading Tom's note, Rogue Wave have Java and C++ tests. Do we need a separate JIRA for any C++ related work? Geoff. On 12/10/06, kelvin goodson [EMAIL PROTECTED] wrote: Tom, Welcome to Tuscany! that's great! Thanks for offering to get involved. How should we proceed? I'd be most happy to assist you to integrate what you have to offer. We currently have a small collection of tests using the junit framework (see https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/ ) but there's significant scope for enhancement. BTW I'm going to make my response Java centric as Andrew has offered to help look at the C++ side of things. How about this for a proposal for how to proceed? I have opened a JIRA (this is our issue or bug tracking system if you are not familiar with these things --- please tell me if you are already an expert). The JIRA can be seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you can upload attachments to the JIRA, so we could perhaps use that to first attach a typical RogueWave test or two. I guess it's likely that there will be some modifications that need to be made with regards to setting up the test within our environment, but that way we could play and discuss how we might proceed with more tests. How does that sound? Best Regards, Kelvin. On 11/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Tom, Coming from the C++ side of Tuscany, I know we'd certainly be interested in those C++ SDO tests - please get involved! Cheers Andrew On 10/11/06, T Gould [EMAIL PROTECTED] wrote: Kelvin - We at Rogue Wave have been developing an SDO product, HydraSDO, and have a seires of tests that might be easiliy modified so as to exercise your Java SDO product. We would be very interested in providing our tests as well as helping create a test environment (unless this has already been done) to futher test the SDO product. Additionally, we also have C++ tests. tom gould --- As the Java M2 release is imminent it occured to me that it would be really useful if there are users out there who are putting our code through its paces that you may be developing samples/tests which could usefully be contributed back to the Tuscany project and make it more robust. If you are in such a position it would be really great to hear from you. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime Implementation not found when running sample Webapps
Well, I wish I had some sort of clue as to what I did to fix it, but it seems to be working now in my environment, and rfeng never saw it broken in his, so I'll assume it was something dumb I did :) Thanks everyone. -Bert On 10/12/06, Andy Piper [EMAIL PROTECTED] wrote: Ken was working on some fixes for the webapp runtime stuff but his HD crashed last week. I'm not sure what status the actual committed source code is in, but it was working (or pretty close) when I tried it last week. andy At 23:35 11/10/2006, Bert Lamb wrote: I just updated to HEAD today (clean source tree, clean local maven repo) and I am trying to run the helloworldjsonrpc and the helloworldws samples and I am getting the following when trying to deploy them in Tomcat. My gut is telling me that the tuscany war plugin has misplaced a jar or something, but I am not sure how to track that down. Any ideas? SEVERE: Runtime Implementation not found org.apache.tuscany.runtime.webapp.TuscanyInitException: Runtime Implementation n ot found at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:75) at org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextIniti alized(TuscanyContextListener.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698 ) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442 ) at org.apache.catalina.core.StandardService.start(StandardService.java:4 50) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709 ) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.ClassNotFoundException: org.apache.tuscany.runtime.webapp.W ebappRuntimeImpl at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:68) ... 25 more Oct 11, 2006 6:29:58 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Exception sending context initialized event to listener instance of clas s org.apache.tuscany.runtime.webapp.TuscanyContextListener org.apache.tuscany.runtime.webapp.TuscanyInitException: Runtime Implementation n ot found at org.apache.tuscany.runtime.webapp.WebappUtilImpl.getRuntime(WebappUti lImpl.java:75) at org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextIniti alized(TuscanyContextListener.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698 ) at
[jira] Created: (TUSCANY-830) Use namespace prefixes from XSD during serialization
Use namespace prefixes from XSD during serialization Key: TUSCANY-830 URL: http://issues.apache.org/jira/browse/TUSCANY-830 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Priority: Minor I just found out XMLHelper.save() method always uses the dataobject's namespace URI to derive its namespace prefix even the prefix has been defined in the XSD. For example, I modify xmlns:nsPrefix=nsURI in the simple.xsd located in the resource folder under sdo/impl project from xmlns:simple=http://www.example.com/simple; to xmlns:simple=http://www.example.com/simple/1.0; then modify SimpleDynamicTestCase.javato display its serialization output. Here are the XSD and the serialization output: *simple.xsd* xsd:schema targetNamespace=http://www.example.com/simple/1.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:simple=http://www.example.com/simple/1.0; xsd:element name=stockQuote type=simple:Quote/ xsd:complexType name=Quote 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 name=quotes type=simple:Quote minOccurs=0 maxOccurs=unbounded/ /xsd:sequence /xsd:complexType /xsd:schema *Serialization output* ?xml version=1.0 encoding=ASCII? _1:stockQuote xmlns:_1=http://www.example.com/simple/1.0; symbolfbnt/symbol companyNameFlyByNightTechnology/companyName price1000.0/price open11000.0/open1 low1000.0/low volume1000.0/volume change11000.0/change1 quotes price2000.0/price /quotes /_1:stockQuote -- 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: Potential Java SDO Serialization Bug
Thanks, Yang. I have opened TUSCANY-830 to track this improvement. Yang ZHONG [EMAIL PROTECTED] wrote: XSD prefixes are *not* parts of the definitions. It may be nice for XML to use the original prefixes, however different ones must be used instead if ever conflicted. _1 may be ugly, but it doesn't disconform to the XSD. Do you want to change bug to improvement? On 10/11/06, Fuhwei Lwo wrote: I just found out XMLHelper.save() method always uses the dataobject's namespace URI to derive its namespace prefix even the prefix was defined in the XSD. For example, I modify xmlns:nsPrefix=nsURI in the simple.xsd located in the resource folder under sdo/impl project from xmlns:simple= http://www.example.com/simple; to xmlns:simple= http://www.example.com/simple/1.0; then modify SimpleDynamicTestCase.javato display its serialization output. Here are the XSD and the serialization output: *simple.xsd* targetNamespace=http://www.example.com/simple/1.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:simple=http://www.example.com/simple/1.0; minOccurs=0 maxOccurs=unbounded/ *Serialization output* _1:stockQuote xmlns:_1=http://www.example.com/simple/1.0; fbnt FlyByNightTechnology 1000.0 1000.0 1000.0 1000.0 1000.0 2000.0 Is this expected behaviour? -- Yang ZHONG
[jira] Created: (TUSCANY-831) hellowordws
hellowordws --- Key: TUSCANY-831 URL: http://issues.apache.org/jira/browse/TUSCANY-831 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Critical Fix For: Java-M2 hellowordws sample webapp does not load in tomcat receives org.apache.tuscany.databinding.sdo.ImportSDOLoader exception. -- 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-831) hellowordws
[ http://issues.apache.org/jira/browse/TUSCANY-831?page=all ] Rick Rineholt updated TUSCANY-831: -- Attachment: localhost.2006-10-12.log stack trace of hellowordws hellowordws --- Key: TUSCANY-831 URL: http://issues.apache.org/jira/browse/TUSCANY-831 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Critical Fix For: Java-M2 Attachments: localhost.2006-10-12.log hellowordws sample webapp does not load in tomcat receives org.apache.tuscany.databinding.sdo.ImportSDOLoader exception. -- 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: Runtime Implementation not found when running sample Webapps
Hi, I just tried to load helloworldws in quite some time and I receive another error org.apache.tuscany.databinding.sdo.ImportSDOLoader Just on quick inspection I've notice that it's pom.xml is referencing a wrong version of axiom-api. Not sure why it's even directly needing that. I've opened Jira http://issues.apache.org/jira/browse/TUSCANY-831 Bert Lamb wrote: Here is the output for the helloworldws sample: D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\MANIFEST.MF D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.properties D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\sca\default.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\binding.axis2.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.axiom.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.sdo.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\interface.wsdl.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\webapp.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\web.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldImpl.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldService.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\LICENSE.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\NOTICE D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\README.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworld.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworldOM.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\activation-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\axiom-api-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\commons-logging-1.0.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\jaxen-1.1-beta-9.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\mail-1.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sca-api-r0.95-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sdo-api-r2.0.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\stax-api-1.0.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\webapp-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xercesImpl-2.6.2.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xml-apis-1.3.03.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\classworlds-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commonj-api_r1.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commons-cli-1.0.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\core-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\doxia-sink-api-1.0-alpha-7.jar
Re: Runtime Implementation not found when running sample Webapps
Yep, I'm seeing this too. I should have been more specific, my problems with the jsonrpc sample were the ones that resolved themselves. -Bert On 10/12/06, Rick [EMAIL PROTECTED] wrote: Hi, I just tried to load helloworldws in quite some time and I receive another error org.apache.tuscany.databinding.sdo.ImportSDOLoader Just on quick inspection I've notice that it's pom.xml is referencing a wrong version of axiom-api. Not sure why it's even directly needing that. I've opened Jira http://issues.apache.org/jira/browse/TUSCANY-831 Bert Lamb wrote: Here is the output for the helloworldws sample: D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\MANIFEST.MF D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.properties D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\sca\default.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\binding.axis2.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.axiom.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.sdo.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\interface.wsdl.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\webapp.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\web.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldImpl.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldService.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\LICENSE.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\NOTICE D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\README.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworld.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworldOM.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\activation-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\axiom-api-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\commons-logging-1.0.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\jaxen-1.1-beta-9.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\mail-1.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sca-api-r0.95-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sdo-api-r2.0.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\stax-api-1.0.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\webapp-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xercesImpl-2.6.2.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xml-apis-1.3.03.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\classworlds-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commonj-api_r1.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commons-cli-1.0.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\core-1.0-incubator-M2-SNAPSHOT.jar
[jira] Created: (TUSCANY-832) Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree
Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree Key: TUSCANY-832 URL: http://issues.apache.org/jira/browse/TUSCANY-832 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo The XSD anyURI type is mapped to SDO URI type with sdo:propertyType annotation. When I used the SDO URI type property to reference a DataObject in a different tree and tried to serialize it, I would get the exception below. Exception in thread main org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.endSave(XMLSaveImpl.java:284) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:247) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:988) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(XMLDocumentImpl.java:183) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:107) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:102) at AnyURITest.testAnySimpleType(AnyURITest.java:45) at AnyURITest.main(AnyURITest.java:29) Caused by: org.eclipse.emf.ecore.xmi.DanglingHREFException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.handleDanglingHREF(XMLHelperImpl.java:680) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:711) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReference(XMLSaveImpl.java:1874) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReferenceSingle(XMLSaveImpl.java:1917) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1420) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2458) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1032) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:918) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementFeatureMap(XMLSaveImpl.java:2208) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1351) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:624) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:549) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) ... 7 more -- 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-832) Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree
[ http://issues.apache.org/jira/browse/TUSCANY-832?page=all ] Fuhwei Lwo updated TUSCANY-832: --- Attachment: anyURI.xsd AnyURITest.java Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree Key: TUSCANY-832 URL: http://issues.apache.org/jira/browse/TUSCANY-832 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Attachments: anyURI.xsd, AnyURITest.java The XSD anyURI type is mapped to SDO URI type with sdo:propertyType annotation. When I used the SDO URI type property to reference a DataObject in a different tree and tried to serialize it, I would get the exception below. Exception in thread main org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.endSave(XMLSaveImpl.java:284) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:247) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:988) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(XMLDocumentImpl.java:183) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:107) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:102) at AnyURITest.testAnySimpleType(AnyURITest.java:45) at AnyURITest.main(AnyURITest.java:29) Caused by: org.eclipse.emf.ecore.xmi.DanglingHREFException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.handleDanglingHREF(XMLHelperImpl.java:680) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:711) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReference(XMLSaveImpl.java:1874) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReferenceSingle(XMLSaveImpl.java:1917) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1420) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2458) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1032) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:918) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementFeatureMap(XMLSaveImpl.java:2208) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1351) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:624) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:549) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) ... 7 more -- 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]
[VOTE] Release parent pom and buildtools (take 2)
New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release parent pom and buildtools (take 2)
I have tested these artifacts against the SDO branch and all was fine, so here's my +1 Regards, Kelvin. On 12/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime Implementation not found when running sample Webapps
Please make sure databinding-sdo extension is there. Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 12, 2006 6:46 AM Subject: Re: Runtime Implementation not found when running sample Webapps Hi, I just tried to load helloworldws in quite some time and I receive another error org.apache.tuscany.databinding.sdo.ImportSDOLoader Just on quick inspection I've notice that it's pom.xml is referencing a wrong version of axiom-api. Not sure why it's even directly needing that. I've opened Jira http://issues.apache.org/jira/browse/TUSCANY-831 Bert Lamb wrote: Here is the output for the helloworldws sample: D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\MANIFEST.MF D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.properties D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\sca\default.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\binding.axis2.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.axiom.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.sdo.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\interface.wsdl.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\webapp.scdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\web.xml D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldImpl.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldService.class D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\LICENSE.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\NOTICE D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\README.txt D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworld.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworldOM.wsdl D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\activation-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\axiom-api-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\commons-logging-1.0.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\jaxen-1.1-beta-9.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\mail-1.4.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sca-api-r0.95-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sdo-api-r2.0.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\stax-api-1.0.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\webapp-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xercesImpl-2.6.2.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xml-apis-1.3.03.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\classworlds-1.1.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commonj-api_r1.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commons-cli-1.0.jar
Re: [VOTE] Release parent pom and buildtools (take 2)
My +1 -- Jeremy On Oct 12, 2006, at 7:55 AM, Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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: [VOTE] Release parent pom and buildtools (take 2)
+1 On 10/12/06, Jeremy Boynes [EMAIL PROTECTED] wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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]
[jira] Commented: (TUSCANY-672) Unable to override systemScdl in a webapp
[ http://issues.apache.org/jira/browse/TUSCANY-672?page=comments#action_12441769 ] Bert Lamb commented on TUSCANY-672: --- I believe this problem has been fixed Unable to override systemScdl in a webapp - Key: TUSCANY-672 URL: http://issues.apache.org/jira/browse/TUSCANY-672 Project: Tuscany Issue Type: Bug Components: Java SCA Common Affects Versions: Java-M2 Environment: WinXP with Tomcat 5.5.17 Reporter: Bert Lamb Fix For: Java-M2 Ok, so the good news is that I got the binding and the sample working when modifying the webapp.system.scdl in webapp-host.jar. I decided it would be cleaner though to create my own copy of webapp.system.scdl (and call it jsonrpc.system.scdl) to put in my hello world webapp. I tried this and modified the web.xml to have context-param param-namesystemScdlPath/param-name param-value/META-INF/sca/jsonrpc.system.scdl/param-value /context-param However, this gives me a Null system SCDL URL Exception thrown. I looked at ServletLauncherListener.java and it looks like the systemScdlPath URL is being loaded with a different classloader than the applicationScdlPath which may be leading to the exception. -- 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: [jira] Created: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
I don't think this is a blocker. If we need to annotate implementation classes in samples for the databinding framework to perform the transformation, we should just release note that this is a temporary thing and will be resolved in a later release. Jim On Oct 12, 2006, at 8:30 AM, Jeremy Boynes wrote: What do we need to do to clear this blocker? -- Jeremy On Oct 11, 2006, at 6:30 AM, ant elder (JIRA) wrote: DataBinding: Is it a concern of Programming Model vs. Assembly? --- Key: TUSCANY-824 URL: http://issues.apache.org/jira/browse/ TUSCANY-824 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Priority: Blocker Fix For: Java-M2 There have been some question about the DataBinding framework and if it should be a concern of the Programming Model vs. Assembly? See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg08679.html and a follow up mention in: http://www.mail-archive.com/tuscany- [EMAIL PROTECTED]/msg09363.html -- 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] - 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: [VOTE] Release parent pom and buildtools (take 2)
+1. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 12, 2006 8:04 AM Subject: Re: [VOTE] Release parent pom and buildtools (take 2) My +1 -- Jeremy On Oct 12, 2006, at 7:55 AM, Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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: Runtime Implementation not found when running sample Webapps
I am also having this problem. The databinding-sdo jar is located at WEB-INF/tuscany/extenstions/ On 10/12/06, Raymond Feng [EMAIL PROTECTED] wrote: Please make sure databinding-sdo extension is there. Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 12, 2006 6:46 AM Subject: Re: Runtime Implementation not found when running sample Webapps Hi, I just tried to load helloworldws in quite some time and I receive another error org.apache.tuscany.databinding.sdo.ImportSDOLoader Just on quick inspection I've notice that it's pom.xml is referencing a wrong version of axiom-api. Not sure why it's even directly needing that. I've opened Jira http://issues.apache.org/jira/browse/TUSCANY-831 Bert Lamb wrote: Here is the output for the helloworldws sample: D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\MANIFEST.MF D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.properties D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\maven\org.apache.tuscany.samples.sca\sample-helloworldws\pom.xml D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\sca\default.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\binding.axis2.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.axiom.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\databinding.sdo.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\interface.wsdl.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\META-INF\tuscany\webapp.scdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\web.xml D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldImpl.class D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\helloworld\HelloWorldService.class D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\LICENSE.txt D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\NOTICE D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\META-INF\README.txt D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworld.wsdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\classes\wsdl\helloworldOM.wsdl D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\activation-1.1.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\axiom-api-1.1.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\commons-logging-1.0.4.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\jaxen-1.1-beta-9.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\mail-1.4.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sca-api-r0.95-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\sdo-api-r2.0.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\stax-api-1.0.1.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\webapp-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xercesImpl-2.6.2.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\lib\xml-apis-1.3.03.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\classworlds-1.1.jar D:\tools\apache- tomcat-5.5.17\webapps\sample-helloworldws-1.0-incubator-M2-SNAPSHOT\WEB-INF\tuscany\boot\commonj-api_r1.1-1.0-incubator-M2-SNAPSHOT.jar D:\tools\apache-
[C++ Wiki] Links on the Tuscany for C++ page broken
The first five links on the Tuscany C++ page on the Wiki ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp) are links to pages on the main Tuscany web site. Unfortunately four of them are broken (see below) - presumably following the recent reorganisation of the main site. - The main tuscany site http://incubator.apache.org/tuscany/ - [image: [WWW]] The installation instructions for SCA and SDO in C++http://incubator.apache.org/tuscany/installcpp.html - [image: [WWW]] The C++ user guide for SCA and SDO in C++http://incubator.apache.org/tuscany/userguidecpp.html - [image: [WWW]] The SCA for C++ Documentationhttp://incubator.apache.org/tuscany/documentationscacpp.html - [image: [WWW]] The SDO for C++ Documentationhttp://incubator.apache.org/tuscany/documentationsdocpp.html It's not obvious how to fix this since, for example, there doesn't seem to be a single page that is the installation instructions for SCA and SDO. Does anyone have any strong opinions about how we re-organise this? I think the bottom two could reasonably be pointed to http://incubator.apache.org/tuscany/cpp_sca_overview.html and http://incubator.apache.org/tuscany/cpp_sdo_overview.html and maybe the third one deleted. Then perhaps the second one should open another Wiki page where we list or link to installation instructions for various combinations of product and platform. I was intending to add instructions on how to set up a build environment on Ubuntu but as things stand there's no obvious place to put it. Regards, Geoff.
[DAS] Managed Version property/column for OCC
While writing the User level documentation for Optimistic Concurrency Control I started wondering about our current default which is to NOT manage the designated version column. That is, we assume that it is the client's responsibility to modify this column whenever they modify any other column in the associated row. We also provide another option in which the DAS is responsible for bumping the value of the designated column whenever any other column is modified in the associated row. It seems to me that this will be the typical case and should also be the default to save the developer from specifying another piece of config. If there are no strong feelings otherwise then I will open a JIRA for this. Thanks. -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-833) ComponentType sidefiles do not work for Pojo Implementation
ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=all ] Venkatakrishnan updated TUSCANY-833: Component/s: Java SCA POJO Container Affects Version/s: Java-M2 Priority: Critical (was: Major) ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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: [DAS] Managed Version property/column for OCC
This is fine with me. Most of the time users will probably want to have the DAS do the work rather than manually updating the version column or having a database trigger do it. Brent On 10/12/06, Kevin Williams [EMAIL PROTECTED] wrote: While writing the User level documentation for Optimistic Concurrency Control I started wondering about our current default which is to NOT manage the designated version column. That is, we assume that it is the client's responsibility to modify this column whenever they modify any other column in the associated row. We also provide another option in which the DAS is responsible for bumping the value of the designated column whenever any other column is modified in the associated row. It seems to me that this will be the typical case and should also be the default to save the developer from specifying another piece of config. If there are no strong feelings otherwise then I will open a JIRA for this. Thanks. -- Kevin - 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: [VOTE] Release parent pom and buildtools (take 2)
+1 Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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]
[jira] Assigned: (TUSCANY-820) Configuration info for Command Parameters should include an index
[ http://issues.apache.org/jira/browse/TUSCANY-820?page=all ]
Brent Daniel reassigned TUSCANY-820:
Assignee: Brent Daniel
Configuration info for Command Parameters should include an index
---
Key: TUSCANY-820
URL: http://issues.apache.org/jira/browse/TUSCANY-820
Project: Tuscany
Issue Type: Improvement
Components: Java DAS RDB
Affects Versions: Java-Mx
Reporter: Kevin Williams
Assigned To: Brent Daniel
Fix For: Java-Mx
The configuration for command parameters should include an index. As an
example, the current SP example with an OUT parameter has the following
associated config file:
Config
xsi:noNamespaceSchemaLocation=http:///org.apache.tuscany.das.rdb/config.xsd;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
Command name=getNamedCustomers SQL={call GETNAMEDCUSTOMERS(?,?)}
kind=procedure
Parameter direction=IN columnType=commonj.sdo.String/
Parameter direction=OUT columnType=commonj.sdo.IntObject/
/Command
/Config
In keeping with our philosophy that only config that needs to vary from the
defaults should be provided, the first parameter should not need to be
defined since it is of the default IN type. However, removing the first
parameter definition results in the following error.
java.lang.RuntimeException: SQL Exception: Parameter 1 cannot be registered
as an OUT parameter because it is an IN parameter.
at
org.apache.tuscany.das.rdb.impl.SPCommandImpl.executeQuery(SPCommandImpl.java:73)
at
org.apache.tuscany.das.rdb.test.StoredProcs.testGetNamedCustomers(StoredProcs.java:116)
I assume this error is caused by the runtime inferring index positionally
from the config input and the first parameter is necessary as a place holder
in order for the OUT parameter to properly have an index of 2.
--
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: Stabilizing M2 for release
Generally favorable. Essentially +1 if it were a vote. I have one concern is on the sca deliverables. We need to drive to a conclusion soon to figure out the exact artifacts a user will download and what each will contain. Not directly, related to the branching, but you did touched on it. Jeremy Boynes wrote: We have had quite a few suggestions over the last couple of days for new functionality for the trunk some of which would result in changes to the APIs. We have also had the completion of one of the major pieces of code (async over axis webservices) that was still outstanding although there are still concerns over the amount of test coverage it has. We also have RC distros of both SDO and DAS available. I am concerned that there is enough pent-up energy in the project that we may soon see more changes that will destabilize what we have right now. In light of that, I would like to suggest that we create a branch where we can finish stabilizing M2 so that we can open the trunk for new development without concern that it will disrupt a release. This matches what has already been done for SDO. The alternative is to initiate a code-freeze until the M2 release is tagged saying that all new work should be done in people's sandboxes. This code-freeze is likely to be in place for a while as we also need to wait for Axis2 1.1 to be released. I believe that would be less acceptable and so unless there is an objection I plan to go down the branch path. Just for the record (and people reading this later), the purpose of this branch is to stabilize a milestone. The intention is not to establish a branch for the purpose of ongoing maintenance and once the release is tagged work on the branch will end. It can always be reopened later if someone wants to restart work on it but that is not the intention at this time. The SDO code already has a branch in place and we have basically stable versions of the build support artifacts. In light of that, rather than copy the entire source tree I'm going to create branches for each of the source distributions that we intend to produce as follows: tags/java/pom/parent/1-incubator tags/java/buildtools/1.0-incubator-M2 tags/java/spec/sca-api/1.0-incubator-r0.95-M2 branches/sdo-java-M2 (already there) branches/das-java-M2 branches/sca-java-M2 I moved the tags to a java subdirectory as I think over the course of time we will be tagging quite a few things and if we put them all in one directory it is going to get confusing. The pom/parent and buildtools tags will correspond to the current version in the trunk. These are pre-reqs for all the other projects and as such I would like to finalize their release early. I'm going to re-initiate the vote from last week based on the new tags. Once the parent POM is tagged, SDO and DAS can be updated to use it and eliminate all SNAPSHOT dependencies. If they are ready to go, we can initiate a vote on them either together or separately (my inclination is separately as different people may review them). SCA is a little more complex as we have outstanding issues related to the distribution layout, what's in each distro (code, samples, doco etc.) and so forth. As such I do not intend to just copy the entire SCA tree but instead to build it up as these issues get resolved. This will allow us to move things like the samples around in the trunk without needing to duplicate work that in the branch (so we only do it once). Once a module is copied to the branch, the version in the trunk will be bumped to 1.0-incubator-SNAPSHOT (removing the M2 designation). This will ensure that there are no conflicts in between things built from the branch and things built from the trunk (as artifacts from both will be placed in your local repo). The first modules copied to the branch will be those needed to support the standalone and webapp runtimes. This will include the kernel, commands, runtime modules and the webapp plugin. The second wave of modules copied would be those for extensions that we decide are /IN/ the release. The only reason these are separate from the first ones is that we have not defined yet how they will finally be packaged (just that they will be in a binary form). The ones I believe that are currently in this category are: * binding.axis2 * binding.rmi * idl.wsdl * databinding.sdo * databinding.axiom I am not sure on whether javascript, jsonrpc, ruby or spring fall in this category or the next - opinions? A third set of modules will be distributed in source form only. This includes groovy, castor, jaxb, xmlbeans and celtix. Finally, we need to decide how we will distribute supplemental artifacts such as javadoc, end-user doc and samples. Once we know that, they can be added to the branch in the appropriate places. Thanks for reading this far. -- Jeremy - To unsubscribe, e-mail: [EMAIL
[jira] Assigned: (TUSCANY-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=all ] Jim Marino reassigned TUSCANY-833: -- Assignee: Jim Marino ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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: Stabilizing M2 for release
+1 I'll wait for 2 JIRAS to get in and I'll work with a commiter to get DAS branch created. - Luciano Resende On 10/12/06, Rick [EMAIL PROTECTED] wrote: Generally favorable. Essentially +1 if it were a vote. I have one concern is on the sca deliverables. We need to drive to a conclusion soon to figure out the exact artifacts a user will download and what each will contain. Not directly, related to the branching, but you did touched on it. Jeremy Boynes wrote: We have had quite a few suggestions over the last couple of days for new functionality for the trunk some of which would result in changes to the APIs. We have also had the completion of one of the major pieces of code (async over axis webservices) that was still outstanding although there are still concerns over the amount of test coverage it has. We also have RC distros of both SDO and DAS available. I am concerned that there is enough pent-up energy in the project that we may soon see more changes that will destabilize what we have right now. In light of that, I would like to suggest that we create a branch where we can finish stabilizing M2 so that we can open the trunk for new development without concern that it will disrupt a release. This matches what has already been done for SDO. The alternative is to initiate a code-freeze until the M2 release is tagged saying that all new work should be done in people's sandboxes. This code-freeze is likely to be in place for a while as we also need to wait for Axis2 1.1 to be released. I believe that would be less acceptable and so unless there is an objection I plan to go down the branch path. Just for the record (and people reading this later), the purpose of this branch is to stabilize a milestone. The intention is not to establish a branch for the purpose of ongoing maintenance and once the release is tagged work on the branch will end. It can always be reopened later if someone wants to restart work on it but that is not the intention at this time. The SDO code already has a branch in place and we have basically stable versions of the build support artifacts. In light of that, rather than copy the entire source tree I'm going to create branches for each of the source distributions that we intend to produce as follows: tags/java/pom/parent/1-incubator tags/java/buildtools/1.0-incubator-M2 tags/java/spec/sca-api/1.0-incubator-r0.95-M2 branches/sdo-java-M2 (already there) branches/das-java-M2 branches/sca-java-M2 I moved the tags to a java subdirectory as I think over the course of time we will be tagging quite a few things and if we put them all in one directory it is going to get confusing. The pom/parent and buildtools tags will correspond to the current version in the trunk. These are pre-reqs for all the other projects and as such I would like to finalize their release early. I'm going to re-initiate the vote from last week based on the new tags. Once the parent POM is tagged, SDO and DAS can be updated to use it and eliminate all SNAPSHOT dependencies. If they are ready to go, we can initiate a vote on them either together or separately (my inclination is separately as different people may review them). SCA is a little more complex as we have outstanding issues related to the distribution layout, what's in each distro (code, samples, doco etc.) and so forth. As such I do not intend to just copy the entire SCA tree but instead to build it up as these issues get resolved. This will allow us to move things like the samples around in the trunk without needing to duplicate work that in the branch (so we only do it once). Once a module is copied to the branch, the version in the trunk will be bumped to 1.0-incubator-SNAPSHOT (removing the M2 designation). This will ensure that there are no conflicts in between things built from the branch and things built from the trunk (as artifacts from both will be placed in your local repo). The first modules copied to the branch will be those needed to support the standalone and webapp runtimes. This will include the kernel, commands, runtime modules and the webapp plugin. The second wave of modules copied would be those for extensions that we decide are /IN/ the release. The only reason these are separate from the first ones is that we have not defined yet how they will finally be packaged (just that they will be in a binary form). The ones I believe that are currently in this category are: * binding.axis2 * binding.rmi * idl.wsdl * databinding.sdo * databinding.axiom I am not sure on whether javascript, jsonrpc, ruby or spring fall in this category or the next - opinions? A third set of modules will be distributed in source form only. This includes groovy, castor, jaxb, xmlbeans and celtix. Finally, we need to decide how we will distribute supplemental artifacts such as javadoc, end-user doc and samples. Once we know that, they can be added to the branch in the
[jira] Commented: (TUSCANY-832) Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree
[ http://issues.apache.org/jira/browse/TUSCANY-832?page=comments#action_12441824 ] Yang ZHONG commented on TUSCANY-832: Might seem like a usage error: URI can't be computed without person contained within a Resource. Do you want to try to contain person inside a Resource which can have any URI you want to see in the XML output/serialization? Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree Key: TUSCANY-832 URL: http://issues.apache.org/jira/browse/TUSCANY-832 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Attachments: anyURI.xsd, AnyURITest.java The XSD anyURI type is mapped to SDO URI type with sdo:propertyType annotation. When I used the SDO URI type property to reference a DataObject in a different tree and tried to serialize it, I would get the exception below. Exception in thread main org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.endSave(XMLSaveImpl.java:284) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:247) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:988) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(XMLDocumentImpl.java:183) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:107) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:102) at AnyURITest.testAnySimpleType(AnyURITest.java:45) at AnyURITest.main(AnyURITest.java:29) Caused by: org.eclipse.emf.ecore.xmi.DanglingHREFException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.handleDanglingHREF(XMLHelperImpl.java:680) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:711) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReference(XMLSaveImpl.java:1874) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReferenceSingle(XMLSaveImpl.java:1917) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1420) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2458) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1032) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:918) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementFeatureMap(XMLSaveImpl.java:2208) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1351) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:624) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:549) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) ... 7 more -- 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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441825 ] Jim Marino commented on TUSCANY-833: Proliferating an encapsulation approach to extensions is the wrong way to fix this as it will just add to the problems. Moreover, it will not solve the issue for Java Pojos. Either we should treat this as a blocker for M2 and fix it or release note that it does not work. I outlined in an email to the list yesterday how to fix this. For the specific script issues, a better workaround involves moving lifecycle scope to the base component type (which would involve moving it from PojoComponentType) as I also outlined. There are, however, other issues which still need to be addressed regarding script extensions as I mentioned in the same mail, which I'm happy to help with. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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-832) Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree
[ http://issues.apache.org/jira/browse/TUSCANY-832?page=comments#action_12441841 ] Fuhwei Lwo commented on TUSCANY-832: EMF can handle the cross document link but not SDO. I have opened a new JIRA against the future SDO spec 3.0. For Tuscany SDO implementation, I think we need some SPIs to support this feature. Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree Key: TUSCANY-832 URL: http://issues.apache.org/jira/browse/TUSCANY-832 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Attachments: anyURI.xsd, AnyURITest.java The XSD anyURI type is mapped to SDO URI type with sdo:propertyType annotation. When I used the SDO URI type property to reference a DataObject in a different tree and tried to serialize it, I would get the exception below. Exception in thread main org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.endSave(XMLSaveImpl.java:284) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:247) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:988) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(XMLDocumentImpl.java:183) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:107) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:102) at AnyURITest.testAnySimpleType(AnyURITest.java:45) at AnyURITest.main(AnyURITest.java:29) Caused by: org.eclipse.emf.ecore.xmi.DanglingHREFException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.handleDanglingHREF(XMLHelperImpl.java:680) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:711) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReference(XMLSaveImpl.java:1874) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReferenceSingle(XMLSaveImpl.java:1917) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1420) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2458) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1032) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:918) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementFeatureMap(XMLSaveImpl.java:2208) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1351) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:624) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:549) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) ... 7 more -- 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] Resolved: (TUSCANY-828) Update companyweb.war location in sample distribution
[ http://issues.apache.org/jira/browse/TUSCANY-828?page=all ] Brent Daniel resolved TUSCANY-828. -- Resolution: Fixed Update companyweb.war location in sample distribution - Key: TUSCANY-828 URL: http://issues.apache.org/jira/browse/TUSCANY-828 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 Attachments: tuscany828.lresende.20061011.txt Move CompanyWeb.war to root directory of the distribution as per comments from M2 RC2 http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00270.html -- 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]
Error running sample in Java SDO M2 RC3
I'm getting a NullPointerException from the UsingXPath sample in SDO M2 RC3. Here's the output from the sample with some debug code that I added to print the exception and stack trace: *** SDO Sample UsingXPath *** Demonstrats accessing a created DataObject's properties using xPath. *** DataObject created Accessing individual item from list using xpath expressionitems/item[1] DataObject toString : [EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: item) (instanceClassName: null) (abstract: false, interface: false)) Item name:Lawnmower Part num: 872-AA Accessing individual item from list using xpath expressionitems/item[productName=Baby Monitor] Sorry there was an error executing expression items/item[productName=Baby Monitor] java.lang.NullPointerException at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2054) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2161) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1940) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1860) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:744) at org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216) at org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326) at org.apache.tuscany.samples.sdo.specCodeSnippets.UsingXPath.accessDataObjectUsingXPath(UsingXPath.java:94) at org.apache.tuscany.samples.sdo.specCodeSnippets.UsingXPath.main(UsingXPath.java:140) at org.apache.tuscany.samples.sdo.ExecuteSamples.main(ExecuteSamples.java:123) GoodBye Simon kelvin goodson wrote: I have put a new release candidate for SDO Java up at http://people.apache.org/~kelvingoodson/sdo_java/RC3/ This tries to take into account the comments that the sample distribution does not need to be stand alone, and that javadoc should be shipped with the binary and sample distributions. I have been fighting with the maven build environment to produce a good set of javadoc as part of the build, from a user's perspective, but that's not at all easy given the structure of our projects and the nature of the maven javadoc plugin, so currently the binary distribution carries javadoc for the sdo api and all of the tuscany implementation. The README file draws the attention of an SDO user to relevant classes in the tuscany implementation javadoc. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release parent pom and buildtools (take 2)
+1 I have tested this with the still under development DAS M2 RC3, and seems to be working fine... - Luciano On 10/12/06, cr22rc [EMAIL PROTECTED] wrote: +1 Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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]
[jira] Resolved: (TUSCANY-827) Update companyweb readme.htm
[ http://issues.apache.org/jira/browse/TUSCANY-827?page=all ] Luciano Resende resolved TUSCANY-827. - Resolution: Fixed Thanks for applying the patch. Update companyweb readme.htm Key: TUSCANY-827 URL: http://issues.apache.org/jira/browse/TUSCANY-827 Project: Tuscany Issue Type: Improvement Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Attachments: tuscany827.lresende.20061011.txt, tuscany827.lresende.20061011.zip Need to update the readme.htm based on the feedback from DAS M2 RC2 http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00268.html -- 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: [VOTE] Release parent pom and buildtools (take 2)
+1 from me as well Luciano Resende wrote: +1 I have tested this with the still under development DAS M2 RC3, and seems to be working fine... - Luciano On 10/12/06, cr22rc [EMAIL PROTECTED] wrote: +1 Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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: Weak wiki-fu
Thanks! This will be helpful. kelvin goodson wrote: Here's what seems to be everything you could ever want to know about linking on the moinmoin wiki implementation. http://moinmoin.wikiwikiweb.de/HelpOnLinking?highlight=%28%5EHelp.%2A%29 Cheers, Kelvin. On 11/10/06, Kevin Williams [EMAIL PROTECTED] wrote: I am having some trouble setting up links between pages in our wiki. When linking to child pages I have followed examples I have seen on our wiki and do something like this: * [wiki:/Convention_over_configuration Convention over configuration] So, the syntax is : [wiki:/some_child_page child page alias]. This works great when I want to link to a child page. But, I often want to link to a page somewhere else in the hierarchy and I was hoping I could refer to a peer page like this: * [wiki:../some_peer_page peer page alias] But, this does not work. The only way I have found to link to a non-child page is to use the full URL like this: * [ http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/Improved_logging Logging] This works but makes the link appear to be to an external page rather than a page within our own wiki. I think I must be missing something due to my weak wiki-fu. Any help would be appreciated. -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441857 ] Jeremy Boynes commented on TUSCANY-833: --- Jim's proposal to the mailing list sounds like a better long-term solution but I am concerned that doing it this close to the release of M2 will be destabilizing. Propogating the approach used by the script containers does not provide the full function that we need from sidefiles - for example, it does not support scope and lifecycle method configuration that is available via annotation. I think we should tackle this problem as follows: 1. Create the branch using the code as it is today and document that sidefiles are not supported for Java components. This is the status quo. 2. Fix this in head the right way (whatever that is), assess the impact of that patch and consider applying it to the M2 branch before release. 3. Create a patch for the M2 branch that provides sidefile support with minimal destablization (however that can be done). The patches from 2 and 3 provide concrete implementations that we can evaluate for incorporation into M2, balancing the benefit of fixing the bug vs. the potential destabilization. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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] Closed: (TUSCANY-805) Document how to run standalone sca applications
[ http://issues.apache.org/jira/browse/TUSCANY-805?page=all ] Luciano Resende closed TUSCANY-805. --- Resolution: Duplicate Duplicate of : TUSCANY-780 Document how to run standalone sca applications --- Key: TUSCANY-805 URL: http://issues.apache.org/jira/browse/TUSCANY-805 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 I was playing with SCA and could not find any documentation on how to use the standalone distribution to run standalone applications that use SCA. This JIRA is to produce some documentation and post on the website. -- 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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441862 ] Jim Marino commented on TUSCANY-833: Looking into this more, my preference would be not to fix this or do a hack for M2 since for POJOs, component type side files aren't really useful do to some spec issues. Even if we were to fix the problems outlined, the only things that can be specified in a side file are services, references and proprties. The spec has not yet defined how to represent specific Java concepts such as init/destroy and implementation scopes in the component type schema. This renders side files not very useful. The only type of POJO implementation that could be specified with a side file is statelesss with no intitialization or destruction callbacks. In addition, we already support the algorithm for determining services, references and properties on an unannotated POJO, relegating the need to actuallly have to specify a side file to mostly corner cases involving legacy code. Given the need to stabilize a brach, I think we should release note that we do not support component type side files for POJOs with M2. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441870 ] Jim Marino commented on TUSCANY-833: Responding to Jeremy specifically, I would prefer to do the right way after M2 given side files for POJOs don't really do very much. As for copying the component type in the Java implementation loader, I really don't want to do this since IMO introducing workarounds should only be done in extreme circumstances. For extension types, they definitely shouldn't do this. So, my preference would be option 4: release note it. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- 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: M2 Release Items - Status Updates
Latest status on DAS M2 Tasks can be found here : http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2TasksDAS - Luciano On 10/10/06, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Venkata, I have updated the DAS portion : http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2TasksDAS - Luciano On 10/10/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hello Everybody, If you had taken a look at the IRC log that Raymond posted ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09360.html ), it would be evident that all of us agreed out there to get to some common understanding on what the Release Items for M2 are and where we stand with each. This is all the more necessary to re-align ourselves a bit to places where help is required to make M2 happen. Hence I humbly request each of your co-operation in this regard. There has been a M2 status update page on the wiki that has now been revamped a bit. There are now three pages for SCA, SDO and DAS respectively. While I have had some info to populate the SCA page, I have left the other two - SDO and DAS with a skeleton. I request Kelvin and Luciano to look up the SCA for this and see if you'd want to follow something similar for SDO and DAS resp. If you do, then just go ahead from the skeletons I have created. Please, each of you visit the wiki and do the following: - - If the work item you are working on is listed there, then see if you have been put as the owner, if not put that down first. Then update the status information related to your work item. - If the work item you are working is NOT listed there (forgive me for that first), then please add following the template that has been applied to the others and update the relevant info. Lets have this wiki page brought to date by end of wednesday, so that we all get a clear picture of how we are progressing with the release. 'If need be' we can set up a IRC chat on Thursday to quickly run thro the release items and plan on the road ahead. Ok, here are the pages for SCA, SDO and DAS resp. Java SCA - http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2TasksSCA Java SDO - http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2TasksSDO Java DAS - http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2TasksDAS Thanks - Venkat
[jira] Created: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Priority: Minor Fix For: Java-M2 DAS RDB pom has no version information for junit dependency. -- 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] Assigned: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
[ http://issues.apache.org/jira/browse/TUSCANY-834?page=all ] Luciano Resende reassigned TUSCANY-834: --- Assignee: Luciano Resende Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 DAS RDB pom has no version information for junit dependency. -- 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]
NOTICE text in sdo-api module
The NOTICE text refers to the EPL and CPL but I didn't think there was any reference to anything under those licenses in that module (as opposed to the implementation). If this is right we should remove that as being confusing; if not, then we should also include the EPL and CPL text in the LICENSE file. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NOTICE text in sdo-api module
Another thought, for SCA we are using a common NOTICE file across most modules with variable substitution to insert the name of the module etc. This is because of the number of modules we have :-) That might be useful here as well. -- Jeremy On Oct 12, 2006, at 2:12 PM, Jeremy Boynes wrote: The NOTICE text refers to the EPL and CPL but I didn't think there was any reference to anything under those licenses in that module (as opposed to the implementation). If this is right we should remove that as being confusing; if not, then we should also include the EPL and CPL text in the LICENSE file. -- 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]
[jira] Created: (TUSCANY-835) Version column should default to managed = true
Version column should default to managed = true --- Key: TUSCANY-835 URL: http://issues.apache.org/jira/browse/TUSCANY-835 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx This is fine with me. Most of the time users will probably want to have the DAS do the work rather than manually updating the version column or having a database trigger do it. Brent On 10/12/06, Kevin Williams [EMAIL PROTECTED] wrote: While writing the User level documentation for Optimistic Concurrency Control I started wondering about our current default which is to NOT manage the designated version column. That is, we assume that it is the client's responsibility to modify this column whenever they modify any other column in the associated row. We also provide another option in which the DAS is responsible for bumping the value of the designated column whenever any other column is modified in the associated row. It seems to me that this will be the typical case and should also be the default to save the developer from specifying another piece of config. -- 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-834) Missing version information for junit plugin in das pom.xml
[ http://issues.apache.org/jira/browse/TUSCANY-834?page=all ] Luciano Resende updated TUSCANY-834: Attachment: tuscany834.lresende.20061012.txt Patch adding the junit version reference to java/das/rdb/pom.xml Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 Attachments: tuscany834.lresende.20061012.txt DAS RDB pom has no version information for junit dependency. -- 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] Resolved: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
[ http://issues.apache.org/jira/browse/TUSCANY-834?page=all ] Brent Daniel resolved TUSCANY-834. -- Resolution: Fixed Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 Attachments: tuscany834.lresende.20061012.txt DAS RDB pom has no version information for junit dependency. -- 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]
DAS User Guide was Fwd: Introduction - Willian Yabusame Maja
Hi William Another task that came to mind, and your help would be appreciated, is if you could take a look at our initial User Guide documentation and provide some feedback on how usefull that is, and what you might want to see there as a new DAS user. You can find our users guide at : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_Java_User_Guide - Luciano -- Forwarded message -- From: Luciano Resende [EMAIL PROTECTED] Date: Oct 5, 2006 9:10 AM Subject: Re: Introduction - Willian Yabusame Maja To: tuscany-dev@ws.apache.org Hey William, first I want to wellcome you to the Tuscany Project You could start by getting your DEV environment setup and getting familiar with the code, and you can find some information on the following links: http://incubator.apache.org/tuscany/java-projects.html http://incubator.apache.org/tuscany/java_das_overview.html As for help, I think you might be able to help me finishing a DAS sample app that uses Ajax to perform SQL queries into a derby database using DAS. And we could document this in a how to build a hello world DAS app paper : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp If you are OK with this, I'll try to get the unfinished sample into the trunk so you can help... I'm also available at IRC if you have questions... - Luciano On 10/4/06, haleh mahbod [EMAIL PROTECTED] wrote: Welcome to the project Willian. On 10/4/06, Willian Yabusame Maja [EMAIL PROTECTED] wrote: Hi, Tuscany Community! I'm from Brazil, and i'm studing Computer Science in UFMT (University of Mato Grosso). Luciano Resende told me about this project, and he wanted help to develop it. I think I can help... at least I hope : ), because It's my first time in a big project. I'm intersted in developing DAS/SDO and Luciano will give me some tasks until I get used with Tuscany project. Thanks, Willian Yabusame Maja
Re: Java SDO M2 relesae candidate 3 available
This is getting very close now. Good work! I have a few minor comments, mostly typos in the samples documentation. in sample/README.txt change already build to already built in sample/src/main/java/org/apache/tuscany/samples/sdo/overview.html change Samples Programs to Sample Programs remove misplaced line breaks on penultimate lines of Overview and Experimentation sections third category in Overview paragraph does not match the categories in the table that precedes this text when this file is displayed within sample/site/apidocs/index.html (it's actually a subset of the first category in the table). An easy fix is to change and the third category were to or were in the Getting Ready ... section, first line, change depend of to depend on in the Getting Ready ... section, second last paragraph, first line, change insrtuctions to instructions download link for the SDO 2.01 specs currently points to the IBM web site and should be changed to point to the osoa.org site in sample/site/apidocs/org/apache/tuscany/samples/sdo/package.html fix dangling reference at the end of this file in sample/site/apidocs/org/apache/tuscany/samples/sdo/otherSources/package.html in first sentence, change specification to SDO Specification (to avoid forward reference when this text is displayed in the package overview table in sample/site/apidocs/index.html) change usefull scnearios to useful scenarios download link for the SDO 2.01 specs currently points to the IBM web site and should be changed to point to the osoa.org site in sample/site/apidocs/org/apache/tuscany/samples/sdo/specCodeSnippets/package.html change snipets to snippets (twice) change flexability to flexibility change desireable to desirable change extend or improve to to extend or improve download link for the SDO 2.01 specs currently points to the IBM web site and should be changed to point to the osoa.org site in sample/site/apidocs/org/apache/tuscany/samples/sdo/specExampleSection/package.html change specification, exceptions to specification; exceptions download link for the SDO 2.01 specs currently points to the IBM web site and should be changed to point to the osoa.org site in output from ExecuteSamples, CreatePurchaseOrder, and ReadPurchaseOrder: change Fuhwei Lo to Fuhwei Lwo in SDO binary distribution there is duplication of content between RELEASE_NOTES.txt and CHANGES.txt Thanks. Simon kelvin goodson wrote: I have put a new release candidate for SDO Java up at http://people.apache.org/~kelvingoodson/sdo_java/RC3/ This tries to take into account the comments that the sample distribution does not need to be stand alone, and that javadoc should be shipped with the binary and sample distributions. I have been fighting with the maven build environment to produce a good set of javadoc as part of the build, from a user's perspective, but that's not at all easy given the structure of our projects and the nature of the maven javadoc plugin, so currently the binary distribution carries javadoc for the sdo api and all of the tuscany implementation. The README file draws the attention of an SDO user to relevant classes in the tuscany implementation javadoc. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release parent pom and buildtools (take 2)
+1 (non-binding) Simon Jeremy Boynes wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- 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: [jira] Updated: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
You normally don't need or want to do this - the information is inherited from the parent (das) pom.xml's dependencyManagement section which enables it to be specified in one place and shared between all modules. -- Jeremy On Oct 12, 2006, at 2:32 PM, Luciano Resende (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-834?page=all ] Luciano Resende updated TUSCANY-834: Attachment: tuscany834.lresende.20061012.txt Patch adding the junit version reference to java/das/rdb/pom.xml Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 Attachments: tuscany834.lresende.20061012.txt DAS RDB pom has no version information for junit dependency. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
The problem here was that if I generate the source distribution by doing a export of das/rdb and then update the pom to point to parent pom, these default values won't be there and compilation will fail. I think what you said is true if I export the whole das subtree as part of the source distribution, then default values will be available. - Luciano On 10/12/06, Jeremy Boynes [EMAIL PROTECTED] wrote: You normally don't need or want to do this - the information is inherited from the parent (das) pom.xml's dependencyManagement section which enables it to be specified in one place and shared between all modules. -- Jeremy On Oct 12, 2006, at 2:32 PM, Luciano Resende (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-834?page=all ] Luciano Resende updated TUSCANY-834: Attachment: tuscany834.lresende.20061012.txt Patch adding the junit version reference to java/das/rdb/pom.xml Missing version information for junit plugin in das pom.xml --- Key: TUSCANY-834 URL: http://issues.apache.org/jira/browse/TUSCANY-834 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Minor Fix For: Java-M2 Attachments: tuscany834.lresende.20061012.txt DAS RDB pom has no version information for junit dependency. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comment on SDO overview from Tuscany site
No comment in the past 10 days; can I assume the update looks fine and I can sumbit a patch please? The timing seems nice since we're releasing M2. -- Yang ZHONG
Re: [jira] Updated: (TUSCANY-834) Missing version information for junit plugin in das pom.xml
It's important that all dependencies from the source distribution are to released artifacts. This does not apply just to the junit version but to the pom as a whole. If you can't rely on the parent pom being there (which is the implication of you saying that the version won't be there) then you can't rely on the das parent pom being there either and you would need to remove the parent dependency all together; otherwise you are relying on the parent and in which case you might as well avoid the duplication of the junit version info. -- Jeremy On Oct 12, 2006, at 4:37 PM, Luciano Resende wrote: The problem here was that if I generate the source distribution by doing a export of das/rdb and then update the pom to point to parent pom, these default values won't be there and compilation will fail. I think what you said is true if I export the whole das subtree as part of the source distribution, then default values will be available. - Luciano On 10/12/06, Jeremy Boynes [EMAIL PROTECTED] wrote: You normally don't need or want to do this - the information is inherited from the parent (das) pom.xml's dependencyManagement section which enables it to be specified in one place and shared between all modules. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java: Getting Involved -- Tests/Samples
Kelvin - Thanks for setting up a JIRA (I am far from an open source expert, so feel free to provide explanations). I will work with members of our Infrastructure team to provide a couple of sample tests for Tuscany to assess. This might take us a couple of days as we will need to separate tests that exercise the SDO API from tests the exercise Rogue Wave (RW) implementation specific classes. In addition to the actual tests, I think it would be wise if we make sure we are on common ground relative to the test framework -- for both Java and C++. I am not certain how we would best go about doing this, but a couple of items would include: *ensuring we are using the same tools. (we use JUnit and CxxTest) *what if any architectural documents for Java and C++ test suites exist --- if this is none - we might want to work togeher to build out the documents *can we work together to create test suite design? tom On 10/12/06, kelvin goodson [EMAIL PROTECTED] wrote: Tom, Welcome to Tuscany! that's great! Thanks for offering to get involved. How should we proceed? I'd be most happy to assist you to integrate what you have to offer. We currently have a small collection of tests using the junit framework (see https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/ ) but there's significant scope for enhancement. BTW I'm going to make my response Java centric as Andrew has offered to help look at the C++ side of things. How about this for a proposal for how to proceed? I have opened a JIRA (this is our issue or bug tracking system if you are not familiar with these things --- please tell me if you are already an expert). The JIRA can be seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you can upload attachments to the JIRA, so we could perhaps use that to first attach a typical RogueWave test or two. I guess it's likely that there will be some modifications that need to be made with regards to setting up the test within our environment, but that way we could play and discuss how we might proceed with more tests. How does that sound? Best Regards, Kelvin. On 11/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Tom, Coming from the C++ side of Tuscany, I know we'd certainly be interested in those C++ SDO tests - please get involved! Cheers Andrew On 10/11/06, T Gould [EMAIL PROTECTED] wrote: Kelvin - We at Rogue Wave have been developing an SDO product, HydraSDO, and have a seires of tests that might be easiliy modified so as to exercise your Java SDO product. We would be very interested in providing our tests as well as helping create a test environment (unless this has already been done) to futher test the SDO product. Additionally, we also have C++ tests. tom gould --- As the Java M2 release is imminent it occured to me that it would be really useful if there are users out there who are putting our code through its paces that you may be developing samples/tests which could usefully be contributed back to the Tuscany project and make it more robust. If you are in such a position it would be really great to hear from you. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-832) Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree
[ http://issues.apache.org/jira/browse/TUSCANY-832?page=comments#action_12441884 ] Yang ZHONG commented on TUSCANY-832: Not sure how EMF gets a URI without Resource. Are you proposing SDO SPI something like SDOUtil.setURI(DataObject person,String URI)? Needs to support serialization and deserialization of SDO URI type property that references a DataObject in a different tree Key: TUSCANY-832 URL: http://issues.apache.org/jira/browse/TUSCANY-832 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Attachments: anyURI.xsd, AnyURITest.java The XSD anyURI type is mapped to SDO URI type with sdo:propertyType annotation. When I used the SDO URI type property to reference a DataObject in a different tree and tried to serialize it, I would get the exception below. Exception in thread main org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.endSave(XMLSaveImpl.java:284) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:247) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:988) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(XMLDocumentImpl.java:183) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:107) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java:102) at AnyURITest.testAnySimpleType(AnyURITest.java:45) at AnyURITest.main(AnyURITest.java:29) Caused by: org.eclipse.emf.ecore.xmi.DanglingHREFException: The object '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: Person) (instanceClassName: null) (abstract: false, interface: false))' is not contained in a resource. at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.handleDanglingHREF(XMLHelperImpl.java:680) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:711) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReference(XMLSaveImpl.java:1874) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementReferenceSingle(XMLSaveImpl.java:1917) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1420) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2458) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1032) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:918) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementFeatureMap(XMLSaveImpl.java:2208) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1351) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:624) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:549) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) ... 7 more -- 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-836) doubleValue() may be inaccurate for Long
doubleValue() may be inaccurate for Long
Key: TUSCANY-836
URL: http://issues.apache.org/jira/browse/TUSCANY-836
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-Mx
Environment: Sun JRE 1.5.0_07-b03
Reporter: Yang ZHONG
assertSame(DataObjectUtil.getBigDecimal(new
Long(Long.MAX_VALUE)).longValue(), Long.MAX_VALUE);
complains
junit.framework.AssertionFailedError: expected same:-9223372036854775808
was not:9223372036854775807
Potential fix:
if (value instanceof Long)
{
return new BigDecimal(((Long)value).longValue());
}
before
if (value instanceof Number)
{
return new BigDecimal(((Number)value).doubleValue());
}
Thanks to Marcelo Palladino.
--
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-836) doubleValue() may be inaccurate for Long
[ http://issues.apache.org/jira/browse/TUSCANY-836?page=all ]
Yang ZHONG updated TUSCANY-836:
---
Attachment: Long2BigDecimalTestCase.java
Could someone commit the new Test Case or its variation please?
doubleValue() may be inaccurate for Long
Key: TUSCANY-836
URL: http://issues.apache.org/jira/browse/TUSCANY-836
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-Mx
Environment: Sun JRE 1.5.0_07-b03
Reporter: Yang ZHONG
Attachments: Long2BigDecimalTestCase.java
assertSame(DataObjectUtil.getBigDecimal(new
Long(Long.MAX_VALUE)).longValue(), Long.MAX_VALUE);
complains
junit.framework.AssertionFailedError: expected
same:-9223372036854775808 was not:9223372036854775807
Potential fix:
if (value instanceof Long)
{
return new BigDecimal(((Long)value).longValue());
}
before
if (value instanceof Number)
{
return new BigDecimal(((Number)value).doubleValue());
}
Thanks to Marcelo Palladino.
--
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: [VOTE] Release parent pom and buildtools (take 2)
+1 - Venkat On 10/12/06, Jeremy Boynes [EMAIL PROTECTED] wrote: New version of the build artifacts that other Tuscany modules depend on. For each there are links to the tag (as a separate source distribution is not really applicable) and the artifact. Please vote to approve the release of these so we can use them to build the releases of the other modules: parent-pom [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/1/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/1-incubator/ buildtools [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/1.0-incubator-M2/ [artifacts] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/1.0-incubator-M2/ I ran the RAT tool on the source trees and the results can be found here: http://people.apache.org/~jboynes/rat/tuscany-M2/parent-1.rat http://people.apache.org/~jboynes/rat/tuscany-M2/buildtools-M2.rat -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stabilizing M2 for release
Hi Jeremy, thanks for that explanation... was really useful. I think Javascript and maybe even Ruby should be in. Javascript has been up and working for long now. I found it to be a good demonstration of a container extension and that is how I ended up doing Ruby quickly (by my standards :)). It has... - properties, services and references working - extends to support E4X - has an acceptable test coverage - has a working sample Maybe the doc is something that remains to be done or maybe that is also there and am missing that. Thanks - Venkat On 10/12/06, Luciano Resende [EMAIL PROTECTED] wrote: +1 I'll wait for 2 JIRAS to get in and I'll work with a commiter to get DAS branch created. - Luciano Resende On 10/12/06, Rick [EMAIL PROTECTED] wrote: Generally favorable. Essentially +1 if it were a vote. I have one concern is on the sca deliverables. We need to drive to a conclusion soon to figure out the exact artifacts a user will download and what each will contain. Not directly, related to the branching, but you did touched on it. Jeremy Boynes wrote: We have had quite a few suggestions over the last couple of days for new functionality for the trunk some of which would result in changes to the APIs. We have also had the completion of one of the major pieces of code (async over axis webservices) that was still outstanding although there are still concerns over the amount of test coverage it has. We also have RC distros of both SDO and DAS available. I am concerned that there is enough pent-up energy in the project that we may soon see more changes that will destabilize what we have right now. In light of that, I would like to suggest that we create a branch where we can finish stabilizing M2 so that we can open the trunk for new development without concern that it will disrupt a release. This matches what has already been done for SDO. The alternative is to initiate a code-freeze until the M2 release is tagged saying that all new work should be done in people's sandboxes. This code-freeze is likely to be in place for a while as we also need to wait for Axis2 1.1 to be released. I believe that would be less acceptable and so unless there is an objection I plan to go down the branch path. Just for the record (and people reading this later), the purpose of this branch is to stabilize a milestone. The intention is not to establish a branch for the purpose of ongoing maintenance and once the release is tagged work on the branch will end. It can always be reopened later if someone wants to restart work on it but that is not the intention at this time. The SDO code already has a branch in place and we have basically stable versions of the build support artifacts. In light of that, rather than copy the entire source tree I'm going to create branches for each of the source distributions that we intend to produce as follows: tags/java/pom/parent/1-incubator tags/java/buildtools/1.0-incubator-M2 tags/java/spec/sca-api/1.0-incubator-r0.95-M2 branches/sdo-java-M2 (already there) branches/das-java-M2 branches/sca-java-M2 I moved the tags to a java subdirectory as I think over the course of time we will be tagging quite a few things and if we put them all in one directory it is going to get confusing. The pom/parent and buildtools tags will correspond to the current version in the trunk. These are pre-reqs for all the other projects and as such I would like to finalize their release early. I'm going to re-initiate the vote from last week based on the new tags. Once the parent POM is tagged, SDO and DAS can be updated to use it and eliminate all SNAPSHOT dependencies. If they are ready to go, we can initiate a vote on them either together or separately (my inclination is separately as different people may review them). SCA is a little more complex as we have outstanding issues related to the distribution layout, what's in each distro (code, samples, doco etc.) and so forth. As such I do not intend to just copy the entire SCA tree but instead to build it up as these issues get resolved. This will allow us to move things like the samples around in the trunk without needing to duplicate work that in the branch (so we only do it once). Once a module is copied to the branch, the version in the trunk will be bumped to 1.0-incubator-SNAPSHOT (removing the M2 designation). This will ensure that there are no conflicts in between things built from the branch and things built from the trunk (as artifacts from both will be placed in your local repo). The first modules copied to the branch will be those needed to support the standalone and webapp runtimes. This will include the kernel, commands, runtime modules and the webapp plugin. The second wave of modules copied would be those for extensions that we decide are /IN/ the release. The only reason these are
Old style header still in use?
I had a memory of seeing one of these recently so I grepped for something indicative in SDO and DAS and came up with: $ grep -rli --exclude=*.svn-base licensors sdo das sdo/distribution/src/main/assembly/sdo.xml sdo/impl/src/test/resources/anytype.xsd sdo/impl/src/test/resources/api_test.xsd sdo/impl/src/test/resources/bank.xsd sdo/impl/src/test/resources/datatype.xsd sdo/impl/src/test/resources/foo-ext.xsd sdo/impl/src/test/resources/foo.xsd sdo/impl/src/test/resources/mixed.xsd sdo/impl/src/test/resources/names.xsd sdo/impl/src/test/resources/open.xsd sdo/impl/src/test/resources/sdoannotations.xsd sdo/impl/src/test/resources/sdotypes.xsd sdo/impl/src/test/resources/simple.xsd sdo/impl/src/test/resources/XMLDocumentNoNamespaceSchemaLocation.xsd sdo/impl/src/test/resources/XMLDocumentSchemaLocation.xsd sdo/tools/readme.htm sdo/tools/src/test/resources/enum.xsd sdo/tools/src/test/resources/repeatingChoice.xsd sdo/tools/src/test/resources/sequences.xsd sdo/tools/src/test/resources/simple.xsd das/samples/build.xml das/samples/companyweb/build.xml das/samples/companyweb/src/main/webapp/Company.jsp das/samples/companyweb/src/main/webapp/META-INF/context.xml das/samples/companyweb/src/main/webapp/WEB-INF/web.xml das/samples/testing/tomcat/build.xml das/samples/testing/tomcat/companyweb/src/test/java/org/apache/ tuscany/test/das/DasTestCase.java das/samples/testing/tomcat/context.xsl das/samples/testing/tomcat/readme.htm das/samples/testing/tomcat/server.xsl We need to make sure the headers are up to date per Board policy - can someone please check and fix these. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
