New to Tuscany, would like to contribute small fix to one of the tests
Hi all, I just checked out the java tree and encountered the following problem, which seems fixable with a one line change (details at bottom). Running org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094 sec <<< FAILURE! testMap( org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase) Time elapsed: 0.078 sec <<< ERROR! java.lang.IllegalArgumentException: --02-- at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parseInt (XMLGregorianCalendarImpl.java:2789) at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parse (XMLGregorianCalendarImpl.java:2711) at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl .(XMLGregorianCalendarImpl.java:433) at com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar (DatatypeFactoryImpl.java:230) at org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject( SimpleTypeMapperImpl.java:330) at org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase.testMap (SimpleTypeMapperExtensionTestCase.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess( SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.java:818) So we have two relevant source files: 1) modules\databinding\src\main\java\org\apache\tuscany\sca\databinding\impl\SimpleTypeMapperImpl.java 2) modules\databinding\src\test\java\org\apache\tuscany\sca\databinding\extension\SimpleTypeMapperExtensionTestCase.java Looking at the two relevant source files and the trace I found it was failing when passing in a value of "--02--" to DatatypeFactory.newInstance ().newXMLGregorianCalendar. The gMonth format is in section 3.2.14.2 of the relevant spec: http://www.w3.org/TR/xmlschema-2/#dateTime-order, and says the format should only be --MM. Note that gDay is ---DD (sec. 3.2.13.1). Looking at the TestCase I see on line 52 that the format looks wrong. Changed it from --02-- to --02 and re-tested and got past that error. Since it's a one line fix I didn't attach a patch.
Re: New to Tuscany, would like to contribute small fix to one of the tests
Hi, Bill. Welcome to Tuscany. You hit an interesting known issue related to the format of xsd:gMonth described at http://books.xmlschemata.org/relaxng/ch19-77111.html. The following is quoted from that page: "The value space of xsd:gMonth is the period of one calendar month recurring each calendar year (such as the month of April). Its lexical space should follow the ISO 8601 syntax for such periods (i.e., -- MM) with an optional time zone. Tip There's a typo in the W3C XML Schema Recommendation, in which the format is defined as -- MM -- --. Even though an erratum should be published to bring the W3C XML Schema inline with ISO 8601, most current schema processors expect the (bogus) -- MM -- -- format. In the example, I follow the correct ISO 8601 format." By looking into the latest XSD spec, it now says "--MM". So you're right, the --MM is the correct format. So the bottom line is that if you pass the correct format --MM to some JDKs such as SUN JDK 5.x, the test case wil fail. But the IBM JDK seems to be happy with both format. If I remember correctly, SUN JDK 6.x now expects --MM. Could you tell us which JDK you're using? We could make this paticular test case JDK-version sensitive. Thanks, Raymond - Original Message - From: "Bill Barnhill" <[EMAIL PROTECTED]> To: Sent: Saturday, May 19, 2007 10:24 AM Subject: New to Tuscany, would like to contribute small fix to one of the tests Hi all, I just checked out the java tree and encountered the following problem, which seems fixable with a one line change (details at bottom). Running org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094 sec <<< FAILURE! testMap( org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase) Time elapsed: 0.078 sec <<< ERROR! java.lang.IllegalArgumentException: --02-- at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parseInt (XMLGregorianCalendarImpl.java:2789) at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parse (XMLGregorianCalendarImpl.java:2711) at com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl .(XMLGregorianCalendarImpl.java:433) at com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar (DatatypeFactoryImpl.java:230) at org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject( SimpleTypeMapperImpl.java:330) at org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase.testMap (SimpleTypeMapperExtensionTestCase.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess( SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.java:818) So we have two relevant source files: 1) modules\databinding\src\main\java\org\apache\tuscany\sca\databinding\impl\SimpleTypeMapperImpl.java 2) modules\databinding\src\test\java\org\apache\tuscany\sca\databinding\extension\SimpleTypeMapperExtensionTestCase.java Looking at the two relevant source files and the trace I found it was failing when passing in a value of "--02--" to D
Re: New to Tuscany, would like to contribute small fix to one of the tests
Hi Raymond, Thanks for the welcome. You hit the nail on the head. I had thought I was building with Sun JDK 1.5, turns out I was building with Sun JDK 1.6. I switched to 1.5 and it blew past that problem and another I was having. I did have to make one change to get it to build though, even under 1.5(though old version fo 1.5..1.50_06-b05, :) I need to update). That change was to add the following snippet for the servlet-api 2.5dependency to java\sca\itest\databindings\sdogen\src\main\resources\generate\pom.xml.vm: javax.servlet servlet-api 2.5 test http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html, but the code seems to have changed from that. My goal is to have an SCA runtime within equinox, able to access SCA components (some remote web services, some local components) that are each packaged in individual bundles. Thanks, Bill On 5/19/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Bill. Welcome to Tuscany. You hit an interesting known issue related to the format of xsd:gMonth described at http://books.xmlschemata.org/relaxng/ch19-77111.html. The following is quoted from that page: "The value space of xsd:gMonth is the period of one calendar month recurring each calendar year (such as the month of April). Its lexical space should follow the ISO 8601 syntax for such periods (i.e., -- MM) with an optional time zone. Tip There's a typo in the W3C XML Schema Recommendation, in which the format is defined as -- MM -- --. Even though an erratum should be published to bring the W3C XML Schema inline with ISO 8601, most current schema processors expect the (bogus) -- MM -- -- format. In the example, I follow the correct ISO 8601 format." By looking into the latest XSD spec, it now says "--MM". So you're right, the --MM is the correct format. So the bottom line is that if you pass the correct format --MM to some JDKs such as SUN JDK 5.x, the test case wil fail. But the IBM JDK seems to be happy with both format. If I remember correctly, SUN JDK 6.x now expects --MM. Could you tell us which JDK you're using? We could make this paticular test case JDK-version sensitive. Thanks, Raymond - Original Message - From: "Bill Barnhill" <[EMAIL PROTECTED]> To: Sent: Saturday, May 19, 2007 10:24 AM Subject: New to Tuscany, would like to contribute small fix to one of the tests > Hi all, > > I just checked out the java tree and encountered the following problem, > which seems fixable with a one line change (details at bottom). > > Running > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094sec > <<< FAILURE! > testMap( > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase ) > Time elapsed: 0.078 sec <<< ERROR! > java.lang.IllegalArgumentException: --02-- >at > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parseInt > (XMLGregorianCalendarImpl.java:2789) >at > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parse > (XMLGregorianCalendarImpl.java:2711) >at > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl > .(XMLGregorianCalendarImpl.java:433) >at > com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar > (DatatypeFactoryImpl.java:230) >at > org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject( > SimpleTypeMapperImpl.java:330) >at > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase.testMap > (SimpleTypeMapperExtensionTestCase.java:107) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) >at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:589) >at junit.framework.TestCase.runTest(TestCase.java:168) >at junit.framework.TestCase.runBare(TestCase.java:134) >at junit.framework.TestResult$1.protect(TestResult.java:110) >at junit.framework.TestResult.runProtected(TestResult.java:128) >at junit.framework.TestResult.run(TestResult.java:113) >at junit.framework.TestCase.run(TestCase.java:124) >at junit.framework.TestSuite.runTest(TestSuite.java:232) >at junit.framework.TestSuite.run(TestSuite.java:227) >at org.junit.internal.runners.OldTestClassRunner.run( > OldTestClassRunner.java:35) >at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( > JUnit4Tes
Re: New to Tuscany, would like to contribute small fix to one of the tests
Just took a look inside contrib/host-equinox and discovered it's empty other than skeleton code for launching equinox. My impression from http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html that OSGi was that OSGi support would probably be working now. What I'd like is an SCA runtime working as a set of bundles within equinox and a test/demo bundle that locates and invokes services. Or is that something that's not done yet? Thanks, Bill On 5/19/07, Bill Barnhill <[EMAIL PROTECTED]> wrote: Hi Raymond, Thanks for the welcome. You hit the nail on the head. I had thought I was building with Sun JDK 1.5, turns out I was building with Sun JDK 1.6. I switched to 1.5 and it blew past that problem and another I was having. I did have to make one change to get it to build though, even under 1.5(though old version fo 1.5..1.50_06-b05, :) I need to update). That change was to add the following snippet for the servlet-api 2.5dependency to java\sca\itest\databindings\sdogen\src\main\resources\generate\pom.xml.vm: javax.servlet servlet-api 2.5 test http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html, but the code seems to have changed from that. My goal is to have an SCA runtime within equinox, able to access SCA components (some remote web services, some local components) that are each packaged in individual bundles. Thanks, Bill On 5/19/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, Bill. > > Welcome to Tuscany. > > You hit an interesting known issue related to the format of xsd:gMonth > described at http://books.xmlschemata.org/relaxng/ch19-77111.html . The > following is quoted from that page: > > "The value space of xsd:gMonth is the period of one calendar month > recurring > each calendar year (such as the month of April). Its lexical space > should > follow the ISO 8601 syntax for such periods ( i.e., -- MM) with an > optional > time zone. > Tip > There's a typo in the W3C XML Schema Recommendation, in which the format > is > defined as -- MM -- --. Even though an erratum should be published to > bring > the W3C XML Schema inline with ISO 8601, most current schema processors > expect the (bogus) -- MM -- -- format. > > In the example, I follow the correct ISO 8601 format." > > By looking into the latest XSD spec, it now says "--MM". So you're > right, > the --MM is the correct format. > > So the bottom line is that if you pass the correct format --MM to some > JDKs > such as SUN JDK 5.x, the test case wil fail. But the IBM JDK seems to be > happy with both format. If I remember correctly, SUN JDK 6.x now > expects --MM. > > Could you tell us which JDK you're using? We could make this paticular > test > case JDK-version sensitive. > > Thanks, > Raymond > > ----- Original Message - > From: "Bill Barnhill" < [EMAIL PROTECTED]> > To: > Sent: Saturday, May 19, 2007 10:24 AM > Subject: New to Tuscany, would like to contribute small fix to one of > the > tests > > > > Hi all, > > > > I just checked out the java tree and encountered the following > problem, > > which seems fixable with a one line change (details at bottom). > > > > Running > > > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094sec > > <<< FAILURE! > > testMap( > > > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase > ) > > Time elapsed: 0.078 sec <<< ERROR! > > java.lang.IllegalArgumentException: --02-- > >at > > > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parseInt > > (XMLGregorianCalendarImpl.java:2789) > >at > > > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl$Parser.parse > > (XMLGregorianCalendarImpl.java:2711) > >at > > > com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl > > .(XMLGregorianCalendarImpl.java:433) > >at > > > com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar > > (DatatypeFactoryImpl.java:230) > >at > > > org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject > ( > > SimpleTypeMapperImpl.java:330) > >at > > > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase.testMap > > (SimpleTypeMapperExtensionTestCase.java:107) > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Re: New to Tuscany, would like to contribute small fix to one of the tests
The OSGi support has fallen behind with all the refactoring of the runtime. The most recent working code was this great sample from Joel [1], but thats based on the old Tuscany M2 runtime. Now would be a really good time to get OSGi support going again. Seems like there's lots of interest in SCA and OSGi and the Tuscany runtime and SPIs are now really clean and stable so it should be much easier to get things working. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/[EMAIL PROTECTED] On 5/19/07, Bill Barnhill <[EMAIL PROTECTED]> wrote: Just took a look inside contrib/host-equinox and discovered it's empty other than skeleton code for launching equinox. My impression from http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html that OSGi was that OSGi support would probably be working now. What I'd like is an SCA runtime working as a set of bundles within equinox and a test/demo bundle that locates and invokes services. Or is that something that's not done yet? Thanks, Bill On 5/19/07, Bill Barnhill <[EMAIL PROTECTED]> wrote: > > Hi Raymond, > > Thanks for the welcome. You hit the nail on the head. I had thought I was > building with Sun JDK 1.5, turns out I was building with Sun JDK 1.6. I > switched to 1.5 and it blew past that problem and another I was having. I > did have to make one change to get it to build though, even under 1.5(though old version fo > 1.5..1.50_06-b05, :) I need to update). > > That change was to add the following snippet for the servlet-api 2.5dependency to > java\sca\itest\databindings\sdogen\src\main\resources\generate\pom.xml.vm: > > javax.servlet > servlet-api > 2.5 > test > > It build fine now, and I am trying to figure out how to build the OSGi > modules in contrib. I'd appreciate a pointer to any readmes on that if they > exist. I have read > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html, but > the code seems to have changed from that. > > My goal is to have an SCA runtime within equinox, able to access SCA > components (some remote web services, some local components) that are each > packaged in individual bundles. > > Thanks, > Bill > > On 5/19/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > Hi, Bill. > > > > Welcome to Tuscany. > > > > You hit an interesting known issue related to the format of xsd:gMonth > > described at http://books.xmlschemata.org/relaxng/ch19-77111.html . The > > following is quoted from that page: > > > > "The value space of xsd:gMonth is the period of one calendar month > > recurring > > each calendar year (such as the month of April). Its lexical space > > should > > follow the ISO 8601 syntax for such periods ( i.e., -- MM) with an > > optional > > time zone. > > Tip > > There's a typo in the W3C XML Schema Recommendation, in which the format > > is > > defined as -- MM -- --. Even though an erratum should be published to > > bring > > the W3C XML Schema inline with ISO 8601, most current schema processors > > expect the (bogus) -- MM -- -- format. > > > > In the example, I follow the correct ISO 8601 format." > > > > By looking into the latest XSD spec, it now says "--MM". So you're > > right, > > the --MM is the correct format. > > > > So the bottom line is that if you pass the correct format --MM to some > > JDKs > > such as SUN JDK 5.x, the test case wil fail. But the IBM JDK seems to be > > happy with both format. If I remember correctly, SUN JDK 6.x now > > expects --MM. > > > > Could you tell us which JDK you're using? We could make this paticular > > test > > case JDK-version sensitive. > > > > Thanks, > > Raymond > > > > - Original Message - > > From: "Bill Barnhill" < [EMAIL PROTECTED]> > > To: > > Sent: Saturday, May 19, 2007 10:24 AM > > Subject: New to Tuscany, would like to contribute small fix to one of > > the > > tests > > > > > > > Hi all, > > > > > > I just checked out the java tree and encountered the following > > problem, > > > which seems fixable with a one line change (details at bottom). > > > > > > Running > > > > > org.apache.tuscany.sca.databinding.extension.SimpleTypeMapperExtensionTestCase > > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094sec > > > <<< FAILURE! > > > testMap( > > > > > org.apache.tuscany.sca.d
Re: New to Tuscany, would like to contribute small fix to one of the tests
I have a definite need to get Tuscany+OSGi working, so will be contributing patches on this over the next month. My first goal is to get host-equinox functioning. I've got Equinox 3.3 starting from within the test and am working on a BundleActivator that does the majority of the host work. I'll do a fresh checkout tomorrow and make sure the servlet-api add works as well, though I think it will. On 5/21/07, ant elder <[EMAIL PROTECTED]> wrote: The OSGi support has fallen behind with all the refactoring of the runtime. The most recent working code was this great sample from Joel [1], but thats based on the old Tuscany M2 runtime. Now would be a really good time to get OSGi support going again. Seems like there's lots of interest in SCA and OSGi and the Tuscany runtime and SPIs are now really clean and stable so it should be much easier to get things working. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/[EMAIL PROTECTED] On 5/19/07, Bill Barnhill <[EMAIL PROTECTED]> wrote: > > Just took a look inside contrib/host-equinox and discovered it's empty > other > than skeleton code for launching equinox. My impression from > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html that > OSGi was that OSGi support would probably be working now. What I'd like is > an SCA runtime working as a set of bundles within equinox and a test/demo > bundle that locates and invokes services. Or is that something that's not > done yet? > > Thanks, > Bill > > On 5/19/07, Bill Barnhill <[EMAIL PROTECTED]> wrote: > > > > Hi Raymond, > > > > Thanks for the welcome. You hit the nail on the head. I had thought I > was > > building with Sun JDK 1.5, turns out I was building with Sun JDK 1.6 . I > > switched to 1.5 and it blew past that problem and another I was > having. I > > did have to make one change to get it to build though, even under 1.5 (though > old version fo > > 1.5..1.50_06-b05, :) I need to update). > > > > That change was to add the following snippet for the servlet-api > 2.5dependency to > > > java\sca\itest\databindings\sdogen\src\main\resources\generate\pom.xml.vm: > > > > javax.servlet > > servlet-api > > 2.5 > > test > > > > > It build fine now, and I am trying to figure out how to build the OSGi > > modules in contrib. I'd appreciate a pointer to any readmes on that if > they > > exist. I have read > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15054.html, but > > the code seems to have changed from that. > > > > My goal is to have an SCA runtime within equinox, able to access SCA > > components (some remote web services, some local components) that are > each > > packaged in individual bundles. > > > > Thanks, > > Bill > > > > On 5/19/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > > > Hi, Bill. > > > > > > Welcome to Tuscany. > > > > > > You hit an interesting known issue related to the format of xsd:gMonth > > > described at http://books.xmlschemata.org/relaxng/ch19-77111.html . > The > > > following is quoted from that page: > > > > > > "The value space of xsd:gMonth is the period of one calendar month > > > recurring > > > each calendar year (such as the month of April). Its lexical space > > > should > > > follow the ISO 8601 syntax for such periods ( i.e., -- MM) with an > > > optional > > > time zone. > > > Tip > > > There's a typo in the W3C XML Schema Recommendation, in which the > format > > > is > > > defined as -- MM -- --. Even though an erratum should be published to > > > bring > > > the W3C XML Schema inline with ISO 8601, most current schema > processors > > > expect the (bogus) -- MM -- -- format. > > > > > > In the example, I follow the correct ISO 8601 format." > > > > > > By looking into the latest XSD spec, it now says "--MM". So you're > > > right, > > > the --MM is the correct format. > > > > > > So the bottom line is that if you pass the correct format --MM to some > > > JDKs > > > such as SUN JDK 5.x, the test case wil fail. But the IBM JDK seems to > be > > > happy with both format. If I remember correctly, SUN JDK 6.x now > > > expects --MM. > > > > > > Could you tell us which JDK you're using? We could make this paticular > > > test > &
