Re: Contents of Tuscany binary archives
Perhaps you could issue the external dependencies in a separate archive; that would need the appropriate N L of course, but would not change very often. Sounds attractive. So we would have tuscany-binaries tuscany-dependencies tuscany-src I think this would be an advantage if we go ahead and split up our distributions into smaller units as suggested in [1]. At the moment the distribution contains everything and the chances that a dependency version will change is high. With smaller, more focused distribution zips, we may be able to maintain a set of dependency versions as the Tuscany function matures. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
[jira] Closed: (TUSCANY-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1516. -- Resolution: Cannot Reproduce Closing as Cannot Reproduce as per the previous comments the attached test is missing files and out of date. This is likely fixed now anyway, please reopen if the issue persists. Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Fix For: Java-SCA-Next Attachments: default.composite, MyServiceImpl.java, mySimpleService.composite, MyTotalService.java, MyTotalServiceImpl.java, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- 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: Contents of Tuscany binary archives
On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] wrote: Perhaps you could issue the external dependencies in a separate archive; that would need the appropriate N L of course, but would not change very often. Sounds attractive. So we would have tuscany-binaries tuscany-dependencies tuscany-src I think this would be an advantage if we go ahead and split up our distributions into smaller units as suggested in [1]. At the moment the distribution contains everything and the chances that a dependency version will change is high. With smaller, more focused distribution zips, we may be able to maintain a set of dependency versions as the Tuscany function matures. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html There would still be a download available that includes both Tuscany and the dependency jars though right? This would just add additional downloads separating Tuscany and dependencies? ...ant
Re: Contents of Tuscany binary archives
On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] wrote: Perhaps you could issue the external dependencies in a separate archive; that would need the appropriate N L of course, but would not change very often. Sounds attractive. So we would have tuscany-binaries tuscany-dependencies tuscany-src I think this would be an advantage if we go ahead and split up our distributions into smaller units as suggested in [1]. At the moment the distribution contains everything and the chances that a dependency version will change is high. With smaller, more focused distribution zips, we may be able to maintain a set of dependency versions as the Tuscany function matures. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html There would still be a download available that includes both Tuscany and the dependency jars though right? This would just add additional downloads separating Tuscany and dependencies? ...ant so you mean... tuscany-binaries tuscany-binaries-with-dependencies tuscany-src Sebastien pointed us toward Spring as another example which, for the framework, has the slightly different pattern ?-binaries ?-binaries+dependencies-src-samples Whichever turns out to be the favoured style in the project I'd like to take a more static approach to dealing with and packaging binary dependencies and their associated licenses. Simon
Re: Contents of Tuscany binary archives
An alternative to what we do now with all the licenses embedded in the one top level LICENSE file is to include the licenses in individual files either in a separate licenses folder or in the same folder as the dependency so its real easy to see if any are missing and what they apply to. I thought that was discouraged but it seems to be becoming acceptable again and makes thing clear i think. +1 Having separate license files, one for each dependency where appropriate, doesn't mean we can't concat them together into a top level if that is required. Another thing that would help a lot is to use the Maven plugins to help generate our legal files instead of creating them by hand. Me immediate reaction is that I don't think having more maven plugins is a good thing. A while back I looked at the plugin configuration that CxF use to generate their license information and it seemed effective but ultimately seems like quite a complicated way of reading a configuration file that maps dependencies to licenses. Probably OK if you wrote the plugin but personally I found it quite difficult to follow. Maybe I didn't spend enough time on it. I know more about releases now so I'll take another look and see if it is clearer. Simon
Re: Contents of Tuscany binary archives
On 29/01/2008, Simon Laws [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] wrote: Perhaps you could issue the external dependencies in a separate archive; that would need the appropriate N L of course, but would not change very often. Sounds attractive. So we would have tuscany-binaries tuscany-dependencies tuscany-src I think this would be an advantage if we go ahead and split up our distributions into smaller units as suggested in [1]. At the moment the distribution contains everything and the chances that a dependency version will change is high. With smaller, more focused distribution zips, we may be able to maintain a set of dependency versions as the Tuscany function matures. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html There would still be a download available that includes both Tuscany and the dependency jars though right? This would just add additional downloads separating Tuscany and dependencies? ...ant so you mean... tuscany-binaries tuscany-binaries-with-dependencies tuscany-src The advantage of having a separate dependency package is that you only need to update it when one of the library items changes. The disadvantage is having to download 2 archives initially. I see that as very minor. Sebastien pointed us toward Spring as another example which, for the framework, has the slightly different pattern ?-binaries ?-binaries+dependencies-src-samples I don't like that - seems a waste to have to download the dependencies just to get the samples. Whichever turns out to be the favoured style in the project I'd like to take a more static approach to dealing with and packaging binary dependencies and their associated licenses. Simon SebastiAn ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN props
Having seen the version from sebb I note there's just a [miscellany] introducer required. I'll fix it. Kelvin. On 29/01/2008, kelvin goodson [EMAIL PROTECTED] wrote: Substituting the contents of this file into my config file causes the error svn: C:\Documents and Settings\Administrator\Application Data\Subversion\config:4: Section header expected when using svn command line version ... svn, version 1.4.5 (r25188) compiled Aug 22 2007, 20:56:15 or TortoiseSVN 1.4.4, Build 9706 - 32 Bit , 2007/06/09 09:44:02 so for some reason I don't think it likes encountering enable-auto-props = yes as a first functional line Kelvin. On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: Just as an fyi follow on from TUSCANY-2019 does everyone know they can (and should) have their SVN configured to automatically set SVN properties like eol-style? We've a template file for this at https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props, if you're on Windows your subversion config file might be somewhere like: C:\Documents and Settings\Administrator\Application Data\Subversion\config. ...ant
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Comments inline. Note that I have also some prototype of a install program in my sandbox. On Jan 29, 2008 7:14 AM, Simon Laws [EMAIL PROTECTED] wrote: On Jan 28, 2008 5:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... I'm not too keen on scanning a disk directory as it doesn't apply to a distributed environment, I'd prefer to: - define a model representing a contribution repository - persist it in some XML form I've started on some model code in my sandbox [1]. Feel free to use and abuse. Regards Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/ Looking a svn I find there is already a ContributionRepository implementation [1]. There may be a little bit too much function in there at the moment but it's useful to see it none the less. So, to work out what it does. First question concerns the store() method. public URL store(String contribution, URL sourceURL, InputStream contributionStream). Can someone explain what the sourceURL is for? contribution is the URI for the contribution being stored SourceURL is the URL pointing to the contribution you want to store in the repository. InputStream is the content of the contribution (optional) The model in my sandbox [2], which is very simlar to the XML that the current contribution repository uses, now holds node and contribution name information [3]. These could be two separate models to decouple the management of contributions from the process of associating them together. I'd keep the info in one place but I expect other's views will vary. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/contribution-impl/src/main/java/org/apache/tuscany/sca/contribution/service/impl/ContributionRepositoryImpl.java [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-model-xml/src/test/resources/org/apache/tuscany/sca/domain/model/xml/test.domain -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
On Jan 28, 2008 5:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... I'm not too keen on scanning a disk directory as it doesn't apply to a distributed environment, I'd prefer to: - define a model representing a contribution repository - persist it in some XML form I've started on some model code in my sandbox [1]. Feel free to use and abuse. Regards Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/ Looking a svn I find there is already a ContributionRepository implementation [1]. There may be a little bit too much function in there at the moment but it's useful to see it none the less. So, to work out what it does. First question concerns the store() method. public URL store(String contribution, URL sourceURL, InputStream contributionStream). Can someone explain what the sourceURL is for? The model in my sandbox [2], which is very simlar to the XML that the current contribution repository uses, now holds node and contribution name information [3]. These could be two separate models to decouple the management of contributions from the process of associating them together. I'd keep the info in one place but I expect other's views will vary. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/contribution-impl/src/main/java/org/apache/tuscany/sca/contribution/service/impl/ContributionRepositoryImpl.java [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-model-xml/src/test/resources/org/apache/tuscany/sca/domain/model/xml/test.domain
Re: SCA contribution packaging schemes: was: SCA runtimes
On Jan 28, 2008 5:34 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip I don't think that a Webapp is the right architecture but I may be wrong or missing something, so you should probably just try and see for yourself if this is what you want to do. Can you explain more about why what you mean by not the right architecture? There has been confusion and disagreement around what Tuscany should be doing with webapps for a long time, years even, so maybe its time we tried to get some consensus on this. ...ant
Re: SVN props
The ASF version has: ... [miscellany] enable-auto-props = yes ... On 29/01/2008, kelvin goodson [EMAIL PROTECTED] wrote: Substituting the contents of this file into my config file causes the error svn: C:\Documents and Settings\Administrator\Application Data\Subversion\config:4: Section header expected when using svn command line version ... svn, version 1.4.5 (r25188) compiled Aug 22 2007, 20:56:15 or TortoiseSVN 1.4.4, Build 9706 - 32 Bit , 2007/06/09 09:44:02 so for some reason I don't think it likes encountering enable-auto-props = yes as a first functional line Kelvin. On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: Just as an fyi follow on from TUSCANY-2019 does everyone know they can (and should) have their SVN configured to automatically set SVN properties like eol-style? We've a template file for this at https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props, if you're on Windows your subversion config file might be somewhere like: C:\Documents and Settings\Administrator\Application Data\Subversion\config. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN props
Substituting the contents of this file into my config file causes the error svn: C:\Documents and Settings\Administrator\Application Data\Subversion\config:4: Section header expected when using svn command line version ... svn, version 1.4.5 (r25188) compiled Aug 22 2007, 20:56:15 or TortoiseSVN 1.4.4, Build 9706 - 32 Bit , 2007/06/09 09:44:02 so for some reason I don't think it likes encountering enable-auto-props = yes as a first functional line Kelvin. On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: Just as an fyi follow on from TUSCANY-2019 does everyone know they can (and should) have their SVN configured to automatically set SVN properties like eol-style? We've a template file for this at https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props, if you're on Windows your subversion config file might be somewhere like: C:\Documents and Settings\Administrator\Application Data\Subversion\config. ...ant
Re: SVN props
On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: Just as an fyi follow on from TUSCANY-2019 does everyone know they can (and should) have their SVN configured to automatically set SVN properties like eol-style? We've a template file for this at https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props, if you're on Windows your subversion config file might be somewhere like: C:\Documents and Settings\Administrator\Application Data\Subversion\config. The ASF version is at: http://www.apache.org/dev/svn-eol-style.txt see: http://www.apache.org/dev/version-control.html#https-svn-config ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On Jan 29, 2008 12:08 PM, sebb [EMAIL PROTECTED] wrote: On 29/01/2008, Simon Laws [EMAIL PROTECTED] wrote: An alternative to what we do now with all the licenses embedded in the one top level LICENSE file is to include the licenses in individual files either in a separate licenses folder or in the same folder as the dependency so its real easy to see if any are missing and what they apply to. I thought that was discouraged but it seems to be becoming acceptable again and makes thing clear i think. +1 Having separate license files, one for each dependency where appropriate, doesn't mean we can't concat them together into a top level if that is required. I'm not sure that separate LICENSE files are allowed (tried to find that out recently), but even if they are, AFAIK the main LICENSE file would have to have pointers to the additional files, so could not be a vanilla AL 2.0 anyway. The closest I can find to matching policy says : ...Otherwise, you should append their license(s) to the LICENSE file at the top of the distribution, or at least put a pointer in the LICENSE file to the third-party license. - http://www.apache.org/dev/apply-license.html So that makes it sound like it would be acceptable to have the top level LICENSE just point to a folder containing the other licenses. Several poddling releases that do this have been approved by the IPMC in the recent past and other non-incubating releases i've seen also do this. ...ant
[jira] Resolved: (TUSCANY-1483) Static SDO generator: problem with elements named internal*
[ https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-1483. -- Resolution: Fixed patch applied at revision 615169 Static SDO generator: problem with elements named internal* --- Key: TUSCANY-1483 URL: https://issues.apache.org/jira/browse/TUSCANY-1483 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Daniel Peter Priority: Minor Fix For: Java-SDO-Next Attachments: 1483-withTestCase.patch, 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd Hi, I run into a problem with the static generated SDOs, when having a xsd with the following two elements: xsd:element name=abc type=xsd:integer / xsd:element name=internalAbc type=xsd:integer / In the generated Impl class this leads twice to the same constant INTERNAL_ABC. The xsd elements might simply be renamed in order to avoid this clash, but there might be situations where this is not possible. The generator could use a different, less probable prefix (e.g. ___INTERNAL_). Thanks, Daniel. -- 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-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder resolved TUSCANY-2019. Resolution: Fixed All SVN changes applied. Thanks for the commands Sebb. SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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: Contents of Tuscany binary archives
On 29/01/2008, Simon Laws [EMAIL PROTECTED] wrote: An alternative to what we do now with all the licenses embedded in the one top level LICENSE file is to include the licenses in individual files either in a separate licenses folder or in the same folder as the dependency so its real easy to see if any are missing and what they apply to. I thought that was discouraged but it seems to be becoming acceptable again and makes thing clear i think. +1 Having separate license files, one for each dependency where appropriate, doesn't mean we can't concat them together into a top level if that is required. I'm not sure that separate LICENSE files are allowed (tried to find that out recently), but even if they are, AFAIK the main LICENSE file would have to have pointers to the additional files, so could not be a vanilla AL 2.0 anyway. Another thing that would help a lot is to use the Maven plugins to help generate our legal files instead of creating them by hand. There have been some discussions about this in Commons which have yet to be resolved. I would wait until those are resolved and the documentation is updated before going that route. Me immediate reaction is that I don't think having more maven plugins is a good thing. A while back I looked at the plugin configuration that CxF use to generate their license information and it seemed effective but ultimately seems like quite a complicated way of reading a configuration file that maps dependencies to licenses. Probably OK if you wrote the plugin but personally I found it quite difficult to follow. Maybe I didn't spend enough time on it. I know more about releases now so I'll take another look and see if it is clearer. See above. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1674) Missing NonBlockingInterceptor on service wire
[
https://issues.apache.org/jira/browse/TUSCANY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder resolved TUSCANY-1674.
Resolution: Fixed
Fixed as described
Missing NonBlockingInterceptor on service wire
--
Key: TUSCANY-1674
URL: https://issues.apache.org/jira/browse/TUSCANY-1674
Project: Tuscany
Issue Type: Bug
Reporter: Rashmi Hunt
Fix For: Java-SCA-Next
Attachments: patch-nonblocking.txt, RuntimeWireImpl.java
The reason why NonBlockingInterceptor is needed on the service wire as well
is, if there is no nonBlockingInterceptor at service wire and if the service
is invoked not from a reference then there is no asynch support even if the
call is non blocking. For e.g if a pure webservice client (or any pure
client) is sending a request to a non blocking service call, since Tuscany
code is currently missing a nonBlockingInterceptor on the service wire, there
is no async support for this case, even though the service operation is
marked as non-blocking.
Solution is straightforward. Add NonBlockingInterCeptor on service wire in
RuntimeWireImpl.initInvocationChains() for the service wire clause
Binding serviceBinding = wireTarget.getBinding();
if (operation.isNonBlocking()) {
addNonBlockingInterceptor(service, serviceBinding, chain);
}
And add a new addNonBlockingInterceptor() function which takes params
service, serviceBinding, chain
/**
* Add a non-blocking interceptor if the service binding needs it
*
* @param service
* @param binding
* @param chain
*/
private void addNonBlockingInterceptor(ComponentService service, Binding
binding, InvocationChain chain) {
ServiceBindingProvider provider =
((RuntimeComponentService)service).getBindingProvider(binding);
if (provider != null) {
boolean supportsAsyncOneWayInvocation = false;
if (provider instanceof ServiceBindingProvider2) {
supportsAsyncOneWayInvocation =
((ServiceBindingProvider2)provider).supportsAsyncOneWayInvocation();
} else {
// Must be an old provider that doesn't have this method. If
this is a old provider keep the behavior
// as is where there is no nonBlockingInterceptor on the
service wire. If a binding provider needs a
// nonBlocking interceptor, it would have been implemented
ServiceBindingProvider2 and indicated
// supportsAsyncOneWayInvocation accordingly
supportsAsyncOneWayInvocation = true;
}
if (!supportsAsyncOneWayInvocation) {
chain.addInterceptor(new
NonBlockingInterceptor(workScheduler));
}
}
}
--
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: Contents of Tuscany binary archives
On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 12:08 PM, sebb [EMAIL PROTECTED] wrote: On 29/01/2008, Simon Laws [EMAIL PROTECTED] wrote: An alternative to what we do now with all the licenses embedded in the one top level LICENSE file is to include the licenses in individual files either in a separate licenses folder or in the same folder as the dependency so its real easy to see if any are missing and what they apply to. I thought that was discouraged but it seems to be becoming acceptable again and makes thing clear i think. +1 Having separate license files, one for each dependency where appropriate, doesn't mean we can't concat them together into a top level if that is required. I'm not sure that separate LICENSE files are allowed (tried to find that out recently), but even if they are, AFAIK the main LICENSE file would have to have pointers to the additional files, so could not be a vanilla AL 2.0 anyway. The closest I can find to matching policy says : ...Otherwise, you should append their license(s) to the LICENSE file at the top of the distribution, or at least put a pointer in the LICENSE file to the third-party license. - http://www.apache.org/dev/apply-license.html Great! That's what I was looking for - now to find the thread where the question was raised ;-) So that makes it sound like it would be acceptable to have the top level LICENSE just point to a folder containing the other licenses. Several poddling releases that do this have been approved by the IPMC in the recent past and other non-incubating releases i've seen also do this. Agreed. Or perhaps put all the LICENSES in the same directory, but name the 3rd party ones accordingly, e.g. LICENSE_jdom etc ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures
[ https://issues.apache.org/jira/browse/TUSCANY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-2011. -- Resolution: Fixed completed at revision 616270 include apache headers in xmls and xsds without causing test case failures -- Key: TUSCANY-2011 URL: https://issues.apache.org/jira/browse/TUSCANY-2011 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next there are total 7 files in sdo-impl and 3 files in tools-test which can contain Apache headers without any test case failures, so do so for a successful RAT report -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On Jan 29, 2008 10:28 AM, Simon Laws [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] wrote: Perhaps you could issue the external dependencies in a separate archive; that would need the appropriate N L of course, but would not change very often. Sounds attractive. So we would have tuscany-binaries tuscany-dependencies tuscany-src I think this would be an advantage if we go ahead and split up our distributions into smaller units as suggested in [1]. At the moment the distribution contains everything and the chances that a dependency version will change is high. With smaller, more focused distribution zips, we may be able to maintain a set of dependency versions as the Tuscany function matures. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html There would still be a download available that includes both Tuscany and the dependency jars though right? This would just add additional downloads separating Tuscany and dependencies? ...ant so you mean... tuscany-binaries tuscany-binaries-with-dependencies tuscany-src Sebastien pointed us toward Spring as another example which, for the framework, has the slightly different pattern ?-binaries ?-binaries+dependencies-src-samples Whichever turns out to be the favoured style in the project I'd like to take a more static approach to dealing with and packaging binary dependencies and their associated licenses. Simon An alternative to what we do now with all the licenses embedded in the one top level LICENSE file is to include the licenses in individual files either in a separate licenses folder or in the same folder as the dependency so its real easy to see if any are missing and what they apply to. I thought that was discouraged but it seems to be becoming acceptable again and makes thing clear i think. Another thing that would help a lot is to use the Maven plugins to help generate our legal files instead of creating them by hand. ...ant
SVN props
Just as an fyi follow on from TUSCANY-2019 does everyone know they can (and should) have their SVN configured to automatically set SVN properties like eol-style? We've a template file for this at https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props, if you're on Windows your subversion config file might be somewhere like: C:\Documents and Settings\Administrator\Application Data\Subversion\config. ...ant
[jira] Created: (TUSCANY-2021) ComponentContext.getRequestContext() does not return null when no active request
ComponentContext.getRequestContext() does not return null when no active request Key: TUSCANY-2021 URL: https://issues.apache.org/jira/browse/TUSCANY-2021 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: All Reporter: Simon Nash Assignee: Simon Nash Priority: Minor Fix For: Java-SCA-Next When calling ComponentContext.getRequestContext() from an @Init method, null should be returned (see lines 809/810 of the Java Annotations and APIs spec). Instead, a non-functional instance of RequestContextImpl is returned. -- 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] Assigned: (TUSCANY-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-2019: -- Assignee: ant elder SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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: Conversation from a non-SCA application
See inline.
Simon
Nishant Joshi wrote:
Hi,
First i didn't get what you mean by I started the server first, noted the
random port number
that was assigned, then built the client using that port number.
But I have tried with modifying the sample callback-ws-service in 1.1-RC3
I got the same exception that i have posted before...
following is the only change i have done in
callback-ws-service\MyServiceImpl.java
-
@Context
protected ComponentContext componentContext;
@Init
public void init() {
System.out.println(Init);
myServiceCallback = componentContext.getRequestContext
().getCallback();
}
You can't do componentContext.getRequestContext().getCallback() in an
@Init method. You need to call this from the business method that
receives the forward request. This is because the request context
with the callback destination doesn't exist until the forward method
is invoked.
According to the spec, getRequestContext() should return null if there is
no current request. Unfortunately, Tuscany is not doing this. I have
opened TUSCANY-2021 for this problem. If getRequestContext() had returned
null as the spec says, you would have seen a NullPointerException and been
able to diagnose the problem more easily.
Simon
-
Following is the output of server.
--
Jan 29, 2008 10:35:39 AM org.apache.tuscany.sca.node.impl.SCADomainProxyImplinit
INFO: Domain will be started stand-alone as domain URL is not provided
Jan 29, 2008 10:35:39 AM
org.apache.tuscany.sca.domain.impl.SCADomainImplregisterNode
INFO: Registered node: http://nishantj02:3283 at endpoint
http://nishantj02:3283
Jan 29, 2008 10:35:39 AM
org.apache.tuscany.sca.node.impl.SCADomainProxyImplcreateRuntime
INFO: Domain management configured from
file:/C:/Downloads/Tuscany/1.1-RC3/tuscany-sca-1.1-incubating/lib/tuscany-
sca-all-1.1-incubating.jar
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping:
http://nishantj02:3283/SCADomainEventServiceProxyComponent
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping:
http://nishantj02:3283/SCADomainAPIServiceProxyComponent
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping:
http://nishantj02:3283/SCANodeManagerComponent/SCANodeManagerService
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping:
http://nishantj02:3283/SCANodeManagerComponent/ComponentManagerService/*
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping:
http://nishantj02:3283/SCANodeManagerComponent/ComponentManagerService
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping: http://nishantj02:3283/SCADomain/scaDomain.js
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.node.impl.SCANodeImplactivateComposite
INFO: Building composite: {http://callbackws}callbackws
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.node.impl.SCANodeImplstartComposite
INFO: Starting composite: {http://callbackws}callbackws
Jan 29, 2008 10:35:45 AM
org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping
INFO: Added Servlet mapping: http://nishantj02:8086/MyServiceComponent
Callback server started (press enter to shutdown)
Init
someMethod on thread Thread[pool-1-thread-3,5,main]
Sleeping ...
RuntimeException invoking receiveResult:
java.lang.reflect.UndeclaredThrowableException
java.lang.reflect.UndeclaredThrowableException
at $Proxy17.receiveResult(Unknown Source)
at myserver.MyServiceImpl.someMethod(MyServiceImpl.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke
(JavaImplementationInvoker.java:105)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke
Re: Distribution zips and what they contain, was: SCA runtimes
Sorry for the late response. I have been travelling and in OASIS meetings, and I'm just catching up with the ML now. See comments inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need +1 to both of these. It would also help modularity by eliminating some undesired dependencies, and it would give people a better understanding of the true size of Tuscany. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components I think it would make sense to have binding.ws in here. If we are including binding.sca (as auggested by Sebastien), this implies a need for binding.ws to handle remote endpoints. - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components +1 (see comment above). - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components +1 - tuscany-process.zip - For process development BPEL and XQuery components +1 - tuscany-all.zip - all of the above If this is exactly equal to the sum of all of the above, then we just need a zipzip file that contains the other zips, with a script to unzip them all into the same set of directories. Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. +1 for taking this as a first step. I'm also assuming that the relevant samples are included in each zip. +1 Simon Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Jan 29, 2008 3:09 PM, Simon Nash [EMAIL PROTECTED] wrote: Sorry for the late response. I have been travelling and in OASIS meetings, and I'm just catching up with the ML now. See comments inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need +1 to both of these. It would also help modularity by eliminating some undesired dependencies, and it would give people a better understanding of the true size of Tuscany. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components I think it would make sense to have binding.ws in here. If we are including binding.sca (as auggested by Sebastien), this implies a need for binding.ws to handle remote endpoints. I agree with that. Not sure i agree all the other distro's will really help the goal of making things easier for people to find what they need but if we do have a core distro then i think it should include WS support. ...ant
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a)
Looks good to me, thanks for correcting the problems mentioned by Sebastian. +1 Matthieu On Jan 28, 2008 9:31 AM, Simon Laws [EMAIL PROTECTED] wrote: Hi, The previous VOTE thread here for SCA Java 1.1-incubating identified some issues. http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html A new release candidate (RC3a) has been created addressing the issues as discussed in the previous thread. I'm starting this IPMC VOTE thread in parallel with the project vote thread as the material content of the release hasn't changed significantly and I don't want to delay before getting IPMC eyeballs on it. The ongoing thread in the Tuscany community can be found here http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27401.html The release includes a set of bug-fixes and new function such as the implementation of binding.jms. You can see a list of changes at: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/distribution/src/main/release/CHANGES The signed binary and source distributions, the RAT reports, and the Maven staging repository are listed at the following links. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/ Stage maven repo: http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ RAT report: http://people.apache.org/~slaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txthttp://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3a/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ Please review and approve the release. This vote will remain open for at least 72 hours. Thank you for your attention, Simon
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a)
As already reported, I've not been able to build the release successfully. Any ideas on what is going wrong? Also, there are quite a few files missing from the source archive. On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: +1 to release RC3a for 1.1. In the building the source from an empty maven repo, I once hit the issue reported in [1]. Overrall, the binary dirstro is good. I can run most of the samples successfully. I ran into an issue with the ant script for demos\xml-bigbank. [2]. The LICENSE/NOTICE files seems to be good too. I don't think [1] [2] are blocking issues. We could work them around and fix them in future releases. [1] http://jira.codehaus.org/browse/MEV-573 [2] https://issues.apache.org/jira/browse/TUSCANY-2022 Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: [EMAIL PROTECTED]; tuscany-dev tuscany-dev@ws.apache.org Sent: Monday, January 28, 2008 9:31 AM Subject: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a) Hi, The previous VOTE thread here for SCA Java 1.1-incubating identified some issues. http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html A new release candidate (RC3a) has been created addressing the issues as discussed in the previous thread. I'm starting this IPMC VOTE thread in parallel with the project vote thread as the material content of the release hasn't changed significantly and I don't want to delay before getting IPMC eyeballs on it. The ongoing thread in the Tuscany community can be found here http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27401.html The release includes a set of bug-fixes and new function such as the implementation of binding.jms. You can see a list of changes at: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/distribution/src/main/release/CHANGES The signed binary and source distributions, the RAT reports, and the Maven staging repository are listed at the following links. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/ Stage maven repo: http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ RAT report: http://people.apache.org/~slaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txthttp://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3a/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ Please review and approve the release. This vote will remain open for at least 72 hours. Thank you for your attention, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1767) Calculator-webapp fails to start in Geronimo (geronimo-tomcat6-jee5-2.0.1)
[ https://issues.apache.org/jira/browse/TUSCANY-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1767. -- Resolution: Fixed I guess this was fixed by adding the geronimo deployment descriptor in webapp samples. Calculator-webapp fails to start in Geronimo (geronimo-tomcat6-jee5-2.0.1) -- Key: TUSCANY-1767 URL: https://issues.apache.org/jira/browse/TUSCANY-1767 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-Next Reporter: Luciano Resende Fix For: Java-SCA-Next I tried deploying the calculator-webapp sample application from Tuscany 1.0 RC3a and was getting the following stack trace. It looks like we are not being able to create a stream reader to read the sca-contribution.xml file. ERROR [[/sample-calculator-webapp]] Exception starting filter tuscany org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:159) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:234) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:332) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:90) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3696) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4330) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:60) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:343) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:196) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:355) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$f8a16e7e.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:524) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at
[jira] Resolved: (TUSCANY-1699) Tuscany vs ESB, how developers choose SOA platform
[ https://issues.apache.org/jira/browse/TUSCANY-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1699. -- Resolution: Invalid Is this just a discussion, then it should be moved to dev/user list ? Similar discussion available at : http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26462.html Tuscany vs ESB, how developers choose SOA platform -- Key: TUSCANY-1699 URL: https://issues.apache.org/jira/browse/TUSCANY-1699 Project: Tuscany Issue Type: Test Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Muti platform, Tuscany, Java, SOA Reporter: gengshaoguang Fix For: Java-SCA-Next I'm not sure this is a right place to raise this issue, if not, just move it to another. Once I have been working on ESB for 3 months, it was a sub-task for me keep looking for answers of SOA. There ARE quite a lot of talks about SOA, and for a very long time, developers eye on SOA as a bright future, some one even see SOA as mysterious. In China, big software makers like to tell their customers they are SOA, it seems SOA has been a flag of technical pioneer. SOA starts from Web Service, but WS has been walking on the road for ages, SOA did no more works than integrators between systems. But now, definitly, SOA should play more roles than that. ESB came over on the bases of EAI, ESB improved EAI to SOA like, before, EAI not. ESB makes every thing into xml message driven, xml could be soap enveloped. from a developers point of view, ESB gives the following prospect: 1. A very common interface which makes every thing works as send+receive, but this just make things too loose, before, compile will find a lot of errors, but now not; 2. A single access point plus a message router, in these case, service consumer only need to post their request to this single point, and the router could analyse the requesting message, and deliver it to a right dealer / service; seems cool? Not really in fact, this could cause more jobs and errors, route map need define, some times messages changes and errors came out, you just don't know from whick sector; 3.Extension becomes easier with standard like JBI, developers could extend a ESB (if it is JBI compatible) with new feature on the bases of JBI, JBI is message bases, this extension work IS confortable; 4. ESB seems able to host a great deal of services, but the bigest problem is without a transaction support, (Tuscany too); 5. ESB has not give a solution of security, (Tuscany too) 6. I have tested ServiceMix, the performace is another headache, we got only 1/5 of a common tenology based system. I did not make such a comparison with Tuscany, but from the archtecture's view, Tuscany is faster of course. A ESB need to transfer xml for each sector to finish a process ring. 7. ESB is much more well known, and almost all the platform vender advertised their product ESB enabled; to be continued... -- 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: Comments on 1.1-RC3a
java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: windows xp version: 5.1 arch: x86 Family: windows
MAVEN_OPTS=-Xmx128M
I can upload the logs if they would be of any use.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] no fileName specfied for schema.
On 28/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
On Jan 28, 2008 8:44 AM, sebb [EMAIL PROTECTED] wrote:
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if it
is, it should probably not be in the lib directory, as it is not a jar
file.
This is an required ODE dependency.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does not seem to be present.
The jar tuscany-assembly-xsd-1.1-incubating.jar is available in modules.
Also the jars
tuscany-sca-all-1.1-incubating.jar
tuscany-sca-manifest.jar
are not mentioned in the LICENSE
Source archives
===
The following files and directories are present in SVN, but not in the
source archive:
demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
itest/contribution-classloader/contribution-test/src/main
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/databindings/interop/src/test
itest/databindings/jaxbgen/src/test
itest/databindings/jaxbgen/src/main/java
itest/databindings/sdogen/src/test
itest/databindings/sdogen/src/main/java
itest/domain/src/main/java/org
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/binding-dwr/src/test
modules/binding-ws-axis2/src/main/assembly
modules/binding-ws/src/test
modules/contribution-java/src/test/resources
modules/contribution-namespace/src/test/resources
modules/contribution-osgi/src/test
modules/contribution/src/test
modules/core-databinding/src/test/java/org/apache/tuscany/core
modules/core-spi/src/test
modules/databinding-saxon/src/test
modules/definitions/src/test
modules/definitions/src/main/resources
modules/domain-api/src/test
modules/domain/src/test
modules/extension-helper/src/test
modules/host-http/src/test
modules/host-jms-activemq/src/test
modules/host-jms/src/test
modules/host-webapp/src/test
modules/implementation-spring/src/test/java/org/apache/tuscany/implementation
modules/implementation-xquery/src/test
modules/implementation-xquery/src/main/java/org/apache/tuscany/implementation
modules/interface-wsdl-java2wsdl/src/main/resources
[jira] Resolved: (TUSCANY-1716) implementation.bpel build issue
[ https://issues.apache.org/jira/browse/TUSCANY-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1716. -- Resolution: Fixed Assignee: Luciano Resende This issue is now solved on new surefire releases and trunk is working as expected now. implementation.bpel build issue --- Key: TUSCANY-1716 URL: https://issues.apache.org/jira/browse/TUSCANY-1716 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next See threads for more information : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg23507.html and http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg23439.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1776) Top-level build with clean repo fails in implementation-bpel
[
https://issues.apache.org/jira/browse/TUSCANY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1776.
--
Resolution: Cannot Reproduce
I guess this is old, and is working now in Release 1.1 and trunk. Please reopen
if you still see issues.
Top-level build with clean repo fails in implementation-bpel
Key: TUSCANY-1776
URL: https://issues.apache.org/jira/browse/TUSCANY-1776
Project: Tuscany
Issue Type: Bug
Components: Java SCA BPEL Implementation Extension
Affects Versions: Java-SCA-1.0
Environment: Windowx XP, maven 2.0.5
Reporter: Simon Nash
Fix For: Java-SCA-Next
A top-level build of tuscany-sca-1.0-rc3a with an empty maven repo fails with
the following error. A subsequent rebuild without cleaning the repo works
fine.
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact: org.apache.ode:ode-dao-jpa-ojpa-derby:1.1:zip
[INFO] Expanding: C:\Documents and
Settings\nash\.m2\repository\org\apache\ode\ode-dao-jpa-ojpa-derby\1.1\ode-dao-jpa-ojpa-derby-1.1.zip
into
H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating-src\modules\implementation-bpel\target\test-classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-surefire-plugin:2.3:test': Unable to find the
mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.3:test' in the plugin
'org.apache.maven.plugins:maven-surefire-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-surefire-plugin:2.3:test.
[INFO]
[INFO] For more information, run Maven with the -e switch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a)
+1 to release RC3a for 1.1. In the building the source from an empty maven repo, I once hit the issue reported in [1]. Overrall, the binary dirstro is good. I can run most of the samples successfully. I ran into an issue with the ant script for demos\xml-bigbank. [2]. The LICENSE/NOTICE files seems to be good too. I don't think [1] [2] are blocking issues. We could work them around and fix them in future releases. [1] http://jira.codehaus.org/browse/MEV-573 [2] https://issues.apache.org/jira/browse/TUSCANY-2022 Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: [EMAIL PROTECTED]; tuscany-dev tuscany-dev@ws.apache.org Sent: Monday, January 28, 2008 9:31 AM Subject: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a) Hi, The previous VOTE thread here for SCA Java 1.1-incubating identified some issues. http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html A new release candidate (RC3a) has been created addressing the issues as discussed in the previous thread. I'm starting this IPMC VOTE thread in parallel with the project vote thread as the material content of the release hasn't changed significantly and I don't want to delay before getting IPMC eyeballs on it. The ongoing thread in the Tuscany community can be found here http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27401.html The release includes a set of bug-fixes and new function such as the implementation of binding.jms. You can see a list of changes at: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/distribution/src/main/release/CHANGES The signed binary and source distributions, the RAT reports, and the Maven staging repository are listed at the following links. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/ Stage maven repo: http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ RAT report: http://people.apache.org/~slaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txthttp://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3a/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ Please review and approve the release. This vote will remain open for at least 72 hours. Thank you for your attention, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2022) Generated build-dependency.xml for demos\xml-bigbank points to the wrong version of wstx-asl
Generated build-dependency.xml for demos\xml-bigbank points to the wrong version of wstx-asl Key: TUSCANY-2022 URL: https://issues.apache.org/jira/browse/TUSCANY-2022 Project: Tuscany Issue Type: Bug Components: Java SCA Samples, Java SCA Tools, Maven Plugins Affects Versions: Java-SCA-1.1 Reporter: Raymond Feng Fix For: Java-SCA-Next Here is the exception I'm seeing by running ant run under demos\xml-bigbank. Buildfile: build.xml run: [java] Exception in thread main javax.xml.stream.FactoryConfigurationErro r: Provider com.bea.xml.stream.MXParserFactory not found [java] at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) [java] at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) [java] at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) [java] at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory. java:136) [java] at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeB uilder.createContributionService(ReallySmallRuntimeBuilder.java:181) [java] at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime. start(ReallySmallRuntime.java:129) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.i nit(DefaultSCADomain.java:99) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:230) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC ADomain.java:69) [java] at bigbank.BigBankClient.main(BigBankClient.java:30) [java] Java Result: 1 The dependency analysis shows that wstx-asl-3.2.0 is pulled by neethi. [INFO] | +- org.apache.tuscany.sca:tuscany-policy-xml:jar:1.1-incubating:compile [INFO] | | +- org.apache.ws.commons.axiom:axiom-api:jar:1.2.5:compile [INFO] | | | \- jaxen:jaxen:jar:1.1-beta-10:compile [INFO] | | \- org.apache.neethi:neethi:jar:2.0.2:compile [INFO] | | +- org.apache.ws.commons.axiom:axiom-impl:jar:1.2.5:compile [INFO] | | | \- javax.mail:mail:jar:1.4:compile [INFO] | | +- org.codehaus.woodstox:wstx-asl:jar:3.2.0:compile [INFO] | | \- commons-logging:commons-logging:jar:1.1:compile Our binary contribution ships wstx-asl-3.2.1.jar. The -- 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: Comments on 1.1-RC3a
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] no fileName specfied for schema.
On 28/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
On Jan 28, 2008 8:44 AM, sebb [EMAIL PROTECTED] wrote:
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if it
is, it should probably not be in the lib directory, as it is not a jar
file.
This is an required ODE dependency.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does not seem to be present.
The jar tuscany-assembly-xsd-1.1-incubating.jar is available in modules.
Also the jars
tuscany-sca-all-1.1-incubating.jar
tuscany-sca-manifest.jar
are not mentioned in the LICENSE
Source archives
===
The following files and directories are present in SVN, but not in the
source archive:
demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
itest/contribution-classloader/contribution-test/src/main
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/databindings/interop/src/test
itest/databindings/jaxbgen/src/test
itest/databindings/jaxbgen/src/main/java
itest/databindings/sdogen/src/test
itest/databindings/sdogen/src/main/java
itest/domain/src/main/java/org
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/binding-dwr/src/test
modules/binding-ws-axis2/src/main/assembly
modules/binding-ws/src/test
modules/contribution-java/src/test/resources
modules/contribution-namespace/src/test/resources
modules/contribution-osgi/src/test
modules/contribution/src/test
modules/core-databinding/src/test/java/org/apache/tuscany/core
modules/core-spi/src/test
modules/databinding-saxon/src/test
modules/definitions/src/test
modules/definitions/src/main/resources
modules/domain-api/src/test
modules/domain/src/test
modules/extension-helper/src/test
modules/host-http/src/test
modules/host-jms-activemq/src/test
modules/host-jms/src/test
modules/host-webapp/src/test
modules/implementation-spring/src/test/java/org/apache/tuscany/implementation
modules/implementation-xquery/src/test
modules/implementation-xquery/src/main/java/org/apache/tuscany/implementation
modules/interface-wsdl-java2wsdl/src/main/resources
modules/interface-wsdl/src/test
modules/node-api/src/test
modules/node/src/test
modules/node/src/main/resources
modules/osgi-runtime/src/test/resources
modules/policy-transaction/src/test/resources
samples/binding-echo/binding-echo.svg
samples/binding-notification-consumer/src/test/resources
samples/binding-notification-producer/src/test/resources
samples/calculator/calculator.svg
samples/calculator-distributed/calculator-distributed.svg
samples/calculator-implementation-policies/calculator.svg
samples/calculator-rmi-reference/calculator-rmi-reference.svg
Re: Comments on 1.1-RC3a
I cannot reproduce either. Source distro builds sucessfully for me.
On Jan 29, 2008 12:36 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] no fileName specfied for schema.
On 28/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
On Jan 28, 2008 8:44 AM, sebb [EMAIL PROTECTED] wrote:
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if it
is, it should probably not be in the lib directory, as it is not a jar
file.
This is an required ODE dependency.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does not seem to be present.
The jar tuscany-assembly-xsd-1.1-incubating.jar is available in modules.
Also the jars
tuscany-sca-all-1.1-incubating.jar
tuscany-sca-manifest.jar
are not mentioned in the LICENSE
Source archives
===
The following files and directories are present in SVN, but not in the
source archive:
demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
itest/contribution-classloader/contribution-test/src/main
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/databindings/interop/src/test
itest/databindings/jaxbgen/src/test
itest/databindings/jaxbgen/src/main/java
itest/databindings/sdogen/src/test
itest/databindings/sdogen/src/main/java
itest/domain/src/main/java/org
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/binding-dwr/src/test
modules/binding-ws-axis2/src/main/assembly
modules/binding-ws/src/test
modules/contribution-java/src/test/resources
modules/contribution-namespace/src/test/resources
modules/contribution-osgi/src/test
modules/contribution/src/test
modules/core-databinding/src/test/java/org/apache/tuscany/core
modules/core-spi/src/test
modules/databinding-saxon/src/test
modules/definitions/src/test
modules/definitions/src/main/resources
modules/domain-api/src/test
modules/domain/src/test
modules/extension-helper/src/test
modules/host-http/src/test
modules/host-jms-activemq/src/test
modules/host-jms/src/test
modules/host-webapp/src/test
modules/implementation-spring/src/test/java/org/apache/tuscany/implementation
modules/implementation-xquery/src/test
modules/implementation-xquery/src/main/java/org/apache/tuscany/implementation
modules/interface-wsdl-java2wsdl/src/main/resources
modules/interface-wsdl/src/test
modules/node-api/src/test
modules/node/src/test
modules/node/src/main/resources
modules/osgi-runtime/src/test/resources
modules/policy-transaction/src/test/resources
samples/binding-echo/binding-echo.svg
Re: Comments on 1.1-RC3a
Hi,
I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is successful.
Can you try maven 2.0.5 or 2.0.7?
You can also try mvn -X to get more information about the failure.
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 1:10 PM
Subject: Re: Comments on 1.1-RC3a
java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: windows xp version: 5.1 arch: x86 Family: windows
MAVEN_OPTS=-Xmx128M
I can upload the logs if they would be of any use.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] no fileName specfied for schema.
On 28/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
On Jan 28, 2008 8:44 AM, sebb [EMAIL PROTECTED] wrote:
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if
it
is, it should probably not be in the lib directory, as it is not a
jar
file.
This is an required ODE dependency.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does not seem to be present.
The jar tuscany-assembly-xsd-1.1-incubating.jar is available in
modules.
Also the jars
tuscany-sca-all-1.1-incubating.jar
tuscany-sca-manifest.jar
are not mentioned in the LICENSE
Source archives
===
The following files and directories are present in SVN, but not in
the
source archive:
demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
itest/contribution-classloader/contribution-test/src/main
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/databindings/interop/src/test
itest/databindings/jaxbgen/src/test
itest/databindings/jaxbgen/src/main/java
itest/databindings/sdogen/src/test
itest/databindings/sdogen/src/main/java
itest/domain/src/main/java/org
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/binding-dwr/src/test
modules/binding-ws-axis2/src/main/assembly
modules/binding-ws/src/test
modules/contribution-java/src/test/resources
modules/contribution-namespace/src/test/resources
modules/contribution-osgi/src/test
modules/contribution/src/test
modules/core-databinding/src/test/java/org/apache/tuscany/core
modules/core-spi/src/test
modules/databinding-saxon/src/test
modules/definitions/src/test
modules/definitions/src/main/resources
modules/domain-api/src/test
modules/domain/src/test
modules/extension-helper/src/test
modules/host-http/src/test
modules/host-jms-activemq/src/test
modules/host-jms/src/test
modules/host-webapp/src/test
Re: Contents of Tuscany binary archives
sebb wrote: [snip] Sebastien pointed us toward Spring as another example which, for the framework, has the slightly different pattern ?-binaries ?-binaries+dependencies-src-samples Spring provides another package with the binaries, samples and docs, without dependencies [1], but I was not trying to cover samples when I pointed to the Spring example and was not suggesting to only have two packages. I'm actually proposing a more modular distro structure in another thread [2]. I don't like that - seems a waste to have to download the dependencies just to get the samples. I agree with you :) I wouldn't like it either. SebastiAn ;-) [1] http://sourceforge.net/project/showfiles.php?group_id=73357package_id=173644release_id=565295 [2] http://marc.info/?l=tuscany-devm=120102342123577 -- SebastiEn :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Simon Laws wrote: [snip] The model in my sandbox [2], which is very simlar to the XML that the current contribution repository uses, now holds node and contribution name information [3]. These could be two separate models to decouple the management of contributions from the process of associating them together. I like the decoupling part: - A workspace containing contributions (basically just a contribution URI - URL association). I've started to add that Workspace interface to the contribution package. - A description of the network containing nodes, we don't need a new model for that, as we already have implementation-node and can use something like: composite name=bobsNetWork component name=bobsNode1 implementation.node ... /component component name=bobsNode2 implementation.node ... /component /composite -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transaction intents
Hi Greg and Venkat, Answers to spec questions inline.. Dave - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, January 24, 2008 11:05 AM Subject: Re: Transaction intents Hi Greg, With respect to your last point on 'code removing intents', this has now been modified to leave the computed intents in the binding and implemenation instances. So now, bindings and implementations should be able to run thro the intents and act on things that they 'mayProvide'. I had already posted about this change yesterday in response to another mail you had posted on this subject. With respect to the other points, I'm keen to hear the perspectives of some SPECS folks to understand further. Thanks. - Venkat On Jan 24, 2008 9:21 PM, Greg Dritschler [EMAIL PROTECTED] wrote: I have been looking at the SCA Transaction spec and I have noticed some difficulties reconciling the transaction intent descriptions with the capabilities of the policy framework. 1) The SCA Transaction spec has several sets of mutually-exclusive intents: managedTransaction and noManagedTransaction, propagatesTransaction and suspendsTransaction, transactedOneWay and immediateOneWay. In the policy framework all intents are additive and there is no concept of exclusive intents. I know this problem was discussed in the OSOA Policy working group but it was left unresolved in the published specs. I think there needs to be some extension to the policy framework implementation to handle exclusive intents. Yes, the spec draft was intentionally published with a disconnect in the intent FW. We are now resolving the MUX functionality in the FW itself. 2) The transactedOneWay and immediateOneWay intents are unique in that they apply to services and references but are classified as implementation intents (rather than interaction intents). What this means is that the intents specified at each end of the wire having no bearing on each other. A reference might use transactedOneWay while the service uses immediateOneWay or vice versa. This conflicts with the following statement in section 1.4.10 of the SCA Policy Framework: If the element is a binding instance and its parent element (service, reference or callback) is wired, the required intents of the other side of the wire may be added to the intent set when they are available. This may simplify, or eliminate, the policy matching step later described in step C. I think this statement needs to be clarified to say that only interaction intents are to be copied. It also means there needs to be some extension to the intent definition that indicates whether an intent is an interaction intent or not. Correct on all points. I also found a minor problem in the Tuscany implementation of the policy framework. In the process of trying to find a policy set that matches the required intents, the code removes intents from the intent attach point that it finds in a bindingType or implementationType mayProvide list. I'm not sure how the binding or implementation can provide the intent if it has been removed. I think the code needs to be changed to preserve these intents in the intent attach point and just skip over them when looking for matching policy sets. Right. From a spec perspective, the point is that the mayProvides intents don't need to be included in the policySet search. Greg Dritschler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comments on 1.1-RC3a
I've just tried again with the same JDK and Maven.
I used mvn clean and then mvn -X
The log is here:
http://people.apache.org/~sebb/tuscany
mvn.log is the initial build I did.
mvn4.log is the last build with mvn -X.
Note that I was able to build the previous version of the release
successfully (once the memory issues were sorted out), but I have not
managed to finish building this one once.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is successful.
Can you try maven 2.0.5 or 2.0.7?
You can also try mvn -X to get more information about the failure.
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 1:10 PM
Subject: Re: Comments on 1.1-RC3a
java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: windows xp version: 5.1 arch: x86 Family: windows
MAVEN_OPTS=-Xmx128M
I can upload the logs if they would be of any use.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] no fileName specfied for schema.
On 28/01/2008, Luciano Resende [EMAIL PROTECTED] wrote:
On Jan 28, 2008 8:44 AM, sebb [EMAIL PROTECTED] wrote:
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if
it
is, it should probably not be in the lib directory, as it is not a
jar
file.
This is an required ODE dependency.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does not seem to be present.
The jar tuscany-assembly-xsd-1.1-incubating.jar is available in
modules.
Also the jars
tuscany-sca-all-1.1-incubating.jar
tuscany-sca-manifest.jar
are not mentioned in the LICENSE
Source archives
===
The following files and directories are present in SVN, but not in
the
source archive:
demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
itest/contribution-classloader/contribution-test/src/main
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/databindings/interop/src/test
itest/databindings/jaxbgen/src/test
itest/databindings/jaxbgen/src/main/java
itest/databindings/sdogen/src/test
itest/databindings/sdogen/src/main/java
itest/domain/src/main/java/org
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/binding-dwr/src/test
Re: Comments on 1.1-RC3a
Hi,
Hi,
It's strange. The main problem you have is that the following file cannot be
opened for write:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
Can you check if you already have this file on the disk which might be used
by other processes?
Thanks,
Raymond
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at java.io.FileWriter.init(FileWriter.java:46)
at
org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101)
at
org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273)
at java.lang.Thread.run(Thread.java:595)
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 4:46 PM
Subject: Re: Comments on 1.1-RC3a
I've just tried again with the same JDK and Maven.
I used mvn clean and then mvn -X
The log is here:
http://people.apache.org/~sebb/tuscany
mvn.log is the initial build I did.
mvn4.log is the last build with mvn -X.
Note that I was able to build the previous version of the release
successfully (once the memory issues were sorted out), but I have not
managed to finish building this one once.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is
successful.
Can you try maven 2.0.5 or 2.0.7?
You can also try mvn -X to get more information about the failure.
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 1:10 PM
Subject: Re: Comments on 1.1-RC3a
java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: windows xp version: 5.1 arch: x86 Family: windows
MAVEN_OPTS=-Xmx128M
I can upload the logs if they would be of any use.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by
JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [exec:java {execution: generate-test-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
...
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[jira] Commented: (TUSCANY-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563781#action_12563781 ] Sebb commented on TUSCANY-2019: --- I've only concentrated on java and xml files; there are a lot of other text files that need to be checked. The other file types I've seen in SVN are: # type count # bpel6 # classpath 1 # componentType 114 # composite 316 # config 1 # constrainingType3 # css 8 # ctrl4 # dat 127 # doc 1 # emx 1 # ext 1 # fixme 1 # gif 2 # groovy 6 # handlers1 # jar 8 # jks 8 # jpg 9 # js 14 # jsp 6 # lck 1 # list2 # mar 1 # mf 79 # off 2 # pdf 2 # png69 # prefs 1 # project 4 # py 6 # rb 6 # scdl1 # schemas 1 # smd 2 # sql 3 # svg47 # tmp 1 # vm 11 # wsdl 90 # xq 4 # xsd 212 # xsdconfig 1 # xsl 2 Some of these are binary, e.g. jpg, gif, and probably doc. If you can confirm which are definitely text (and should have eol:native) I can generate more scripts. SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt, svnjava.sh, svnxml.sh The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563778#action_12563778 ] Luciano Resende commented on TUSCANY-2019: -- Should we review and update the script we have under /etc and run that at least once before each release ? SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt, svnjava.sh, svnxml.sh The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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: Comments on 1.1-RC3a
Surely the problem is that the file does not exist?
See below.
D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java*
Directory of
D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate
27/01/2008 13:01 1,778 GreeterService.java.vm
1 File(s) 1,778 bytes
Directory of
D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate
30/01/2008 00:24 1,778 GreeterService.java.vm
1 File(s) 1,778 bytes
Directory of
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate
30/01/2008 00:24 1,778 GreeterService.java.vm
1 File(s) 1,778 bytes
Total Files Listed:
3 File(s) 5,334 bytes
D:\tuscany-sca-1.1-incubating-src
On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Hi,
It's strange. The main problem you have is that the following file cannot be
opened for write:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
Can you check if you already have this file on the disk which might be used
by other processes?
Thanks,
Raymond
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite
Exception : java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
java.io.FileNotFoundException:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java
(The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at java.io.FileWriter.init(FileWriter.java:46)
at
org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101)
at
org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273)
at java.lang.Thread.run(Thread.java:595)
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 4:46 PM
Subject: Re: Comments on 1.1-RC3a
I've just tried again with the same JDK and Maven.
I used mvn clean and then mvn -X
The log is here:
http://people.apache.org/~sebb/tuscany
mvn.log is the initial build I did.
mvn4.log is the last build with mvn -X.
Note that I was able to build the previous version of the release
successfully (once the memory issues were sorted out), but I have not
managed to finish building this one once.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is
successful.
Can you try maven 2.0.5 or 2.0.7?
You can also try mvn -X to get more information about the failure.
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, January 29, 2008 1:10 PM
Subject: Re: Comments on 1.1-RC3a
java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: windows xp version: 5.1 arch: x86 Family: windows
MAVEN_OPTS=-Xmx128M
I can upload the logs if they would be of any use.
On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Sebb.
I cannot reproduce the error you are seeing. Which JDK (set by
JAVA_HOME)
and which version of maven did you use for the build?
Thanks,
Raymond
- Original Message -
From: sebb [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, January 28, 2008 10:54 AM
Subject: Re: Comments on 1.1-RC3a
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
Processing greeter.composite.vm to
[jira] Reopened: (TUSCANY-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened TUSCANY-2019: --- There are still quite a few missing properties - scripts for .java and .xml to follow. SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated TUSCANY-2019: -- Attachment: svnxml.sh svnjava.sh SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt, svnjava.sh, svnxml.sh The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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-2019) SVN eol-style property not set correctly on all source files; other incorrect properties
[ https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563788#action_12563788 ] Sebb commented on TUSCANY-2019: --- Re the script: http://svn.apache.org/repos/asf/incubator/tuscany/java/etc/set_svn_properties.sh It should not really be necessary if committers ensure that the correct SVN defaults are set up before adding any new files. However, it is useful as a backup. By the way, it might be sensible to drop the svn directories as follows: find . ! -path '*/.svn*' etc SVN eol-style property not set correctly on all source files; other incorrect properties Key: TUSCANY-2019 URL: https://issues.apache.org/jira/browse/TUSCANY-2019 Project: Tuscany Issue Type: Bug Reporter: Sebb Assignee: ant elder Attachments: addnative.txt, removeexexc.txt, svnjava.sh, svnxml.sh The SVN eol-style property needs to be set to native for .java, .xml and other text files, otherwise problems may arise when SVN is used from OSes with different line-endings. Note that the lists of files in the attachments are not exhaustive; I hope to add some more later -- 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: Comments on 1.1-RC3a
It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273) at java.lang.Thread.run(Thread.java:595) - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 4:46 PM Subject: Re: Comments on 1.1-RC3a I've just tried again with the same JDK and Maven. I used mvn clean and then mvn -X The log is here: http://people.apache.org/~sebb/tuscany mvn.log is the initial build I did. mvn4.log is the last build with mvn -X. Note that I was able to build the previous version of the release successfully (once the memory issues were sorted out), but I have not managed to finish building this one once. On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is successful. Can you try maven 2.0.5 or 2.0.7? You can also try mvn -X to get more information about the failure. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 1:10 PM Subject: Re: Comments on 1.1-RC3a java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode) Maven version: 2.0.8 Java version: 1.5.0_13 OS name: windows xp version: 5.1 arch: x86 Family: windows MAVEN_OPTS=-Xmx128M I can upload the logs if they would be of any use. On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Sebb. I cannot reproduce the error you are seeing. Which JDK (set by JAVA_HOME) and which version of maven did you use for the build? Thanks, Raymond - Original Message -
Re: Comments on 1.1-RC3a
Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273) at java.lang.Thread.run(Thread.java:595) - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 4:46 PM Subject: Re: Comments on 1.1-RC3a I've just tried again with the same JDK and Maven. I used mvn clean and then mvn -X The log is here: http://people.apache.org/~sebb/tuscany mvn.log is the initial build I did. mvn4.log is the last build with mvn -X. Note that I was able to build the previous version of the release successfully (once the memory issues were sorted out), but I have not managed to finish building this one once. On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I just tried maven 2.0.8 and SUN JDK 1.5.0_13-b05. The build is successful. Can you try maven 2.0.5 or 2.0.7? You can also try mvn -X to get more information about the failure. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 1:10 PM Subject: Re: Comments
Re: Comments on 1.1-RC3a
Failed, I've uploaded mvnci.log On 30/01/2008, Luciano Resende [EMAIL PROTECTED] wrote: You could probably just try to build that module... with the following commands... cd D:\tuscany-sca-1.1-incubating-src\itest\databindings\ mvn clean install On Jan 29, 2008 6:22 PM, sebb [EMAIL PROTECTED] wrote: Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273) at java.lang.Thread.run(Thread.java:595) - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 4:46 PM Subject: Re: Comments on 1.1-RC3a I've just tried again with the same JDK and Maven. I used mvn clean and then mvn -X The log is here: http://people.apache.org/~sebb/tuscany mvn.log is the initial build I did. mvn4.log is the last build with mvn -X. Note that I was able to build the previous version of the release
Re: Comments on 1.1-RC3a
You could probably just try to build that module... with the following commands... cd D:\tuscany-sca-1.1-incubating-src\itest\databindings\ mvn clean install On Jan 29, 2008 6:22 PM, sebb [EMAIL PROTECTED] wrote: Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273) at java.lang.Thread.run(Thread.java:595) - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 4:46 PM Subject: Re: Comments on 1.1-RC3a I've just tried again with the same JDK and Maven. I used mvn clean and then mvn -X The log is here: http://people.apache.org/~sebb/tuscany mvn.log is the initial build I did. mvn4.log is the last build with mvn -X. Note that I was able to build the previous version of the release successfully (once the memory issues were sorted out), but I have not managed to finish building this one once. On 29/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I just tried maven 2.0.8 and SUN JDK
Re: Comments on 1.1-RC3a
On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: The debug log only provides information about the maven plugins. In your case, a java program in the itest module is invoked from maven and it fails to create a file. In that case, I would say that the program has a bug, because it is not reporting the failure I don't see any options other than attaching a debugger to figure out why the file cannot be created but I cannot reproduce the problem here. Sometimes I use this tool on Windows to find out if a file is in use: http://download.sysinternals.com/Files/ProcessExplorer.zip. Not the case here, because the file does not exist. Can you try to create a dummy file with the same name at the the same location to see it's possible? The failed name is: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java The path D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\ exists, but it only has a resources subdirectory, not a java one so I cannot create the file. This is presumably the cause. Rebooting your machine may help too. Already done that. As suggested by Luciano, you can build the databindings folder alone. Still fails, see other post. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 6:22 PM Subject: Re: Comments on 1.1-RC3a Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at
Re: Comments on 1.1-RC3a
The debug log only provides information about the maven plugins. In your case, a java program in the itest module is invoked from maven and it fails to create a file. I don't see any options other than attaching a debugger to figure out why the file cannot be created but I cannot reproduce the problem here. Sometimes I use this tool on Windows to find out if a file is in use: http://download.sysinternals.com/Files/ProcessExplorer.zip. Can you try to create a dummy file with the same name at the the same location to see it's possible? Rebooting your machine may help too. As suggested by Luciano, you can build the databindings folder alone. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 6:22 PM Subject: Re: Comments on 1.1-RC3a Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm to D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target/classes/greeter.composite Exception : java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) java.io.FileNotFoundException: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:70) at java.io.FileWriter.init(FileWriter.java:46) at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java:101) at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273) at java.lang.Thread.run(Thread.java:595) - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 4:46 PM Subject: Re: Comments on 1.1-RC3a I've just tried again with the same JDK and Maven. I used mvn clean and then mvn -X The log is here:
Re: Comments on 1.1-RC3a
Hi, Finally I can reproduce the problem now. This time I unzipped the src distro to a new folder and set JAVA_HOME to SUN's JDK. The same problem came out! The main issue here is that IBM JDK behaves differently than the SUN's JDK in creating a new file where some folders in the path don't exist yet. IBM JDK creates the intermediate folders while SUN's JDK complains with a FileNotFoundException. When I tried SUN's JDK this morning, the folders were already created from previous builds and the probem was hidden. Anyway, I will fix the code to make sure it creates the folders before opening the file. For the 1.1 release, I don't think it's a blocker since it's an itest and there are a few workarounds available (for example, using IBM JDK or manually create the folder). We should document it as a known issue. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 7:42 PM Subject: Re: Comments on 1.1-RC3a On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: The debug log only provides information about the maven plugins. In your case, a java program in the itest module is invoked from maven and it fails to create a file. In that case, I would say that the program has a bug, because it is not reporting the failure I don't see any options other than attaching a debugger to figure out why the file cannot be created but I cannot reproduce the problem here. Sometimes I use this tool on Windows to find out if a file is in use: http://download.sysinternals.com/Files/ProcessExplorer.zip. Not the case here, because the file does not exist. Can you try to create a dummy file with the same name at the the same location to see it's possible? The failed name is: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java The path D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\ exists, but it only has a resources subdirectory, not a java one so I cannot create the file. This is presumably the cause. Rebooting your machine may help too. Already done that. As suggested by Luciano, you can build the databindings folder alone. Still fails, see other post. Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 6:22 PM Subject: Re: Comments on 1.1-RC3a Indeed - what does the debug log say about why this did not occur? Is there any additional debugging that can be turned on to find out why it was not created? It takes 30 mins or so to run the build, so I don't want to redo it only to find that it needs to be done yet again with additional options. Alternatively, how can I re-run just the part of the build that failed? On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: It's supposed to generate the following file from GreeterService.java.vm. D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java For some strange reason, this file cannot be created in your case. Can you try to unzip the source distro to a different folder and build again? Thanks, Raymond - Original Message - From: sebb [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 29, 2008 5:32 PM Subject: Re: Comments on 1.1-RC3a Surely the problem is that the file does not exist? See below. D:\tuscany-sca-1.1-incubating-srcdir /s GreeterService.java* Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\src\main\resources\generate 27/01/2008 13:01 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\common\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Directory of D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\classes\generate 30/01/2008 00:24 1,778 GreeterService.java.vm 1 File(s) 1,778 bytes Total Files Listed: 3 File(s) 5,334 bytes D:\tuscany-sca-1.1-incubating-src On 30/01/2008, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Hi, It's strange. The main problem you have is that the following file cannot be opened for write: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target\..\src\main\java\org\apache\tuscany\sca\itest\sdodatabinding\GreeterService.java Can you check if you already have this file on the disk which might be used by other processes? Thanks, Raymond Building project from dir: D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target Processing greeter.composite.vm
