Re: SCA runtimes
On Jan 25, 2008 5:51 AM, Simon Laws [EMAIL PROTECTED] wrote: On Jan 24, 2008 5:58 PM, ant elder [EMAIL PROTECTED] wrote: On Jan 24, 2008 4:20 PM, ant elder [EMAIL PROTECTED] wrote: Updating this list with other suggestions gives (added points 6-9): 1) applications to contain only the code and other artifacts required for the application itself not Tuscany internals - simple sca contribution jars 2) some sort of runtime(s) which can run those application contribution jars, so that could be things like standalone (command prompt), from testcases, in a webapp, or some customization of something like Tomcat/Geronimo/WebSphere/JBoss etc 3) Those runtimes need to be distributed but the Tuscany download page should have a small number of downloads so its easy for users to work out which to choose 4) To make it easy for newbies to run things so at least one distribution should have prebuilt samples so they can be run out-of-the box without having to be compiled/built and for things to work without having to do much/any messing about with installation/configuration/customizing. 5) Ideally the easy to use distribution is not so large. 6) automatic testing of samples 7) smaller packages 8) easier for people to find what they need 9) provide people with packages that fit their scenarios, not cluttered with other things they don't need This list is already pretty much in the order I favour, (1) being more important than (9). How would others arrange it? ...ant Looks ok to me but what is the difference between 7) smaller packages and 5) Ideally the easy to use distribution is not so large. Are these just generally saying that we should make our distributions as small as possible? Simon You're right, i agree 5 and 7 are the same so one could be dropped from the list. I think not too big rather than as small as possible, not sure how big that means, wouldn't like it much if it got bigger than the current 65 Meg. ...ant
[Java SDO] getEncoding() during load() - issues + TUSCANY-1545
I am making this a separate thread and referring it in
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02447.html
as this can be my local setup issue and so don't want to mix with the
release thread.
0] I checked that the EMF version in my classpath is 2.2.3.
1]Eclipse 3.2.1
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html
getEncoding
public java.lang.String getEncoding()
Get the XML encoding for this resource. The default is ASCII.
2]SDO Spec says default is UTF-8.
3]To adhere to SDO Spec, the rootmost place for change can be
XMLDocumentImpl class itself as this is
where SDO Impl implements commonj XMLDocument and contain EMF's XMLResource.
So if inside protected XMLDocumentImpl(ExtendedMetaData extendedMetaData,
Object options)
we do resource.setEncoding(UTF-8); after the Resource is obtained from
EMF's ResourceSet we are all set for save as well as load.
4]If we look at the current 1545 patch, it was doing setEncoding() in
XMLHelperImp.createDocument(). This gets called during save() but not during
load().
In this same class if we look at load(InputStream inputStream, String
locationURI, Object options) and load(Reader inputReader, String
locationURI, Object options)
, here we create *new instances* of XMLDocumentImpl which do not have UTF-8
set as from EMF's viewpoint, the default is ASCII. So, during load operation
the getEncoding() resulted in ASCII even if the document is saved using
'UTF-8'.
5]But still 3] as well as 1545.patch is not correct , for 2 reasons -
1 what will be the way for end user to use *any other encoding* other
than UTF-8 during save and get the same encoding back during load?
2 Also a logical assumption - when we save a resource with a particular
encoding, load should return the resource with same encoding - how to make
this
happen? Because 4]*new instance* of XMLDocument will always default to
ASCII(1]).
For 1, one way can be - user can pass XMLResource.OPTION_ENCODING during
save and
inside SDO Impl, we need to make sure this option is passed to EMF. And when
such option is passed in during save() it should be honored and
default UTF-8 should not be used.
Ref:
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html
OPTION_ENCODING
public static final java.lang.String OPTION_ENCODING
Specify the XML encoding to be used *during save*.
But for 2 i.e. get the same encoding back during load without any special
option passing and without setEncoding() - what is the solution?
Also found below - so the correct behavior should be available in EMF
2.2.3and further.
http://www.eclipse.org/modeling/emf/news/relnotes.php?project=emfversion=2.2.x
* 2.2.2
* 2.2.2RC2 (2 bugs fixed)
o 173815 Bad link exist on EMF/SDO/XSD Developer Guide
o 173681 encoding is ignored during XMLResource#load
*
surefire-reports
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.172 sec
FAILURE!
testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) Time elapsed:
3.125 sec FAILURE!
junit.framework.AssertionFailedError: Encoding ('ASCII' is not correct.
UTF-8 is the expected encoding.
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding (
XMLHelperTestCase.java:313)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding(
XMLHelperTestCase.java:313)
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:597)
at junit.framework.TestCase.runTest (TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run( TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet (
AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
[jira] Resolved: (TUSCANY-1531) Java SDO Documentation page should be updated to default website stype/design
[ https://issues.apache.org/jira/browse/TUSCANY-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-1531. -- Resolution: Fixed After some content updates as shown in http://cwiki.apache.org/TUSCANY/sdo-java-documentation-menu.html, the issues mentioned in this JIRA seem to be resolved. Java SDO Documentation page should be updated to default website stype/design - Key: TUSCANY-1531 URL: https://issues.apache.org/jira/browse/TUSCANY-1531 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-SDO-Next Reporter: Luciano Resende Fix For: Java-SDO-Next The default left side menus are missing or wrong Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation-menu.html as it's one of the pages with more contents on it. User guide has wrong styles : http://incubator.apache.org/tuscany/sdo-java-user-guide.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
Thank you, Sebastien. Graham or I will provide the changes once the new distribution poms are ready. Thank you... Regards, Rajini On 1/24/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Would it be possible to add an OSGi manifest header into these zip files so that the zips can be directly installed into an OSGi runtime? The entries will not have any impact when used without OSGi. +1 The only issue would be the creation of these entries. We have two options - 1)generate them automatically during the build process using the maven-bundle-plugin, +1 or another automated process or 2) hand-code a manifest file. It would be easiest to go with option 2) to start with to avoid any build issues. If it becomes difficult to maintain the hand-coded manifest file, we can move to option 1). I'd suggest to write it by hand once to define the target to automate, then automate its generation right away. The manifest entries will contain bundle names, versions, imported packages, exported packages and a bundle classpath(which lists jars contained inside the zip). Can you post an example or put it in SVN? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release
On Jan 24, 2008 9:39 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, Simon Laws [EMAIL PROTECTED] wrote: Hi sebb Thank you for the detailed review. Can you tell me what you mean by On Jan 24, 2008 4:57 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, ant elder [EMAIL PROTECTED] wrote: I think the NOTICE files in the artifacts that are actually being distributed are OK. Surely the archive bundles are also distributed? I meant that the files in the quote Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/ /quote are actually being distributed. I took Ant Elder's comment to mean that these were not being distributed. snip.. Also can you tell me if you consider that the issues you have found to be blocking issues? Yes, I think the discrepancies in the LICENSE file need to be addressed. Also, comparing the SVN tag with the source archive shows that there are quite a few files and directories that are missing from the source archive. There are several files in the source archive that are not in SVN, which probably should be in SVN, for example: BUILDING CHANGES DISCLAIMER LICENSE NOTICE README RELEASE_NOTES demos/alert-aggregator-webapp/build-dependency.xml demos/xml-bigbank/build-dependency.xml itest/databindings/interop/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/InteropDatabindingTestCase.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterService.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClient.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClientImpl.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceImpl.java itest/databindings/jaxbgen/src/test/java/org/apache/tuscany/sca/itest/jaxbdatabinding/DatabindingTestCase.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterService.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceClientImpl.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceImpl.java itest/databindings/sdogen/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/DatabindingTestCase.java samples/calculator-webapp/build.xml samples/calculator-ws-webapp/build.xml samples/chat-webapp/build.xml samples/feed-aggregator-webapp/build.xml samples/helloworld-dojo-webapp/build-dependency.xml samples/helloworld-jsonrpc-webapp/build.xml samples/helloworld-ws-sdo-webapp/build-dependency.xml There are also a lot of files in SVN, which are not in the source archive: demos/alert-aggregator-webapp/alert-aggregator.svg demos/bigbank-account/bigbank.svg demos/bigbank-calculator/src/test demos/secure-bigbank/secure-bigbank-account/bigbank.svg demos/secure-bigbank/secure-bigbank-calculator/src/test demos/xml-bigbank/xml-bigbank.svg distribution/standalone/src/main/resources distribution/tomcat/src/test distribution/webapp/src/test distribution/webapp/src/main/resources itest/admin/src/test/java/test itest/contribution-import-export/export-java/src/test itest/contribution-import-export/export-wsdl/src/test itest/contribution-import-export/export-wsdl/src/main/java itest/contribution-multiple/src/main itest/databindings/config.svg itest/databindings/databinding.svg itest/databindings/interop.svg itest/domain/src/main/java/org itest/interop-soap-client/src/test/resources itest/osgi-contribution/contribution-classes-v2/src/test itest/osgi-contribution/contribution-classes/src/test itest/transaction/src/test/resources itest/wsdl2java/src/main itest/wsdl2java/src/test/java modules/implementation-das modules/binding-dwr/src/test modules/binding-ws-axis2/src/main/assembly modules/binding-ws/src/test modules/contribution-java/src/test/resources modules/contribution-namespace/src/test/resources modules/contribution-osgi/src/test modules/contribution/src/test modules/core-databinding/src/test/java/org/apache/tuscany/core modules/core-spi/src/test modules/data-engine-helper/src/test modules/data-engine-helper/src/main/resources modules/databinding-saxon/src/test modules/definitions/src/test modules/definitions/src/main/resources modules/domain-api/src/test modules/domain/src/test modules/extension-helper/src/test modules/host-http/src/test modules/host-jms-activemq/src/test modules/host-jms/src/test modules/host-osgi/src/test modules/host-osgi/src/main/java modules/host-webapp/src/test modules/implementation-spring/src/test/java/org/apache/tuscany/implementation modules/implementation-xquery/src/test modules/implementation-xquery/src/main/java/org/apache/tuscany/implementation
Re: SCA contribution packaging schemes: was: SCA runtimes
On Jan 24, 2008 7:47 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: [snip] The (F), (G) and (H) would use the packaging in your (B). For your (B) how/where were you expecting those sca contribution jars to get used? Ah I'm happy to see that there are not so many packaging schemes after all :) We've already started to discuss contribution usage scenarios in [1]. Here's a longer scenario, showing how I want to use contributions and composites in a domain for the store tutorial I've been working on. There are three contributions in the tutorial: - assets.jar containing most implementation artifacts - store.jar containing the main store components - cloud.jar containing utility components in the service cloud Both store.jar and cloud.jar import artifacts from assets.jar. 1. Create assets.jar and store.jar (using scheme B). 2. Open my tutorial domain in my Web browser, upload store.jar to the domain. 3. List the contributions in the domain, store.jar shows a red-x error as some of its imports are not resolvable. 4. Upload assets.jar. Both assets.jar and store.jar show in the list with no red-x. 5. List the deployable composites, find http://store#store under store.jar. Open it in my browser to check it's what I want. 6. Mark http://store#store as deployed. Store has a reference to a CurrencyConverter service (from composite http://cloud#cloud which is not in my domain yet) so it shows a red-x and appears disabled. 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it, mark it deployed. The red-x on deployed composite http://store#store is now gone. 8. Assuming I have 2 machines for running SCA in my network and have already declared these 2 machines to my domain, allocate composites to them. Select http://store#store and associate it with machine1. Store.jar and assets.jar are downloaded to machine1 and machine1 configured with http://store#store. 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar and assets.jar are downloaded to machine2 and machine2 is configured with http://cloud#cloud. 10. Display the list of deployed composites, select http://store#store, click the start button, select http://cloud#cloud, click start. Hope this helps. [1] http://marc.info/?l=tuscany-devm=119952302226006 -- Jean-Sebastien That all sounds wonderful, will be really good when we get to there. There's a lot to do for all that to work though so as a stepping stone how about getting this to work on a single node first without the gui and individual deployment steps and then add those things once we have something basic working? Where do we want this to run? - I'd quite like at least one of the options to be as a regular webapp in Tomcat. ...ant
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release
On Jan 25, 2008 8:59 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 24, 2008 9:39 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, Simon Laws [EMAIL PROTECTED] wrote: Hi sebb Thank you for the detailed review. Can you tell me what you mean by On Jan 24, 2008 4:57 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, ant elder [EMAIL PROTECTED] wrote: I think the NOTICE files in the artifacts that are actually being distributed are OK. Surely the archive bundles are also distributed? I meant that the files in the quote Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/ /quote are actually being distributed. I took Ant Elder's comment to mean that these were not being distributed. snip.. Also can you tell me if you consider that the issues you have found to be blocking issues? Yes, I think the discrepancies in the LICENSE file need to be addressed. Also, comparing the SVN tag with the source archive shows that there are quite a few files and directories that are missing from the source archive. There are several files in the source archive that are not in SVN, which probably should be in SVN, for example: BUILDING CHANGES DISCLAIMER LICENSE NOTICE README RELEASE_NOTES demos/alert-aggregator-webapp/build-dependency.xml demos/xml-bigbank/build-dependency.xml itest/databindings/interop/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/InteropDatabindingTestCase.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterService.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClient.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClientImpl.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceImpl.java itest/databindings/jaxbgen/src/test/java/org/apache/tuscany/sca/itest/jaxbdatabinding/DatabindingTestCase.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterService.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceClientImpl.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceImpl.java itest/databindings/sdogen/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/DatabindingTestCase.java samples/calculator-webapp/build.xml samples/calculator-ws-webapp/build.xml samples/chat-webapp/build.xml samples/feed-aggregator-webapp/build.xml samples/helloworld-dojo-webapp/build-dependency.xml samples/helloworld-jsonrpc-webapp/build.xml samples/helloworld-ws-sdo-webapp/build-dependency.xml There are also a lot of files in SVN, which are not in the source archive: demos/alert-aggregator-webapp/alert-aggregator.svg demos/bigbank-account/bigbank.svg demos/bigbank-calculator/src/test demos/secure-bigbank/secure-bigbank-account/bigbank.svg demos/secure-bigbank/secure-bigbank-calculator/src/test demos/xml-bigbank/xml-bigbank.svg distribution/standalone/src/main/resources distribution/tomcat/src/test distribution/webapp/src/test distribution/webapp/src/main/resources itest/admin/src/test/java/test itest/contribution-import-export/export-java/src/test itest/contribution-import-export/export-wsdl/src/test itest/contribution-import-export/export-wsdl/src/main/java itest/contribution-multiple/src/main itest/databindings/config.svg itest/databindings/databinding.svg itest/databindings/interop.svg itest/domain/src/main/java/org itest/interop-soap-client/src/test/resources itest/osgi-contribution/contribution-classes-v2/src/test itest/osgi-contribution/contribution-classes/src/test itest/transaction/src/test/resources itest/wsdl2java/src/main itest/wsdl2java/src/test/java modules/implementation-das modules/binding-dwr/src/test modules/binding-ws-axis2/src/main/assembly modules/binding-ws/src/test modules/contribution-java/src/test/resources modules/contribution-namespace/src/test/resources modules/contribution-osgi/src/test modules/contribution/src/test modules/core-databinding/src/test/java/org/apache/tuscany/core modules/core-spi/src/test modules/data-engine-helper/src/test modules/data-engine-helper/src/main/resources modules/databinding-saxon/src/test modules/definitions/src/test modules/definitions/src/main/resources modules/domain-api/src/test modules/domain/src/test modules/extension-helper/src/test modules/host-http/src/test modules/host-jms-activemq/src/test modules/host-jms/src/test modules/host-osgi/src/test
Re: Size of the binary distribution
On Jan 24, 2008 7:42 PM, Luciano Resende [EMAIL PROTECTED] wrote: On Jan 24, 2008 8:49 AM, ant elder [EMAIL PROTECTED] wrote: I had a look at what makes up the size of the binary distribution, here's some details: The 1.1 binary distribution is about 65 Meg, of that 50 Meg is from all the jars in the lib directory, 8.5 Meg is from the calculator webapp sample, 2.5Meg is from the mortgage loan approval demo doc, and 2.5 Meg is from all the jars in the modules directory. In the 50 Meg lib directory there are 149 jars, but 25 Meg comes from just the 13 biggest jars (These sizes are all the compressed sizes within the archive) All that gives quite a bit of scope for tweaking, eg if we were to: - remove the modules folder as they're all in the maven repository What is the side effect of removing this folder ? Would ant scripts continue to work ? This is touched in the other threads as as one of the points we need to fix - people using Tuscany shouldn't have to know about its internals so application build scripts shouldn't be directly referencing the individual Tuscany modules. - remove the prebuilt calc webapp sample, we're talking about changing to use simple contributions jars anyway - change the mortgage loan approval demo doc to be plain text or point to the website - remove all but one of the bundled script language engines (ie JRuby, Jython and Groovy) - change wsdl2java to using its own namespace to package name code instead of using XJC - (maybe) not include the xmlbeans and xbean jars xmlBeans and xBean are BPEL/ODE dependencies Is xbean really used by Ode, i've tried removing it and implementation-bpel still seems to work fine? Our Axis binding was unnecessarily dragging in the xbean dependency which i've now removed, the only place that I knew of that we really did use xbean was with E4X when we were on an old Rhino release but thats not needed in the newer Rhino releases. Adding to the list : - remove derby dbs ( ~ 4.0 MB each ) from SVN and make the build create the necessary dbs. That would be really good, its not great to have the database binaries in our src. ...ant
[jira] Created: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures
include apache headers in xmls and xsds without causing test case failures -- Key: TUSCANY-2011 URL: https://issues.apache.org/jira/browse/TUSCANY-2011 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next there are total 7 files in sdo-impl and 3 files in tools-test which can contain Apache headers without any test case failures, so do so for a successful RAT report -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2012) Build Failure due to compilation problems in module 'implementation-widget'
Build Failure due to compilation problems in module 'implementation-widget' Key: TUSCANY-2012 URL: https://issues.apache.org/jira/browse/TUSCANY-2012 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Priority: Blocker [INFO] [INFO] Building Apache Tuscany SCA Widget Implementation Extension [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 9 source files to /home/continuum/data/working-directory/277/modules/implementation-widget/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[37,24] package com.ibm.jvm.util does not exist /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[97,8] cannot find symbol symbol : class ByteArrayOutputStream location: class org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationInvoker /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[97,40] cannot find symbol symbol : class ByteArrayOutputStream location: class org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationInvoker [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 minutes 29 seconds [INFO] Finished at: Fri Jan 25 03:16:35 PST 2008 [INFO] Final Memory: 53M/100M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2015) OSGI iTests are referencing Felix SNAPSHOTs
OSGI iTests are referencing Felix SNAPSHOTs --- Key: TUSCANY-2015 URL: https://issues.apache.org/jira/browse/TUSCANY-2015 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.1 Reporter: Luciano Resende Fix For: Java-SCA-1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inconsistent pom for jaxws-api 2.1
Hi, Our build has a dependency on javax.xml.ws:jaxws-api:2.1. And we have the java.net configured as a maven repo in our pom.xml. The build fails randomly because the same artifact is available at [2] but it has a different pom as [1]. A bunch of transitive dependencies are missing in [2], such as jsr-181. If it happens that [2] is downloaded by mvn, then our build will fail. [1] http://download.java.net/maven/1/javax.xml.ws/poms/jaxws-api-2.1.pom [2] http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.pom Is this a bug in [2]? Is there a way that we can define the ordering of the maven repo so that we can consistenly get [1]? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany 1.1 build failure
Could you please try to build itest/osgi-implementation with a mvn -U
clean install and see if you still have issues. I just tried and it
completed successfully even with all felix artifacts removed from my
local maven repo.
On Jan 25, 2008 3:11 PM, sebb [EMAIL PROTECTED] wrote:
On 25/01/2008, sebb [EMAIL PROTECTED] wrote:
I got a couple of failures when trying to build the Tuscany 1.1 source.
The first time, I got an out of memory error from Java.
I'm assuming this was due to the hundreds of jar and digest files that
were downloaded (at least 760 jar+digest), as the error did not occur
the second time. Possibly this is a memory leak in Maven.
BTW, it looks like the M2 build downloads multiple versions of some jars,
e.g :
backport-util-concurrent v2.1 and v2.1
jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
However, the second time I tried, I got the following error:
snip/
---
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
sdl.sdo\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.description.AxisService).
log4j:WARN Please initialize the log4j system properly.
Generating Java class
stockexceptiontestservice.scatesttool.StockExceptionTest
[WARNING] POM for
'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
It will be ignored for artifact resolution. R
eason: Failed to validate POM for project
com.sun.xml.stream.buffer:streambuffer at Artifact
[com.sun.xml.stream.buffer:streambuffer
:pom:0.4:compile]
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v
4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
x-1.0.pom
[INFO] [jaxws:wsimport {execution: generate-jaxb}]
[INFO] Processing:
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-d, D:
\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.exceptions.
impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...
generating code...
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
[ERROR] null
unknown location
compilation failed, errors should have been reported
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsimport [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-
d,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.except
ions.impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 28 minutes 48 seconds
[INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
[INFO] Final Memory: 59M/63M
[INFO]
---
I will probably try re-running the build again at some point so I can
collect the full log.
Had to increase the memory allocation.
Latest test failed with 3 missing artifacts:
1)
[jira] Created: (TUSCANY-2014) XMLDocument object's rootElement member not intialized properly
XMLDocument object's rootElement member not intialized properly --- Key: TUSCANY-2014 URL: https://issues.apache.org/jira/browse/TUSCANY-2014 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next This problem occurs during a roundtrip operation where a new SDO Type is created, then an instance DO is created from that type. That instance DO is then serialized to an XML document. Then, using XMLHelper.load(String), the document is loaded into an XMLDocument object. When that object is inspected, the rootElement member is not set properly, implying there is either something wrong with the serialization of the DO or the deseriazliation of the xml document. Investigation is underway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2013) Remove derby sample databases from svn and create it dynamicaly
Remove derby sample databases from svn and create it dynamicaly --- Key: TUSCANY-2013 URL: https://issues.apache.org/jira/browse/TUSCANY-2013 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next See discussion on the following thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27351.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release
On 25/01/2008, Simon Laws [EMAIL PROTECTED] wrote: On Jan 25, 2008 8:59 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 24, 2008 9:39 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, Simon Laws [EMAIL PROTECTED] wrote: Hi sebb Thank you for the detailed review. Can you tell me what you mean by On Jan 24, 2008 4:57 PM, sebb [EMAIL PROTECTED] wrote: On 24/01/2008, ant elder [EMAIL PROTECTED] wrote: I think the NOTICE files in the artifacts that are actually being distributed are OK. Surely the archive bundles are also distributed? I meant that the files in the quote Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/ /quote are actually being distributed. I took Ant Elder's comment to mean that these were not being distributed. snip.. Also can you tell me if you consider that the issues you have found to be blocking issues? Yes, I think the discrepancies in the LICENSE file need to be addressed. Also, comparing the SVN tag with the source archive shows that there are quite a few files and directories that are missing from the source archive. There are several files in the source archive that are not in SVN, which probably should be in SVN, for example: BUILDING CHANGES DISCLAIMER LICENSE NOTICE README RELEASE_NOTES demos/alert-aggregator-webapp/build-dependency.xml demos/xml-bigbank/build-dependency.xml itest/databindings/interop/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/InteropDatabindingTestCase.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterService.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClient.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClientImpl.java itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceImpl.java itest/databindings/jaxbgen/src/test/java/org/apache/tuscany/sca/itest/jaxbdatabinding/DatabindingTestCase.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterService.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceClientImpl.java itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceImpl.java itest/databindings/sdogen/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/DatabindingTestCase.java samples/calculator-webapp/build.xml samples/calculator-ws-webapp/build.xml samples/chat-webapp/build.xml samples/feed-aggregator-webapp/build.xml samples/helloworld-dojo-webapp/build-dependency.xml samples/helloworld-jsonrpc-webapp/build.xml samples/helloworld-ws-sdo-webapp/build-dependency.xml There are also a lot of files in SVN, which are not in the source archive: demos/alert-aggregator-webapp/alert-aggregator.svg demos/bigbank-account/bigbank.svg demos/bigbank-calculator/src/test demos/secure-bigbank/secure-bigbank-account/bigbank.svg demos/secure-bigbank/secure-bigbank-calculator/src/test demos/xml-bigbank/xml-bigbank.svg distribution/standalone/src/main/resources distribution/tomcat/src/test distribution/webapp/src/test distribution/webapp/src/main/resources itest/admin/src/test/java/test itest/contribution-import-export/export-java/src/test itest/contribution-import-export/export-wsdl/src/test itest/contribution-import-export/export-wsdl/src/main/java itest/contribution-multiple/src/main itest/databindings/config.svg itest/databindings/databinding.svg itest/databindings/interop.svg itest/domain/src/main/java/org itest/interop-soap-client/src/test/resources itest/osgi-contribution/contribution-classes-v2/src/test itest/osgi-contribution/contribution-classes/src/test itest/transaction/src/test/resources itest/wsdl2java/src/main itest/wsdl2java/src/test/java modules/implementation-das modules/binding-dwr/src/test modules/binding-ws-axis2/src/main/assembly modules/binding-ws/src/test modules/contribution-java/src/test/resources modules/contribution-namespace/src/test/resources modules/contribution-osgi/src/test modules/contribution/src/test modules/core-databinding/src/test/java/org/apache/tuscany/core modules/core-spi/src/test modules/data-engine-helper/src/test modules/data-engine-helper/src/main/resources modules/databinding-saxon/src/test modules/definitions/src/test modules/definitions/src/main/resources modules/domain-api/src/test
Tuscany 1.1 build failure
I got a couple of failures when trying to build the Tuscany 1.1 source.
The first time, I got an out of memory error from Java.
I'm assuming this was due to the hundreds of jar and digest files that
were downloaded (at least 760 jar+digest), as the error did not occur
the second time. Possibly this is a memory leak in Maven.
BTW, it looks like the M2 build downloads multiple versions of some jars, e.g :
backport-util-concurrent v2.1 and v2.1
jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
However, the second time I tried, I got the following error:
snip/
---
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
sdl.sdo\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.description.AxisService).
log4j:WARN Please initialize the log4j system properly.
Generating Java class
stockexceptiontestservice.scatesttool.StockExceptionTest
[WARNING] POM for
'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
It will be ignored for artifact resolution. R
eason: Failed to validate POM for project
com.sun.xml.stream.buffer:streambuffer at Artifact
[com.sun.xml.stream.buffer:streambuffer
:pom:0.4:compile]
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v
4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
x-1.0.pom
[INFO] [jaxws:wsimport {execution: generate-jaxb}]
[INFO] Processing:
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-d, D:
\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.exceptions.
impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...
generating code...
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
[ERROR] null
unknown location
compilation failed, errors should have been reported
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsimport [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-
d,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.except
ions.impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 28 minutes 48 seconds
[INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
[INFO] Final Memory: 59M/63M
[INFO]
---
I will probably try re-running the build again at some point so I can
collect the full log.
S///
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany 1.1 build failure
On 25/01/2008, sebb [EMAIL PROTECTED] wrote:
I got a couple of failures when trying to build the Tuscany 1.1 source.
The first time, I got an out of memory error from Java.
I'm assuming this was due to the hundreds of jar and digest files that
were downloaded (at least 760 jar+digest), as the error did not occur
the second time. Possibly this is a memory leak in Maven.
BTW, it looks like the M2 build downloads multiple versions of some jars, e.g
:
backport-util-concurrent v2.1 and v2.1
jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
However, the second time I tried, I got the following error:
snip/
---
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
sdl.sdo\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.description.AxisService).
log4j:WARN Please initialize the log4j system properly.
Generating Java class
stockexceptiontestservice.scatesttool.StockExceptionTest
[WARNING] POM for
'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
It will be ignored for artifact resolution. R
eason: Failed to validate POM for project
com.sun.xml.stream.buffer:streambuffer at Artifact
[com.sun.xml.stream.buffer:streambuffer
:pom:0.4:compile]
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v
4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
x-1.0.pom
[INFO] [jaxws:wsimport {execution: generate-jaxb}]
[INFO] Processing:
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-d, D:
\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.exceptions.
impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...
generating code...
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
[ERROR] null
unknown location
compilation failed, errors should have been reported
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsimport [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-
d,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.except
ions.impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 28 minutes 48 seconds
[INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
[INFO] Final Memory: 59M/63M
[INFO]
---
I will probably try re-running the build again at some point so I can
collect the full log.
Had to increase the memory allocation.
Latest test failed with 3 missing artifacts:
1) org.apache.felix:org.apache.felix.configadmin:jar:0.9.0-SNAPSHOT
2) org.apache.felix:org.apache.felix.log:jar:0.9.0-incubator-SNAPSHOT
3) org.apache.felix:org.apache.felix.scr:jar:0.9.0-SNAPSHOT
S///
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA contribution packaging schemes: was: SCA runtimes
Sebastien/Ant Here's a longer scenario, showing how I want to use contributions and composites in a domain for the store tutorial I've been working on. A real eye opener. Thank you for this. snip... getting this to work on a single node first without the gui and individual deployment steps and then add those things once we have something basic working? How about the following as some first steps. 1. Disengage the Node from the domain in the way that it is connected at the moment leaving the Node able to load Contributions and start composites as it does currently in stand alone mode. Doing this we remove the sca application that is used to connect the node to the domain and the need to pull in WS, JSON etc that came up on another thread. 2. Wrap the Node in the first run options we want to test with (standalone and tomcat webapp would give us enough to try most of the samples). Add the code that loads all contributions that are available from the file system. Ant already has this code in various forms 3. As an experiment make a Domain that takes as input a - Contributions from disc (again can re-use Ant's contribution loading code) b - a topology file something like [1] and produces as output c - a list of which contributions need to be copied to which node and appropriate warnings about missing dependencies d - updated contributions/composites so that references that refer to services in remote nodes have absolute URLs written in to appropriate bindings. We also have most of the code already to do a-d in various places. d is the trickiest bit but provides the ideal opportunity to tidy up the binding URL calculation story. Thoughts? Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26561.html
Re: Tuscany 1.1 build failure
Hi snip.. The first time, I got an out of memory error from Java. Try doing set MAVEN_OPTS=-Xmx1024m before doing the build BTW, it looks like the M2 build downloads multiple versions of some jars, e.g : Do you mean the M2 build - that's pretty old? However, the second time I tried, I got the following error: Did you get the error with the src distro from 1.1-RC3? Not an error I've seen before. It's trying to read in a WSDL file and process it into java objects but the error shown is not all that useful. Am just about to try the full build for RC3a so I'll see what happens here. Regards Simon
Re: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
The wrong ByteArrayOutputStream was imported. I just fixed it under r615260. Thanks, Raymond - Original Message - From: Continuum VMBuild Server [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, January 25, 2008 3:21 AM Subject: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=41613projectId=277 [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2012) Build Failure due to compilation problems in module 'implementation-widget'
[ https://issues.apache.org/jira/browse/TUSCANY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-2012. --- Resolution: Fixed Fix Version/s: Java-SCA-Next Fixed under r615260 Build Failure due to compilation problems in module 'implementation-widget' Key: TUSCANY-2012 URL: https://issues.apache.org/jira/browse/TUSCANY-2012 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Priority: Blocker Fix For: Java-SCA-Next [INFO] [INFO] Building Apache Tuscany SCA Widget Implementation Extension [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/implementation-widget/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 9 source files to /home/continuum/data/working-directory/277/modules/implementation-widget/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[37,24] package com.ibm.jvm.util does not exist /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[97,8] cannot find symbol symbol : class ByteArrayOutputStream location: class org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationInvoker /home/continuum/data/working-directory/277/modules/implementation-widget/src/main/java/org/apache/tuscany/sca/implementation/widget/provider/WidgetImplementationInvoker.java:[97,40] cannot find symbol symbol : class ByteArrayOutputStream location: class org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationInvoker [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 minutes 29 seconds [INFO] Finished at: Fri Jan 25 03:16:35 PST 2008 [INFO] Final Memory: 53M/100M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2014) XMLDocument object's rootElement member not intialized properly
[ https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-2014: Attachment: Test2014.java This class will demonstrate this problem. XMLDocument object's rootElement member not intialized properly --- Key: TUSCANY-2014 URL: https://issues.apache.org/jira/browse/TUSCANY-2014 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: Test2014.java This problem occurs during a roundtrip operation where a new SDO Type is created, then an instance DO is created from that type. That instance DO is then serialized to an XML document. Then, using XMLHelper.load(String), the document is loaded into an XMLDocument object. When that object is inspected, the rootElement member is not set properly, implying there is either something wrong with the serialization of the DO or the deseriazliation of the xml document. Investigation is underway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany 1.1 build failure
That finished with BUILD SUCCESSFUL.
The errors I reported were when I was running plain mvn from the
top-level directory, which is what the vote e-mail said to do.
Are the missing artifacts due to a Maven bug or a bug in the
configuration or something else?
On 25/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
Could you please try to build itest/osgi-implementation with a mvn -U
clean install and see if you still have issues. I just tried and it
completed successfully even with all felix artifacts removed from my
local maven repo.
On Jan 25, 2008 3:11 PM, sebb [EMAIL PROTECTED] wrote:
On 25/01/2008, sebb [EMAIL PROTECTED] wrote:
I got a couple of failures when trying to build the Tuscany 1.1 source.
The first time, I got an out of memory error from Java.
I'm assuming this was due to the hundreds of jar and digest files that
were downloaded (at least 760 jar+digest), as the error did not occur
the second time. Possibly this is a memory leak in Maven.
BTW, it looks like the M2 build downloads multiple versions of some jars,
e.g :
backport-util-concurrent v2.1 and v2.1
jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
However, the second time I tried, I got the following error:
snip/
---
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
sdl.sdo\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.description.AxisService).
log4j:WARN Please initialize the log4j system properly.
Generating Java class
stockexceptiontestservice.scatesttool.StockExceptionTest
[WARNING] POM for
'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
It will be ignored for artifact resolution. R
eason: Failed to validate POM for project
com.sun.xml.stream.buffer:streambuffer at Artifact
[com.sun.xml.stream.buffer:streambuffer
:pom:0.4:compile]
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v
4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
x-1.0.pom
[INFO] [jaxws:wsimport {execution: generate-jaxb}]
[INFO] Processing:
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-d, D:
\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.exceptions.
impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...
generating code...
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
[ERROR] null
unknown location
compilation failed, errors should have been reported
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsimport [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-
d,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.except
ions.impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 28 minutes 48 seconds
[INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
[INFO] Final Memory: 59M/63M
[INFO]
