Re: Suggestions for Tuscany SCA documenation?
On 2/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Tom Seelbach wrote: If the wiki was switched to a left menu theme it would probably apply to the whole space. That would not work well for Tuscany since it has 3 separate projects (sca, sdo, das) as well as 2 implementations (java, cpp). i.e. the site is very complicated and it wouldn't be worth it to carry that left menu everywhere. There is always the horizontal link navigation at the top of every page anyway so a user is only one click from the top page. I just added a left-hand-nav to the wiki homepage to serve as a TOC. It's pretty simple. I tried to follow the existing Tuscany home as much as possible, and link to new information on the wiki as well. If the team agrees with this approach, we can migrate useful information off of the existing homepage and onto the wiki. If the team doesn't think this is the way to go, its a simple undo. +1, I like it. I'm willing to port some of the existing pages over and update them in the process if this helps. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Tom Sidebar looks good to me. Lets give it a spin and see how it goes. +1 Simon
Re: Suggestions for Tuscany SCA documenation?
I like the idea of having a side navigator; a little concerned of the potential maintenance overhead of this on each wiki page that needs a navigator (although I guess it isn't needed on every page ?), but we'll only find out once we have a reasonable body of work, so I'll go with Simon's give it a spin and see how it goes There is/was also a thread about wiki versus web site @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12431.html which I'm not sure reached any conclusion about what content (if any) should remain on the web site and what should move to the wiki It seems a shame to loose the Tuscany LF; perhaps the number of people who have offered to help with the wiki based documentation outweighs the value of the Tuscany LF - it's not like the cwiki is ugly :) On 14/02/07, Simon Laws [EMAIL PROTECTED] wrote: On 2/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Tom Seelbach wrote: If the wiki was switched to a left menu theme it would probably apply to the whole space. That would not work well for Tuscany since it has 3 separate projects (sca, sdo, das) as well as 2 implementations (java, cpp). i.e. the site is very complicated and it wouldn't be worth it to carry that left menu everywhere. There is always the horizontal link navigation at the top of every page anyway so a user is only one click from the top page. I just added a left-hand-nav to the wiki homepage to serve as a TOC. It's pretty simple. I tried to follow the existing Tuscany home as much as possible, and link to new information on the wiki as well. If the team agrees with this approach, we can migrate useful information off of the existing homepage and onto the wiki. If the team doesn't think this is the way to go, its a simple undo. +1, I like it. I'm willing to port some of the existing pages over and update them in the process if this helps. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Tom Sidebar looks good to me. Lets give it a spin and see how it goes. +1 Simon
[Specs Related] Multivalued Properties
Hi, I have just looked at 'many valued properties' in the recent Assembly Model specs and have some questions. Could somebody please help me with clarifications. There are two samples on multivalued properties. One where the property is of simple type .. component name=MyValueServiceComponent implementation.java class=services.myvalue.MyValueServiceImpl/ property name=currencyEURO/property property name=currencyYen/property property name=currencyUSDollar/property reference name=customerService target=InternalCustomer/customerService/ reference name=StockQuoteService/ /component and another where the property is of complex type... property name=complexFoo MyComplexPropertyValue1 xsi:type=foo:MyComplexType attr=bar foo:aAValue/foo:a foo:bInterestingURI/foo:b /MyComplexPropertyValue1 MyComplexPropertyValue2 xsi:type=foo:MyComplexType attr=zing foo:aBValue/foo:a foo:bBoringURI/foo:b /MyComplexPropertyValue2 /property Now, don't these two representations look different. In the Simple-type property every value is enclosed in a property tag and in the complex type case all values are enclosed withing a single property tag. I'd prefer that even for the complex type property every value is enclosed in its own property tag... i.e. property name=complexFoo MyComplexPropertyValue1 xsi:type=foo:MyComplexType attr=bar foo:aAValue/foo:a foo:bInterestingURI/foo:b /MyComplexPropertyValue1 /property property name=complexFoo MyComplexPropertyValue2 xsi:type=foo:MyComplexType attr=zing foo:aBValue/foo:a foo:bBoringURI/foo:b /MyComplexPropertyValue2 /property I wish this, so that when we are loading them we may have a uniform way of interpretting them immaterial of whether the property is of simple type or complex type. Am I missing a better rationale out here ? Thanks - Venkat
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
Raymond Feng wrote: Hi, Frank. Your proposal sounds promising, I cannot wait to move to SDO 3 :-). For SDO 2.1, if it's not constrained by the spec, adding some metadata to the generated interface/class would be helpful. Thanks, Raymond - Original Message - From: Frank Budinsky (JIRA) tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 4:29 PM Subject: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) [ https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472943 ] Frank Budinsky commented on TUSCANY-1110: - Yang, can you explain more about your idea? I also have a couple of ideas for how to speed up TypeHelper.getType(Class): 1) when we move a Java5 dependency, we should generate an annotation in the interface, which we could use at runtime to find the Type. The exact format of the annotation depends on an SDO 3 feature to support Java metadata annotations, which the SDO collaboration is currently considering. 2) before Java5, we could possibly do something like this: step 1) determine the class name from the provided Class. step 2) mangle the name to determine the impl class name (e.g., org.example.Foo - org.example.impl.FooImpl) step 3) create an instance and then call getType() - or better yet, we could change the generator pattern to generate a static method that returns the type - and then call it. I'm sure there are also other possible ways to do this, but the question is what's the priority for this? Does anyone know if the current performance of this method is a concern that needs immediate attention? Improve the performance of TypeHelperImpl.getType(Class) Key: TUSCANY-1110 URL: https://issues.apache.org/jira/browse/TUSCANY-1110 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Raymond Feng Fix For: Java-SDO-Mx In the SDO databinding for SCA, we need to introspect a java class/interface to figure out the corresponding SDO type. Looking into the code, there is a TODO comment: //TODO more efficient implementation ... this is a really bad one! Do you plan to provide a more efficient impl :-)? Thanks, Raymond -- 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] I'm not 100% sure of what's being proposed here but I think Jax-B has something like this already. If I'm right maybe looking at that and as best as can be done to align it might be something worthwhile ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1111) Interchangeability of Java and WSDL
Interchangeability of Java and WSDL --- Key: TUSCANY- URL: https://issues.apache.org/jira/browse/TUSCANY- Project: Tuscany Issue Type: Bug Components: Java SCA Model Affects Versions: Java-SCA-integration Reporter: ant elder Fix For: Java-SCA-integration JIRA to track issues related to interchangeability of Java and WSDL -- 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] Resolved: (TUSCANY-928) Define Tuscany SDO options for XMLHelper load and save operations
[ https://issues.apache.org/jira/browse/TUSCANY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-928. Resolution: Fixed Resolved at level 507527 Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: https://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-Mx Attachments: ChangeSummaryPropertyTestCase.928, options.928, SDOXMLResourceImpl.928, SDOXMLResourceImpl.java, XMLHelperTestCase.java, XMLHelperTestCase.java XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- 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] Commented: (TUSCANY-1073) Not currently possible to generate WSDL - specifically schema - using SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473099 ] Matthew Peters commented on TUSCANY-1073: - I just tried to put together a test case for this issue, with a progrm that loaded the WSDL, SOAP and schema xsds. I find that things have gone backwards, in that SDO will not now even load the schema xsd any longer. If I try to load the xsd schema at http://www.w3.org/2001/XMLSchema.xsd I get an exception from SDO with the text Type has empty name. It is true that there are types with empty names in this xsd but they are enclosed in elements, and this is allowable. (It is the schema for schema, after all) If I google for this text I find it is in Tuscany's DataFactoryImpl.cpp, and if I have read the change history correctly it arrived in a fix to JIRA 763. So, we need the schema for schema to load before we can make progress. Do you want me to raise this as a new JIRA? Not currently possible to generate WSDL - specifically schema - using SDO - Key: TUSCANY-1073 URL: https://issues.apache.org/jira/browse/TUSCANY-1073 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Reporter: Matthew Peters Fix For: Cpp-M3 When I tried to use SDO to generate some wsdl containing a types element with some schema, I found that I could not generate the contents of the schema, specifically those things that are in the schema namespace. I can't remember quite what happened - either the necessary elements were not in the model or not written out, but Ed Slattery explained to me at the time that anything in the schema namespace is ignored. Please could you fix this so that I can generate wsdl with embedded schema? I currently have a bodge where I have to generate all the schema part of my wsdl by hand - lots of string handling - and then stick it into the wsdl at the appropriate point and it is all a bit horrid. Fixing this would help a lot. -- 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] Commented: (TUSCANY-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ https://issues.apache.org/jira/browse/TUSCANY-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473108 ] Kelvin Goodson commented on TUSCANY-713: Hi Yang, I seem to have a problem with the ProcessSchemaLocations.713 file that you supplied. The patch application file complains about line 55, so I began applying the patch manually. I have a couple of requests, one trivial request is that you use the .patch extension for patches, and if you could make them from a lower point in the directory hierarchy it would save me having to remove the java/sdo prefix from all the markup lines inside the patch (since these days I only usually check out at the sdo level for applying patches) . The other point which is specific to this patch is the use of bulk imports via the wildcard import statement. I don't know if we have a policy on this in general, but I think its better practice to import only what's required. However, in this case its more of an issue, since you have now introduced an implicit import of a class from EMF that has a well known synonym in Tuscany, namely XMLHelperImpl. I think it's particularly important to be specific about which classes are imported when there are two classes of the same name. Could you please supply a fixed up patch file and I will get this out of the way, thanks. Kelvin. Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: https://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Attachments: ProcessSchemaLocations.713, SchemaLocationTestCase.java, SchemaLocationTestCase.java, SchemaLocationTestCase.xml, SDOUtil.java Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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: I can help SCA
Hi Yang, thanks for all the patches. I'm slowly working through them, and for attending to the issues arising from them. Regards, Kelvin. On 12/02/07, Yang ZHONG [EMAIL PROTECTED] wrote: I just did SDO 928, 713, 1091, 1088, 1101, 1102, 1093, 1097 and 1099. While waiting for them to be committed (responding committer's reviews/requests if any), I can help SCA. Any hint where to? -- Yang ZHONG
[jira] Commented: (TUSCANY-1111) Interchangeability of Java and WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473111 ] ant elder commented on TUSCANY-: org.apache.tuscany.core.builder.ConnectorImpl.connect // TODO: TUSCANY-, can't use targetChains.get with different IDLs so use simple name matching org.apache.tuscany.core.implementation.java.JavaComponentBuilder.handleCallbackSites // TODO: TUSCANY-, if using componentType side file with wsdl idl then may not get JavaMappedService org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load // TODO: TUSCANY-, add in reqd bits missing from sidefile org.apache.tuscany.core.wire.WireServiceExtension.checkCompatibility // TODO: TUSCANY-, this test fails when wiring java to wsdl org.apache.tuscany.spi.idl.java.JavaIDLUtils.match // TODO: TUSCANY-, comparing different IDLs fail so use simple name matching org.apache.tuscany.spi.model.Operation.equals // TODO: TUSCANY-, currently comparing different IDLs fail Interchangeability of Java and WSDL --- Key: TUSCANY- URL: https://issues.apache.org/jira/browse/TUSCANY- Project: Tuscany Issue Type: Bug Components: Java SCA Model Affects Versions: Java-SCA-integration Reporter: ant elder Fix For: Java-SCA-integration JIRA to track issues related to interchangeability of Java and WSDL -- 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-1112) Incorrect namespaces in generated XML
Incorrect namespaces in generated XML
-
Key: TUSCANY-1112
URL: https://issues.apache.org/jira/browse/TUSCANY-1112
Project: Tuscany
Issue Type: Bug
Components: C++ DAS
Affects Versions: Cpp-current
Environment: WinXP
Reporter: Matthew Peters
Please excuse the fact that I have only a PHP testcase for this. The PHP is
however pretty trivial and it seems a simple thing to make in C. Also, I know
that the PHP layer is doing very little to interfere, so this is genuine
Tuscany behaviour.
Here is the bug report from the PHP bug tracking system:
Description:
I have been quite sceptical about the XML that SDO is producing when it
builds a SOAP request, especially w.r.t. the namespaces. So I tried
loading the XML that SDO is producing into Java XERCES with validation
on. There are several problems with the XML generated, I think.
Using the two xsds that are in the reproduce section below, and the
short PHP script also there, SDO generates:
?xml version=1.0 encoding=UTF-8?
BOGUS xmlns=http://Component; xmlns:tns=http://Component;
xmlns:tns2=http://www.test.com/info;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=add
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/BOGUS
There are three (!) things wrong with this.
1. XERCES will not accept the xsi:type=add. I do not really know why.
I assume this is because there is no type called add, it's only an
element. So I do not think this should be coming out.
2. name should not be in tns2=http://www.test.com/info, neither should
first and last be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below person
should all ne in the no name namespace.
3.You have to change the person.xsd to see the third thing: put
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
Reproduce code:
---
?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?
types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
Expected result:
see above
Actual result:
--
see above
[2007-01-31 12:21 UTC] mfp at php dot net
I just came across what I think is another example of this. Now I
understand better how namespaces work, I suspect it is more common than
we realise.
Here's the example in a nutshell:
Catalog.xsd defines a catalog element in the catalogNS namespace, which
contains items defined in a different namespace in a different file,
Order.xsd:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:cat=catalogNS xmlns:ord=orderNS targetNamespace=catalogNS
include schemaLocation=Order.xsd/
element name=catalog type=cat:CatalogType/
complexType name=CatalogType
sequence
element maxOccurs=unbounded ref=ord:item/
/sequence
/complexType
/schema
Order.xsd defines the item element as being in the OrderNS namespace:
.../...
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:ord=orderNS xmlns:cust=customerNS targetNamespace=orderNS
.../...
element name=item
.../...
but when you build a catalog and write it out, although a namespace
prefix is defined for orderNS, everything is in the default namespace,
catalogNS:
catalog xmlns=catalogNS xmlns:tns=catalogNS
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:tns2=orderNS
item
.../...
--
This message is
[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473121
]
Matthew Peters commented on TUSCANY-1112:
-
Sorry there is a typo in the test case above - in one of the xsds I have put
elementNameDefault and it should be elementFormDefault.
Incorrect namespaces in generated XML
-
Key: TUSCANY-1112
URL: https://issues.apache.org/jira/browse/TUSCANY-1112
Project: Tuscany
Issue Type: Bug
Components: C++ DAS
Affects Versions: Cpp-current
Environment: WinXP
Reporter: Matthew Peters
Please excuse the fact that I have only a PHP testcase for this. The PHP is
however pretty trivial and it seems a simple thing to make in C. Also, I know
that the PHP layer is doing very little to interfere, so this is genuine
Tuscany behaviour.
Here is the bug report from the PHP bug tracking system:
Description:
I have been quite sceptical about the XML that SDO is producing when it
builds a SOAP request, especially w.r.t. the namespaces. So I tried
loading the XML that SDO is producing into Java XERCES with validation
on. There are several problems with the XML generated, I think.
Using the two xsds that are in the reproduce section below, and the
short PHP script also there, SDO generates:
?xml version=1.0 encoding=UTF-8?
BOGUS xmlns=http://Component; xmlns:tns=http://Component;
xmlns:tns2=http://www.test.com/info;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=add
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/BOGUS
There are three (!) things wrong with this.
1. XERCES will not accept the xsi:type=add. I do not really know why.
I assume this is because there is no type called add, it's only an
element. So I do not think this should be coming out.
2. name should not be in tns2=http://www.test.com/info, neither should
first and last be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below person
should all ne in the no name namespace.
3.You have to change the person.xsd to see the third thing: put
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
Reproduce code:
---
?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?
types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
Expected result:
see above
Actual result:
--
see above
[2007-01-31 12:21 UTC] mfp at php dot net
I just came across what I think is another example of this. Now I
understand better how namespaces work, I suspect it is more common than
we realise.
Here's the example in a nutshell:
Catalog.xsd defines a catalog element in the catalogNS namespace, which
contains items defined in a different namespace in a different file,
Order.xsd:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:cat=catalogNS xmlns:ord=orderNS targetNamespace=catalogNS
include schemaLocation=Order.xsd/
element name=catalog type=cat:CatalogType/
complexType name=CatalogType
sequence
element maxOccurs=unbounded ref=ord:item/
/sequence
/complexType
/schema
Order.xsd defines the item element as being in the OrderNS namespace:
.../...
schema
Re: I can help SCA
kelvin goodson wrote: Hi Yang, thanks for all the patches. I'm slowly working through them, and for attending to the issues arising from them. Regards, Kelvin. On 12/02/07, Yang ZHONG [EMAIL PROTECTED] wrote: I just did SDO 928, 713, 1091, 1088, 1101, 1102, 1093, 1097 and 1099. While waiting for them to be committed (responding committer's reviews/requests if any), I can help SCA. Any hint where to? -- Yang ZHONG Yang, Are you interested in helping with WSDL2Java + Java2WSDL? There is some work to do to integrate the SDO generation and make the most efficient use of the Axis2 code generators. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO impl Java 6 dependancy
SDO had not previously had a dependency on either J2EE nor on woodstox. Adding such a dependency may limit the environments in which SDO may be used. Regards, Paul Golick e-mail: [EMAIL PROTECTED] Jeremy Boynes [EMAIL PROTECTED] 2007-02-13 05:30 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO impl Java 6 dependancy It's not a dependency on Java6, it's a dependency on StAX (java.xml.stream). That happens to be included in Java6, but it is also included in Java5 Enterprise Edition and is available separately for use on Java5 Standard Edition and J2SE 1.4. It seems the SDO implementation now has a hard runtime dependency on StAX in much the same way as it does on EMF so you need to make sure a StAX implementation is available at runtime. You can: * run on Java6 * run on Java 5 EE * run on 1.4 and supply your own StAX implementation If you choose to supply your own implementation, you can use the java.xml.stream API classes from Sun or use the open-source version stax-api v1.0 or 1.0.1. Similarly you can use the reference implementation (from Sun/BEA), or use an open-source implementation such as woodstox. -- Jeremy On Feb 13, 2007, at 1:40 PM, Robbie Minshall wrote: By compiling with a jar that has Java 6 dependancy we are ourselves creating a dependancy on Java 6 for the SDO impl jar. This seems to be a problem to me. No ? Robbie On 2/13/07, Yang ZHONG [EMAIL PROTECTED] wrote: sdo/impl/pom.xml declares dependency on stax-api, that's required to compile sdo impl. StAX impl will be required for runtime if StAX support code path is executed. On 2/13/07, Robbie Minshall [EMAIL PROTECTED] wrote: Paul identified a problem in https://issues.apache.org/jira/browse/TUSCANY-1105 which appears to indicate that the sdo impl jar has dependancies upon Java 6 for some code paths. This scneario is not limited to the CTS execution but should probably present itSelf at least when using the org.apache.tuscany.sdo.helper.XMLDocumentImpl.load code path. Paul points out that the issue is that the wstx-asl-3.2.0.jar and stax-api-1.0.1.jar files are built using java 6 since they contain references to javax.xml.stream.XMLStreamException which only exists in Java 6. The pom file indicates that stax is for optional features, and that woodstax is for testing purposes. Do we need these dependancies ? Should we use a different version of these dependancies ? What solutions do people suggest for resolving this issue ? cheers, Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http:// robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 -- Yang ZHONG -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http:// robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1091) DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance
[ https://issues.apache.org/jira/browse/TUSCANY-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473128 ] Kelvin Goodson commented on TUSCANY-1091: - Hi Yang, I'm going to have to push back on a couple of things here, sorry. First is that I'm getting a test failure when I run in maven (not in eclipse) the exception stack is ... Test set: org.apache.tuscany.sdo.test.XMLStreamHelperPerformanceTestCase --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.06 sec FAILURE! testDynamic(org.apache.tuscany.sdo.test.XMLStreamHelperPerformanceTestCase) Time elapsed: 0.03 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUtil.java:476) at org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectImpl.java:1196) at org.apache.tuscany.sdo.test.XMLStreamHelperPerformanceTestCase.testDynamic(XMLStreamHelperPerformanceTestCase.java:64) at org.apache.tuscany.sdo.test.XMLStreamHelperPerformanceTestCase.testDynamic(XMLStreamHelperPerformanceTestCase.java:64) I'm not sure why line 64 appears twice in the stack, could you take a look please? The second thing is again something I'm not sure we have a policy on but I think is could be confusing. You have introduced a class which differs in name from the interface it implements only by case. NameSpaceContext implements NamespaceContext I think this is potentially confusing. Would you be able to change this to perhaps a XXXImpl class please. DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance Key: TUSCANY-1091 URL: https://issues.apache.org/jira/browse/TUSCANY-1091 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: bindLessNS, bindLessNS, simple3.xsd, XMLStreamHelper.xsd, XMLStreamHelperPerformanceTestCase.java p0:quotes3 p1:symbol3 xmlns:p1=http://www.example.com/simple3;IBM/p1:symbol3 p1:company3 xmlns:p1=http://www.example.com/simple3;IBM Corp./p1:company3 /p0:quotes3 can be optimized as p0:quotes3 xmlns:p1=http://www.example.com/simple3; p1:symbol3IBM/p1:symbol3 p1:company3IBM Corp./p1:company3 /p0:quotes3 Thanks to Fuhwei Lwo for prototyping the Test Case. I've made small changes to make use of HelperContext so that it will neither interfere nor be interfereed by other build test(s). -- 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: core-samples module
I think you need to build the itest plugin (under java/sca/runtime/itest) first. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev List tuscany-dev@ws.apache.org Sent: Wednesday, February 14, 2007 7:34 AM Subject: core-samples module Quick question, should core-samples be buildable? I am getting the following error: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.tuscany.sca:tuscany-itest-plugin' does not exist o r no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 14 10:27:18 EST 2007 [INFO] Final Memory: 5M/11M [INFO] I see a tuscany-itest-plugin-1.0-incubator-SNAPSHOT.jar in my local repo, but standalone/calculator/pom.xml does not have a version for it; so, to try something I added version1.0-incubator-SNAPSHOT/version to said pom.xml, and now I get: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-itest-plugin Version: 1.0-incubator-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-itest-plugin:pom:1.0-incubator-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), sateh (http://maven.sateh.com/maven2//), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshot (http://snapshots.repository.codehaus.org) I am probably missing something really simple, but just in case. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO impl Java 6 dependancy
Thanks Jeremy for the clarification about the various options to resolve this dependancy. On 2/14/07, Paul Golick [EMAIL PROTECTED] wrote: SDO had not previously had a dependency on either J2EE nor on woodstox. Adding such a dependency may limit the environments in which SDO may be used. Regards, Paul Golick e-mail: [EMAIL PROTECTED] Jeremy Boynes [EMAIL PROTECTED] 2007-02-13 05:30 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO impl Java 6 dependancy It's not a dependency on Java6, it's a dependency on StAX (java.xml.stream). That happens to be included in Java6, but it is also included in Java5 Enterprise Edition and is available separately for use on Java5 Standard Edition and J2SE 1.4. It seems the SDO implementation now has a hard runtime dependency on StAX in much the same way as it does on EMF so you need to make sure a StAX implementation is available at runtime. You can: * run on Java6 * run on Java 5 EE * run on 1.4 and supply your own StAX implementation If you choose to supply your own implementation, you can use the java.xml.stream API classes from Sun or use the open-source version stax-api v1.0 or 1.0.1. Similarly you can use the reference implementation (from Sun/BEA), or use an open-source implementation such as woodstox. -- Jeremy On Feb 13, 2007, at 1:40 PM, Robbie Minshall wrote: By compiling with a jar that has Java 6 dependancy we are ourselves creating a dependancy on Java 6 for the SDO impl jar. This seems to be a problem to me. No ? Robbie On 2/13/07, Yang ZHONG [EMAIL PROTECTED] wrote: sdo/impl/pom.xml declares dependency on stax-api, that's required to compile sdo impl. StAX impl will be required for runtime if StAX support code path is executed. On 2/13/07, Robbie Minshall [EMAIL PROTECTED] wrote: Paul identified a problem in https://issues.apache.org/jira/browse/TUSCANY-1105 which appears to indicate that the sdo impl jar has dependancies upon Java 6 for some code paths. This scneario is not limited to the CTS execution but should probably present itSelf at least when using the org.apache.tuscany.sdo.helper.XMLDocumentImpl.load code path. Paul points out that the issue is that the wstx-asl-3.2.0.jar and stax-api-1.0.1.jar files are built using java 6 since they contain references to javax.xml.stream.XMLStreamException which only exists in Java 6. The pom file indicates that stax is for optional features, and that woodstax is for testing purposes. Do we need these dependancies ? Should we use a different version of these dependancies ? What solutions do people suggest for resolving this issue ? cheers, Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http:// robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 -- Yang ZHONG -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http:// robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
Re: Runtime bring-up and next steps
Hmm, my questions are simpler than I may have made them sound. From your original post, you say that you want to eliminate outbound and inbound wires and replace/merge them by/into a single wire attached to the source. Before the merge we used to have, from the perspective of a component C, an inbound wire per service it exposed and an outbound wire per reference it used. Each inbound wire had a set of inbound chains (one per opera- tion in the forward direction) and a number of callback outbound chain sets (one set per source component, and each group with one chain per callback operation). Similarly, each outbound wire had a set of outbound chains and a set of inbound chains. If a single wire is going to merge it all, are both sets of inbound chains and all sets of outbound chains going to be preserved? If not, what's the new structure that is going to be in place and how does it preserve the pre-exis- ting behavior? Like I said, this may be common knowledge and I may just have missed the explanation, in which case would someone point me to it? On 2/12/07, Jim Marino [EMAIL PROTECTED] wrote: I see two cases, managed and non-managed code. In the former, where the source is a component, there would be one set of chains (no distinction between inbound and outbound) attached to the source component. For non-managed code, it would be pretty much the same thing with the chains held in the proxy or CallableReference. Apologies if this has been explained previously and is now common knowledge (if so, could you point me at the explanation?). We've always had concepts of managed vs. non-managed code. The problem is the specs never made the distinction very well and confused the two in places. One of the main goals of the recent spec changes was to clarify this (hence the reintroduction of things like ComponentContext). The code is now in the 1.0 spec module but Jeremy also posted to the wiki on this. I'm not sure, though, if you are referring to this. So is the idea that each chain has interceptors (say, databinding and security) that are used for both incoming and outgoing messages? Is there going to be a way to indicate to an interceptor which way is in effect? I'm not following and probably missing something. I don't think this is any different than what we have today. There would be forward and callback chains associated with a Wire. If the interceptor needs to know if the invocation is a forward or callback invocation, it would be the job of the interceptor builder on the slave to provide it with that information (or have the builder instantiate different interceptors). There is a mail thread on interceptor builders from last week which covers the format for serializing a portable wire definition from master to slave. The idea is the definition would be created on the master and sent to the slave where interceptor builders would be responsible for creating interceptors according to some extensible wire definition information. And would there be a way to indicate the order in each direction? Maybe making the chain a doubly-linked list? Could you explain a little further? I think the chain is exactly how we have it today except it is one as opposed to two chains for each direction. A --\ |-C B --/ I'm proposing we do the following: A --- C B --- In the approach connections would be: 1. Between components 2. From a transport to a component 3. From a component to a transport 4. From a transport to a transport When you say transport, do you mean a composite reference and/or service implementation for a given binding? I think of transport as what a binding provides a link to (not a composite reference or service since they may have multiple bindings). Even with a single hop, a callback invocation handler at C would still need to be able to choose between A and B depending on where the forward call came from. How do you see it referring to the correspon- ding wire when it needs to make the callback? It would be retrieved from the context, basically how it is today. We need to be careful here, though, about dealing with context cleanup on threads. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: core-samples module
I deployed a SNAPSHOT of the plugin so you should no longer need to build that. The plugin depends on kernel from trunk and I have not deployed that so you will need a current local build. -- Jeremy On Feb 14, 2007, at 7:57 AM, Raymond Feng wrote: I think you need to build the itest plugin (under java/sca/runtime/ itest) first. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev List tuscany-dev@ws.apache.org Sent: Wednesday, February 14, 2007 7:34 AM Subject: core-samples module Quick question, should core-samples be buildable? I am getting the following error: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] The plugin 'org.apache.tuscany.sca:tuscany-itest-plugin' does not exist o r no valid version could be found [INFO] - --- [INFO] For more information, run Maven with the -e switch [INFO] - --- [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 14 10:27:18 EST 2007 [INFO] Final Memory: 5M/11M [INFO] - --- I see a tuscany-itest-plugin-1.0-incubator-SNAPSHOT.jar in my local repo, but standalone/calculator/pom.xml does not have a version for it; so, to try something I added version1.0-incubator-SNAPSHOT/version to said pom.xml, and now I get: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-itest-plugin Version: 1.0-incubator-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-itest-plugin:pom:1.0-incubator- SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), sateh (http://maven.sateh.com/maven2//), apache.incubator (http://people.apache.org/repo/m2-incubating- repository), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository), codehaus-snapshot (http://snapshots.repository.codehaus.org) I am probably missing something really simple, but just in case. Thanks - 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: core-samples module
So, how should I get the SNAPSHOT of the plugin? Trying to build the sample can't seem to find it and adding a version to the pom does not help, as I mentioned earlier. I have been able to build the kernel with no problem. On 2/14/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I deployed a SNAPSHOT of the plugin so you should no longer need to build that. The plugin depends on kernel from trunk and I have not deployed that so you will need a current local build. -- Jeremy On Feb 14, 2007, at 7:57 AM, Raymond Feng wrote: I think you need to build the itest plugin (under java/sca/runtime/ itest) first. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev List tuscany-dev@ws.apache.org Sent: Wednesday, February 14, 2007 7:34 AM Subject: core-samples module Quick question, should core-samples be buildable? I am getting the following error: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] The plugin 'org.apache.tuscany.sca:tuscany-itest-plugin' does not exist o r no valid version could be found [INFO] - --- [INFO] For more information, run Maven with the -e switch [INFO] - --- [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 14 10:27:18 EST 2007 [INFO] Final Memory: 5M/11M [INFO] - --- I see a tuscany-itest-plugin-1.0-incubator-SNAPSHOT.jar in my local repo, but standalone/calculator/pom.xml does not have a version for it; so, to try something I added version1.0-incubator-SNAPSHOT/version to said pom.xml, and now I get: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-itest-plugin Version: 1.0-incubator-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-itest-plugin:pom:1.0-incubator- SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), sateh (http://maven.sateh.com/maven2//), apache.incubator (http://people.apache.org/repo/m2-incubating- repository), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository), codehaus-snapshot (http://snapshots.repository.codehaus.org) I am probably missing something really simple, but just in case. Thanks - 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: I can help SCA
I'll browse JIRA for WSDL2Java and Java2WSDL. Let me know if particular one(s) has higher priority or some work not yet in JIRA. On 2/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: Hi Yang, thanks for all the patches. I'm slowly working through them, and for attending to the issues arising from them. Regards, Kelvin. On 12/02/07, Yang ZHONG [EMAIL PROTECTED] wrote: I just did SDO 928, 713, 1091, 1088, 1101, 1102, 1093, 1097 and 1099. While waiting for them to be committed (responding committer's reviews/requests if any), I can help SCA. Any hint where to? -- Yang ZHONG Yang, Are you interested in helping with WSDL2Java + Java2WSDL? There is some work to do to integrate the SDO generation and make the most efficient use of the Axis2 code generators. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
[jira] Updated: (TUSCANY-1105) CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream
[ https://issues.apache.org/jira/browse/TUSCANY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1105: - Attachment: pom.xml.1105 The attached file contains a patch to cts\sdo2.1-tuscany\pom.xml to add a dependency on the stax api (the same version used by SDO). The patch is intended to be applied from the Tuscany\java directory. CTS throws NoClassDefFound errors for javax.xml.stream.XMLStreamException while reading XML stream -- Key: TUSCANY-1105 URL: https://issues.apache.org/jira/browse/TUSCANY-1105 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Affects Versions: Java-SDO-Mx Environment: Java 5 Reporter: Paul Golick Fix For: Java-SDO-Mx Attachments: pom.xml.1105 while adding a test that runs in the SDO impl test directory to the CTS, the surefire-reports for SniffTest includes the following: error type=java.lang.NoClassDefFoundError message=javax.xml.stream.XMLStreamExceptionjava.lang.NoClassDefFoundError: javax.xml.stream.XMLStreamException at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.makeDefaultHandler(SDOXMLResourceImpl.java:299) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.createDefaultHandler(XMLLoadImpl.java:305) at org.eclipse.emf.ecore.xmi.impl.XMLParserPoolImpl.getDefaultHandler(XMLParserPoolImpl.java:186) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:230) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:238) ... -- 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: core-samples module
Yeah, not sure I needed to do that (hoping not to). But when I
try mvn clean I get:
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] A required plugin was not found: Plugin could not be found - check
that t
he goal name is correct: Unable to download the artifact from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.tuscany.sca-DartifactId=tusca
ny-itest-plugin \
-Dversion=1.0-incubator-SNAPSHOT -Dpackaging=maven-plugin
-Dfile=/path/t
o/file
org.apache.tuscany.sca:tuscany-itest-plugin:maven-plugin:1.0-incubator-SNAPSHO
T
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.incubator (http://people.apache.org/repo/m2-incubating-repository),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
codehaus-snapshot (http://snapshots.repository.codehaus.org)
org.apache.tuscany.sca:tuscany-itest-plugin:maven-plugin:1.0-incubator-SNAPSHO
T
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.incubator (http://people.apache.org/repo/m2-incubating-repository),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
codehaus-snapshot (http://snapshots.repository.codehaus.org)
which seems to also depend on the plugin. So then I try
to build the plugin in isolation, in runtime/itest/plugin, and I get
a slew of compilation errors, starting with:
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\MavenMonitorFactory.java:[36,7]
cannot ac
cess org.apache.tuscany.host.MonitorFactory
file org\apache\tuscany\host\MonitorFactory.class not found
public class MavenMonitorFactory extends ProxyMonitorFactory {
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[30,32] package org.osoa.sca.annotations does not exist
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[32,41] package org.apache.tuscany.spi.annotation does not exist
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[33,40] package org.apache.tuscany.spi.component does not exist
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[34,39] package org.apache.tuscany.spi.deployer does not exist
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[35,40] package org.apache.tuscany.spi.extension does not exist
C:\Devt\eclipse-311\eclipse\workspace\trunk\sca\runtime\itest\plugin\src\main\ja
va\org\apache\tuscany\sca\plugin\itest\implementation\junit\JUnitComponentTypeLo
ader.java:[36,50] package org.apache.tuscany.spi.implementation.java does
not ex
ist
...
Any ideas?
On 2/14/07, Raymond Feng [EMAIL PROTECTED] wrote:
I think you need to build the itest plugin (under java/sca/runtime/itest)
first.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: Tuscany Dev List tuscany-dev@ws.apache.org
Sent: Wednesday, February 14, 2007 7:34 AM
Subject: core-samples module
Quick question, should core-samples be buildable?
I am getting the following error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.tuscany.sca:tuscany-itest-plugin' does not
exist o
r no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Feb 14 10:27:18 EST 2007
[INFO] Final Memory: 5M/11M
[INFO]
I see a tuscany-itest-plugin-1.0-incubator-SNAPSHOT.jar in my local
repo,
but standalone/calculator/pom.xml does not have a version for it; so, to
try
something I added version1.0-incubator-SNAPSHOT/version to said
Re: Runtime bring-up and next steps
On Feb 14, 2007, at 7:59 AM, Ignacio Silva-Lepe wrote:
Hmm, my questions are simpler than I may have made them sound. From
your original post, you say that you want to eliminate outbound and
inbound wires and replace/merge them by/into a single wire attached
to the
source.
Before the merge we used to have, from the perspective of a
component C,
an inbound wire per service it exposed and an outbound wire per
reference
it used. Each inbound wire had a set of inbound chains (one per opera-
tion in the forward direction) and a number of callback outbound
chain sets
(one set per source component, and each group with one chain per
callback
operation). Similarly, each outbound wire had a set of outbound
chains and
a set of inbound chains.
If a single wire is going to merge it all, are both sets of inbound
chains
and
all sets of outbound chains going to be preserved? If not, what's
the new
structure that is going to be in place and how does it preserve the
pre-exis-
ting behavior?
Like I said, this may be common knowledge and I may just have
missed the
explanation, in which case would someone point me to it?
Sorry, maybe I didn't explain clearly enough in previous posts. Both
sets of chains will be preserved. Source components will contain the
wires to a target and targets will no longer have incoming wires. The
Allocator on the master will build up a WireDefinition which will be
marshalled to a slave. The WireDefinition will contain a set of
InterceptorDefinitions which InterceptorBuilders will use to
constitute a Wire. The WireDefinition will also contain source and
target URIs. Hence, the Wire will contain both forward and callback
invocation chains. This will mean the Connector can change to the
following:
public interface Connector {
void connect(WireDefinition wd) throws WiringException;
}
As the Connector has a reference to a ComponentManager, it will be be
able to look up source and target, dispatch to InterceptorBuilders
based on a QName, build forward and callback chains for the wire, and
attach the wire to the source. Meeraj has already checked in
WireDefinition as well as posted on the marshalling format, so it may
be worth checking that out.
Jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Developing an SCA Application: Best Practices
Very nice summary! Some comments inline. Andrew Borley wrote: Hi All, After writing the Alert Aggregator sample for the Tuscany Native runtime I thought it would be worthwhile documenting my experiences. I've titled this Best Practices but perhaps Hints Tips or Andy's Observations would be more appropriate! Anyway, below is a suggested list of things to do/think about when writing your own SCA based applications. A few of the points below are from general software development, but they apply equally to SCA development. Start by drawing your SCA diagram (e.g. [1]) - this helps with the componentization of your app. SCA diagrams aren't code path diagrams (such as a BPEL visualization): they simply show what blocks of function you have and which blocks are used by other blocks. Separating components into composites also helps you think about componentization and deployment, as (currently) the smallest deployable block is a composite. Similarly, an SCA diagram is not a class diagram - the smallest SCA unit is the component which could consist of multiple classes or scripts or similar. You may have a requirement for a Utilities class providing some basic function that is used by lots of other classes - SCA wires involve a certain amount of overhead, so it may not be worth creating a Utilities component that all other components reference. Instead, it can be valid to have multiple instances of the same class embedded as part of multiple components. Think about the services and references that your components and composites provide/require, so you can draw the wiring on the diagram and work out which components and composites you need, but don't worry too much about bindings (REST, WS, etc) - SCA/Tuscany makes it so easy to switch bindings that this can be decided at a later time. I didn't worry too much about interfaces at this point - I planned to do most of my components in scripting languages (which don't need defined interfaces in Tuscany Native). In other languages (Java, C++) it may be worth defining the public interfaces that your component implements, so you can see how and where functions are implemented within your composites. When coding the component implementations, it's easiest to start with the 'least-dependent' components - those that don't need lots of other infrastructure or other components or composites in place. For the Alert Aggregator sample (see [1]), my order of component development was as follows: RSSChecker AlertConfig AlertChecker HTMLFormatter POPChecker Of course, as in normal software development, this was an iterative process where each component got revisited as necessary. Component implementations were developed in a standard test-driven manner, but deploying within an SCA runtime adds extra layers of required testing (think unit vs. system tests). I began by testing my component implementations in a standalone, unit-testing-style fashion, then tested under Tuscany via local clients, then via remote clients using whichever service bindings I had chosen and finally via full system tests (in the Alert Aggregator case, through clicking on a web page). The power of SCA meant that I could use the same client code for both local and remote testing , just by adding in a local SCA reference that called the remote service (see the PythonCalculator sample for an example of this - the sample.calculator.client/client.py code is almost exactly the same as the sample.calculator.wsclient/client.py code). I found I needed to programme somewhat defensively - Tuscany SCA Native (or at least the extensions I used) is not yet particularly good at handling exceptions or errors that get thrown, but not caught, in component code. Instead, I tried to check for bad data and catch exception cases within the component implementation. The handling of errors is something that definately needs more work in Tuscany SCA Native - should errors get propagated back to the original client, or should they be caught and logged? A problem that exacerbates this issue is that some of our logging messages don't provide much (or any!) useful information! I think it is critical for us to improve that, as this is a very important part of the user/developer experience. Do you think you could report the issues you found in JIRAs that some of us could help with? The XML story with Tuscany SCA Native is pretty good - I found using SDO/XML/Python ElementTree objects easy and very useful. I would probably go as far as suggesting that developers use XML complex types and SDO rather than trying to flow multiple method parameters, as this can mean less changes required in code and interfaces throughout the development cycle. Good point. I also prefer that approach. I always find mapping between XML documents and multiple service method parameters confusing. I prefer a model where I flow an XML document on the wire, my component works with a single parameter containing that XML document, the document can
[jira] Created: (TUSCANY-1113) Extensible namespaces and types that change
Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Landbo Frederiksen updated TUSCANY-1113: -- Attachment: TestTypeChangesAndExtensibleNamespaces.java This program demonstrates the issues Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Attachments: TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Landbo Frederiksen updated TUSCANY-1113: -- Attachment: XSDHelperImpl.java Just inserted 'true' to force namespace to be extended. All changes marked by NON-TUSCANY comment Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Attachments: TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ https://issues.apache.org/jira/browse/TUSCANY-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-713: --- Attachment: SDOXMLResourceImpl.patch 1. The patch application file complains about line 55 http://incubator.apache.org/tuscany/patches.html recommends svn to generate patchs. I run it on Windows. If the problem stays, do you want to create a SubVersion issue? 2. .patch, lower hierarchy and specific import I don't have a preference, yours works for me. See the attached new patch. Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: https://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Attachments: ProcessSchemaLocations.713, SchemaLocationTestCase.java, SchemaLocationTestCase.java, SchemaLocationTestCase.xml, SDOUtil.java, SDOXMLResourceImpl.patch Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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]
Question on DeploymentException UnsuportedTypeExceptions
Hi Jeremy Why exceptions like DeploymentException and UnsupportedTypeExceptions are defined in the host-api ? if they are specific to host environments, doesn't host environments have dependencies in kernel/core ? -- Luciano Resende http://people.apache.org/~lresende
[jira] Updated: (TUSCANY-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Landbo Frederiksen updated TUSCANY-1113: -- Attachment: SDOXSDEcoreBuilder.java Here is the rather ugly version with the methods copied down from XSDECoreBuilder... Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Attachments: SDOXSDEcoreBuilder.java, TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-1091) DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance
[ https://issues.apache.org/jira/browse/TUSCANY-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-1091: Attachment: bindLessNS.patch 1. XMLStreamHelperPerformanceTestCase failure All build tests pass for me. I mvn clean before test, do you want to give a try please? If the problem stays, I svn all source from scratch, do you want to give a try please? 2. introduced NameSpaceContext NameSpaceContext isn't new. It was renamed from DelegatingNameSpaceContext (Frank http://issues.apache.org/jira/browse/TUSCANY-1091#action_12471365) by striping Delegating (planned http://issues.apache.org/jira/browse/TUSCANY-1091#action_12471389). Now it has been renamed to NamespaceContextImpl in the attached new patch. DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance Key: TUSCANY-1091 URL: https://issues.apache.org/jira/browse/TUSCANY-1091 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: bindLessNS, bindLessNS, bindLessNS.patch, simple3.xsd, XMLStreamHelper.xsd, XMLStreamHelperPerformanceTestCase.java p0:quotes3 p1:symbol3 xmlns:p1=http://www.example.com/simple3;IBM/p1:symbol3 p1:company3 xmlns:p1=http://www.example.com/simple3;IBM Corp./p1:company3 /p0:quotes3 can be optimized as p0:quotes3 xmlns:p1=http://www.example.com/simple3; p1:symbol3IBM/p1:symbol3 p1:company3IBM Corp./p1:company3 /p0:quotes3 Thanks to Fuhwei Lwo for prototyping the Test Case. I've made small changes to make use of HelperContext so that it will neither interfere nor be interfereed by other build test(s). -- 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] Commented: (TUSCANY-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473177 ] Christian Landbo Frederiksen commented on TUSCANY-1113: --- Reading a response from Frank Budinsky, I realized that the issues are probably solved with the 2 fixes. Adding or replacing individual properties in a single type is not necessary when you can redefine an entire type. SO changing TestTypeChangesAndExtensibleNamespaces.generate to just: XSDHelper.INSTANCE.define(new String(xsdFile.getBytes(UTF-8))); DataObject documentDataObject = DataFactory.INSTANCE.create(namespace, rootElement+Type); handleRootDataObject(documentDataObject); Actually makes the program work! Frank's answer: Looking at your test program, I can see that what you're trying to do is more than I thought, so it's going to be harder. Let me explain. In the FIRST part, you define a Type named TestElementXType. Then in SECOND, you add a second Type: TestElementYType, which should work with the true added to XSDHelper.define(), which allows it to proceed. In the THIRD part, you redefine Type TestElementXType, which should work with the addToSortedList() change. That's my theory, anyway :-) What isn't working, since we haven't done anything to support it, is incremental addition/modification of the properties in a Type. Right now, all we have is the ability to add new types or completely replace a type with a new version (like you're doing for TestElementXType in part THREE). You can't add to or replace individual properties in a single type, which is what you're also trying to do with the global elements/properties in the DocumentRoot Type. To test this theory, you could change the global element in the first schema to something like this: element name=RootElement type=xsd:AnyType/ and then delete the global elements in the second and third schemas. This way, you would define the DocumentRoot Type in the first call to XSDHelper.define() and it would contain the property RootElement. On the second and third calls to TypeHelper.define(), since you have no new global elements, it won't change/replace the DocumentRoot, which is causing the problem. I think you should try to get this much working first, then we can think about how to specially handle the DocumentRoot. Note that if we just change things to allow you to also add new properties or change properties in a Type, then it wouldn't be doing the right thing to TestElementXType in the THIRD part - you would have ended up with a TestElementXType that has 4 properties (2 double and 2 integer) instead of a redefinition. Frank. Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Attachments: SDOXSDEcoreBuilder.java, TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-1114) Unable to download resource from repository on build
Unable to download resource from repository on build Key: TUSCANY-1114 URL: https://issues.apache.org/jira/browse/TUSCANY-1114 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Environment: WinXP Reporter: Justin Stewart Just downloaded and installed SCA Java M2 release - binary and samples. When building the calculator sample using Maven, I get: $ mvn [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). ... Sure enough, http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom doesn't exist. Thanks, Justin -- 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] Commented: (TUSCANY-1114) Unable to download resource from repository on build
[ https://issues.apache.org/jira/browse/TUSCANY-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473212 ] Raymond Feng commented on TUSCANY-1114: --- The artifact should be resolved with the apache maven repo at: http://people.apache.org/repo/m2-incubating-repository/ And this repo is configured with the pom.xml and it should work. Maybe you can try to add this repo to user.home/.m2/settings.xml. Unable to download resource from repository on build Key: TUSCANY-1114 URL: https://issues.apache.org/jira/browse/TUSCANY-1114 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Environment: WinXP Reporter: Justin Stewart Just downloaded and installed SCA Java M2 release - binary and samples. When building the calculator sample using Maven, I get: $ mvn [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). ... Sure enough, http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom doesn't exist. Thanks, Justin -- 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] Commented: (TUSCANY-1114) Unable to download resource from repository on build
[ https://issues.apache.org/jira/browse/TUSCANY-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473217 ] Jeremy Boynes commented on TUSCANY-1114: This POM is also included in the samples distribution so mvn -N from the root of that distribution will install it locally for you. Unable to download resource from repository on build Key: TUSCANY-1114 URL: https://issues.apache.org/jira/browse/TUSCANY-1114 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Environment: WinXP Reporter: Justin Stewart Just downloaded and installed SCA Java M2 release - binary and samples. When building the calculator sample using Maven, I get: $ mvn [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). ... Sure enough, http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom doesn't exist. Thanks, Justin -- 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]
spec intent proposal, was: svn commit: r507683 ...
On Feb 14, 2007, at 12:32 PM, [EMAIL PROTECTED] wrote: Author: jboynes Date: Wed Feb 14 12:32:41 2007 New Revision: 507683 URL: http://svn.apache.org/viewvc?view=revrev=507683 Log: strawman for @Intent annotation and usage This flurry of commits was caused by me working with Mike Rowley to verify that the proposed annotations for intent declarations actually compile - real time specification in action :) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.5 Released
Hi, Maybe we can try to build Tuscany w/ maven 2.0.5 now. Thanks, Raymond - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; announce@maven.apache.org; Maven Developers List dev@maven.apache.org Sent: Wednesday, February 14, 2007 1:53 PM Subject: Maven 2.0.5 Released The Maven team would like to announce the release of Maven 2.0.5. You can find the roadmap for the release here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=12294sorter/field=issuekeysorter/ order=DESC The release notes can be found here: http://maven.apache.org/release-notes.html And you can download it from here: http://maven.apache.org/download.html Thanks, The Maven Apache Team! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1113) Extensible namespaces and types that change
[
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Landbo Frederiksen updated TUSCANY-1113:
--
Attachment: SDOXSDEcoreBuilder.java
Sorry I don't know that Patch thing :(
This version contains the latest changes where the createFeature has been
pulled down from XSDECoreBuilder.
Since I (at the moment) did not want to change code in EMF I had to pull down
the entire createFeature method (since it was already overridden) from
XSDECoreBuilder and changed at the spot you pointed out:
// NON-TUSCANY
int existingIndex =
eClass.getEAllStructuralFeatures().indexOf(eClass.getEStructuralFeature(name));
if (existingIndex -1) {
eClass.getEStructuralFeatures().set(existingIndex, eReference);
} else {
eClass.getEStructuralFeatures().add(eReference);
}
Now the test class succeds even using DocumentRoot!!!
I have no idea if all scenarios are handled...
Extensible namespaces and types that change
---
Key: TUSCANY-1113
URL: https://issues.apache.org/jira/browse/TUSCANY-1113
Project: Tuscany
Issue Type: Improvement
Components: Java SDO Implementation
Environment: Eclipse, EMF 2.2.1
Reporter: Christian Landbo Frederiksen
Attachments: SDOXSDEcoreBuilder.java, SDOXSDEcoreBuilder.java,
TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java
Once an xml-schema with a namespace is defined (XSDHelper) you cannot define
other schemas with the same namespace.
I would like namespaces to be extensible.
Once the types of a schema is defined you cannot change them by defining an
altered version of the schema.
I realize the dangers of modifying already defined types but I believe i
ought to be an option.
Summary from:
http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html
An xml schema is uploaded and SDO is used to generate a form for
submitting data as xml-instances of the schema.
New schemas in the same namespace may be added often resulting in new
forms (this is the first issue where I need to extend existing
namespaces).
Xml instances may later be edited again.
This is the most common use case and SDO seems to support this very
well.
BUT xml schemas may be modified, even individual types.
This of course flagged some warning signs and schema versions were
considered.
But 'use at own risk' was chosen because of its simplicity. To support
this strategy a status/mode will be introduced so xml-instances cannot
be edited while schema is in 'administration'-mode. This ought to handle
the case with instances at schema-modification time.
With regards to serialized xml instances any data that is rendered
invalid with type changes will be reset/deleted as of design.
--
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]
Getting plugin doco on the website
I started on some documentation for the itest plugin and am wondering how to integrate this with the stuff on the wiki. I'm using the reporting in the maven-plugin-plugin to generate the doco as it pulls all the goal information out of the Mojo so apart from usage/examples the content is self generating. It creates a mini- site with a bunch of HTML pages and I'd like to get that linked into the main site. Any ideas on how to do that with the wiki? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
[ https://issues.apache.org/jira/browse/TUSCANY-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473238 ] Yang ZHONG commented on TUSCANY-1099: - XSDConstants.lookupQualifier is a nice substitution for Node#lookupPrefix before which is available. Thanks to Frank. However, the attached lookupPrefix serves its special purpose; it can't be simply replaced by Node#lookupPrefix even if moved to DOM level 3 (Java 5). The attached lookupPrefix returns prefix even if which is rebound to different NameSpace already. Node#lookupPrefix doesn't return rebound prefix, neither should XSDConstants.lookupQualifier. It's interesting that current XSDConstants.lookupQualifier does return rebound prefix which is a bug tracked by: http://issues.apache.org/jira/browse/TUSCANY-1115 If interested, here's an example of rebinding prefix: schema xmlns=http://www.w3.org/2001/XMLSchema; xmlns:p=boundNS complexType xmlns:p=differentNS which is also available at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=174236 fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users --- Key: TUSCANY-1099 URL: https://issues.apache.org/jira/browse/TUSCANY-1099 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-Mx Attachments: SDOXSDEcoreBuilder.1099 mvn build ends with message: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS DEcoreBuilder.java:[71,50] cannot resolve symbol symbol : method lookupPrefix (java.lang.String) location: interface org.w3c.dom.Element -- 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: I can help SCA
Yang ZHONG wrote: I'll browse JIRA for WSDL2Java and Java2WSDL. Let me know if particular one(s) has higher priority or some work not yet in JIRA. On 2/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: Hi Yang, thanks for all the patches. I'm slowly working through them, and for attending to the issues arising from them. Regards, Kelvin. On 12/02/07, Yang ZHONG [EMAIL PROTECTED] wrote: I just did SDO 928, 713, 1091, 1088, 1101, 1102, 1093, 1097 and 1099. While waiting for them to be committed (responding committer's reviews/requests if any), I can help SCA. Any hint where to? -- Yang ZHONG Yang, Are you interested in helping with WSDL2Java + Java2WSDL? There is some work to do to integrate the SDO generation and make the most efficient use of the Axis2 code generators. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it would be great to have integration test cases, for example generate Java from WSDL, generate WSDL from Java, verify that the generated Java/WSDL compiles/validates and can be consumed by the Tuscany runtime (use them to type services and references on a POJO component maybe). Once you have a good test scenario you can start adding variations like inline XSDs, XSDs in separate files, simple + complex types, nested complex types, one or more namespaces, WSDL faults etc, maybe start with the test WSDLs from Axis2. Having a basic scenario in place first would be great! and putting it together will probably bump into a number of issues and generate a bunch of JIRAs to work on :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473251 ] Yang ZHONG commented on TUSCANY-1113: - Mail archive: http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00644.html Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Attachments: SDOXSDEcoreBuilder.java, SDOXSDEcoreBuilder.java, TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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]
[SCA Java] Integration Test Case of WSDL2Java and Java2WSDL
Will do. I'll browse the code base for existing or similar Test Case(s) related to WSDL2Java or Java2WSDL. If any one has any related info in mind to share, thanks in advance. On 2/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Yang ZHONG wrote: I'll browse JIRA for WSDL2Java and Java2WSDL. Let me know if particular one(s) has higher priority or some work not yet in JIRA. On 2/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: Hi Yang, thanks for all the patches. I'm slowly working through them, and for attending to the issues arising from them. Regards, Kelvin. On 12/02/07, Yang ZHONG [EMAIL PROTECTED] wrote: I just did SDO 928, 713, 1091, 1088, 1101, 1102, 1093, 1097 and 1099. While waiting for them to be committed (responding committer's reviews/requests if any), I can help SCA. Any hint where to? -- Yang ZHONG Yang, Are you interested in helping with WSDL2Java + Java2WSDL? There is some work to do to integrate the SDO generation and make the most efficient use of the Axis2 code generators. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it would be great to have integration test cases, for example generate Java from WSDL, generate WSDL from Java, verify that the generated Java/WSDL compiles/validates and can be consumed by the Tuscany runtime (use them to type services and references on a POJO component maybe). Once you have a good test scenario you can start adding variations like inline XSDs, XSDs in separate files, simple + complex types, nested complex types, one or more namespaces, WSDL faults etc, maybe start with the test WSDLs from Axis2. Having a basic scenario in place first would be great! and putting it together will probably bump into a number of issues and generate a bunch of JIRAs to work on :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
[jira] Commented: (TUSCANY-1044) DataHelperImpl.toDateTime() is not compliant with spec.
[
https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473271
]
Hasan Muhammad commented on TUSCANY-1044:
-
Hi Kelvin,
Did you get a chance to review this patch ?
Cheers, Hasan
DataHelperImpl.toDateTime() is not compliant with spec.
---
Key: TUSCANY-1044
URL: https://issues.apache.org/jira/browse/TUSCANY-1044
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Ron Gavlin
Fix For: Java-SDO-Mx
Attachments: DateTime.patch, DateTimeTest.zip
Ron,
I think you are correct. The spec says ...
The String representation of DateTime, Duration, Time, Day, Month, MonthDay,
Year, YearMonth, and YearMonthDay follows the lexical representation defined
in XML Schema for the corresponding data types: dateTime, duration, time,
gDay, gMonth, gMonthDay, gYear, gYearMonth, and Date respectively.
and the XML schema definition at
http://www.w3.org/TR/xmlschema-2/#dateTime-timezones seems to be overriden
by the errata at http://www.w3.org/2001/05/xmlschema-errata#e2-45 which
gives ...
The lexical representation of a timezone is a string of the form: (('+' |
'-') hh ':' mm) | 'Z', where *hh* is a two-digit numeral (with leading zeros
as required) that represents the hours, *mm* is a two-digit numeral that
represents the minutes, '+' indicates a nonnegative duration, and '-'
indicates a nonpositive duration. The mapping so defined is one-to-one,
except that '+00:00', '00:00', and 'Z' all represent the same zero-length
duration timezone, UTC; 'Z' is its canonical representation.
so please raise a JIRA, and of course I have to say it ... a fix would be
great too ;-)
Cheers, Kelvin.
On 09/01/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
Based on my reading of the spec, DataHelperImpl.toDateTime(Calendar)
should return a String compatible with the XML Schema dateTime. Consider the
code snippet below:
import commonj.sdo.helper.DataHelper;
System.out.println(DataHelper.INSTANCE.toDateTime(
DataHelper.INSTANCE.toCalendar(2007-01-01T00:00:00.200Z))
This snippet prints the result:
(java.lang.String) 2007-01-01T00:00:00.200 GMT
instead of
(java.lang.String) 2007-01-01T00:00:00.200Z
The GMT suffix seems incorrect to me. The following code supports this
assertion by throwing an IllegalArgumentException when it encounters the
GMT suffix generated by the DataHelper.toDateTime() method.
import javax.xml.datatype.DatatypeFactory;
DatatypeFactory.newInstance().newXMLGregorianCalendar(2007-01-01T00:00:
00.200 GMT);
Do you agree this is a bug? If so, I'll be glad to open a JIRA.
- Ron
--
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: What to do with the WSDL tools
With Yang offering to start contributing to these, perhaps now would be a good time to have one home for them? -- Jeremy On Feb 7, 2007, at 6:46 AM, kelvin goodson wrote: So my understanding of this thread is that the proposal now is that these tools tool will form (part of?) a new, separately releasable, module at a peer level to SDO and with a dependency on SDO. I've just proposed a release of SDO and my best guess is that we would be looking at approx 6 weeks time before we are ready to cut a release. What phase in the lifecycle are these tools in; do they have significant pending features to be developed/ bugs to fix? I haven't played with them. Can anyone point me to any existing documentation re usage/design/plans? Kelvin. On 07/02/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, With respect to the Java2WSDL tool I wish to trim quite of bit of it as most of what we need has now been incorporated into the Axis2 tool over which ours has just been a wrapper providing only the missing things. So AFAICT, the only thing that our Java2WSDL wrapper could add over the current version of Axis2 Java2WSDL is the support for SDOs. I hope to get to this as soon as I am done with somethings that I currently tied up with. - Venkat On 2/7/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Sebastien mentioned stabilizing tools like WSDL2Java and Java2WSDL etc. recently and Kelvin and I were previously discussing moving those tools out of SCA and into SDO on the basis that they actually don't have any dependency on SCA but do on SDO and EMF. Ant has now moved them to the axis2 extension, which makes sense given the dependency on axis2-codegen, but they don't have a dependency on the other modules in there. If there is interest in stabilizing these, then let's move them out to a separate module and release them when they are done. I assume that will require a release of SDO first. -- 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: What to do with the WSDL tools
On Feb 14, 2007, at 5:10 PM, Jeremy Boynes wrote: With Yang offering to start contributing to these, perhaps now would be a good time to have one home for them? +1 Jump-starting tools as an independently releasable module or modules would be good. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn problem?
Hi, I cleaned up my tuscany java files of my computer, then I download the java files from the repository again. OK, till there everything worked fine. But when I try to execute mvn only it appears: [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Feb 15 03:07:23 VET 2007 [INFO] Final Memory: 1M/4M [INFO] C:\Adriano\Faculdade\Tuscanycd tuscany C:\Adriano\Faculdade\Tuscany\tuscanymvn [INFO] Scanning for projects... [INFO] - --- [INFO] Building Tuscany Project [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing C:\Adriano\Faculdade\Tuscany\tuscany\pom.xml to C:\Documents a nd Settings\ADR\.m2\repository\org\apache\tuscany\tuscany-project\1.0-incubator- SNAPSHOT\tuscany-project-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Feb 15 03:07:45 VET 2007 [INFO] Final Memory: 3M/7M [INFO] I suppose it would download many dependencies before BUILD SUCCESSFUL, but no dependency was download :s Am I missing something or it should work this way? Thanks, Adriano Crestani
Re: mvn problem?
I saw similar errors once after I accidentally downloaded files including POMs into overlapped folder hierarchy. Downloading from scratch solved my problem. On 2/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I cleaned up my tuscany java files of my computer, then I download the java files from the repository again. OK, till there everything worked fine. But when I try to execute mvn only it appears: [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Feb 15 03:07:23 VET 2007 [INFO] Final Memory: 1M/4M [INFO] C:\Adriano\Faculdade\Tuscanycd tuscany C:\Adriano\Faculdade\Tuscany\tuscanymvn [INFO] Scanning for projects... [INFO] - --- [INFO] Building Tuscany Project [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing C:\Adriano\Faculdade\Tuscany\tuscany\pom.xml to C:\Documents a nd Settings\ADR\.m2\repository\org\apache\tuscany\tuscany-project\1.0-incubator- SNAPSHOT\tuscany-project-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Feb 15 03:07:45 VET 2007 [INFO] Final Memory: 3M/7M [INFO] I suppose it would download many dependencies before BUILD SUCCESSFUL, but no dependency was download :s Am I missing something or it should work this way? Thanks, Adriano Crestani -- Yang ZHONG
Re: mvn problem?
OK, but the problem is I've already cleaned up all the tuscany files I had. And then I downloaded everything again from https://svn.apache.org/repos/asf/incubator/tuscany/java and the problem continues yet :s. Is there any problem to use tortoise instead of svn? Adriano Crestani On 2/15/07, Yang ZHONG [EMAIL PROTECTED] wrote: I saw similar errors once after I accidentally downloaded files including POMs into overlapped folder hierarchy. Downloading from scratch solved my problem. On 2/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I cleaned up my tuscany java files of my computer, then I download the java files from the repository again. OK, till there everything worked fine. But when I try to execute mvn only it appears: [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Feb 15 03:07:23 VET 2007 [INFO] Final Memory: 1M/4M [INFO] C:\Adriano\Faculdade\Tuscanycd tuscany C:\Adriano\Faculdade\Tuscany\tuscanymvn [INFO] Scanning for projects... [INFO] - --- [INFO] Building Tuscany Project [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing C:\Adriano\Faculdade\Tuscany\tuscany\pom.xml to C:\Documents a nd Settings\ADR\.m2\repository\org\apache\tuscany\tuscany-project\1.0-incubator- SNAPSHOT\tuscany-project-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Feb 15 03:07:45 VET 2007 [INFO] Final Memory: 3M/7M [INFO] I suppose it would download many dependencies before BUILD SUCCESSFUL, but no dependency was download :s Am I missing something or it should work this way? Thanks, Adriano Crestani -- Yang ZHONG
Re: mvn problem?
On Feb 14, 2007, at 10:15 PM, Adriano Crestani wrote: I suppose it would download many dependencies before BUILD SUCCESSFUL, but no dependency was download :s Am I missing something or it should work this way? It is meant to work this way. The top-level directory is just a placeholder - the actual modules are underneath it (sdo, das, sca, etc.). You should be able to check out any one of those on its own and build it separately. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
