SDO Java ChangeSummary on DataObject
I'm thinking about the ChangeSummary on a DataObject feature introduced in SDO 2. My guess is there's no-one else planning to play in this space, but if you have an interest I'd welcome someone to check design ideas with. If anyone is looking for somewhere to begin to contribute, I'd be very happy to have some help with, say, some unit test cases that catch the more esoteric aspects of the spec. I've been jotting in rough fashion some design notes/issues on the wiki at http://wiki.apache.org/ws/Tuscany/TuscanyJava/Design/SDO/ChangeSummary . Please feel free to comment. -- Best Regards Kelvin Goodson
[C++] Axis2C Web Service Entrypoint
Hi All, I've been taking a look at Axis2C recently and I see that one of the items on the list for the ApacheCon C++ release ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks) is an Axis2C Web Service Entrypoint (jira# TUSCANY-429). I've had a quick hack around and got something going, so unless someone's already taken it, I'm happy to own this task and turn my hackings into something uselful! Cheers Andrew
Tuscany Icon
Guys, Here are a few concepts that you can base the Apache Tuscany project icon on: http://www.giorgiozanetti.ca/centro_italia/toscana/centrobeva_300.gif http://www.montalcino-tuscany.com/Cypress_group_and_hill_2.JPG http://www.backdrops.com.au/work/lg_imgs/BW%20Tuscany.jpg http://www.galleryone.com/images/fiore/fiore-country%20road,%20tuscany.jpg http://images.amazon.com/images/P/1894703014.01.LZZZ.jpg Cheers, Dushyanth Inguva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Axis2C Web Service Entrypoint
Andrew, great stuff. When you have something for us to look at you can post a patch on the jira. Please join us for an IRC chat tomorrow (I'll be sending a reminder note soon) Cheers, On 05/06/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, I've been taking a look at Axis2C recently and I see that one of the items on the list for the ApacheCon C++ release ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks) is an Axis2C Web Service Entrypoint (jira# TUSCANY-429). I've had a quick hack around and got something going, so unless someone's already taken it, I'm happy to own this task and turn my hackings into something uselful! Cheers Andrew -- Pete
IRC chat regarding C++ release - Tuesday 6th June
A reminder: We will have an IRC chat on Tuesday 6th June 17:00 BST (18:00 GMT) 12:00 (Eastern) 09:00 (Pacific) to finalize content and schedule to achieve this. Any input from Java Tuscans on their recent release experience would be welcome. The chat takes place on the freenode IRC network, (use server irc.freenode.net), on channel #tuscany, and is scheduled to last one hour, though it may run longer. Please join us! If you need an IRC client for windows, check out http://www.mirc.com, and http://www.mirc.com/links.html has some links to clients for other OS's. -- Pete
[jira] Assigned: (TUSCANY-438) instructions on how to run the sample apps should point to run build-dist.bat
[ http://issues.apache.org/jira/browse/TUSCANY-438?page=all ] Rick Rineholt reassigned TUSCANY-438: - Assign To: Rick Rineholt instructions on how to run the sample apps should point to run build-dist.bat - Key: TUSCANY-438 URL: http://issues.apache.org/jira/browse/TUSCANY-438 Project: Tuscany Type: Bug Components: Website Reporter: Luciano Resende Assignee: Rick Rineholt Attachments: patch-TUSCANY-438-projectjava.xml The following page have instructions on how to run the sample apps http://incubator.apache.org/tuscany/projectjava.html It currently says : Change the directory to the tuscany\java\distribution Issue mvn to build the distribution package. This does not seems to work for me and gives me an error around tuscany-polish, saying that the fixupJars were not available... After reading the BUILDING.txt I noticed the recommendation to run build-dist.bat and that seems to work and I can run the samples now.. We should update the page to point the user to run build-dist.bat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Recursive core architectural overview
Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). For the format, we will have an overview presentation which will cover the basics but we want to leave the majority of time open for questions and discussion. To facilitate this, please review the code (unit tests are a good place to start): http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ - The root location http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/spi/ - Defines the extension API for the runtime. There are different degrees of extension, the most common being found in the extensions package - The goal of this project is to clearly demarcate the runtime extension mechanism. Extensions themselves should reference these packages directly, as opposed to the runtime implementation (core2). http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ core2/ - The actual runtime implementation http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ containers/container.java/ - The Java CI model extension. There are other experimental Groovy and Spring extensions as well Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-204) DAS should allow for convention to reduce need for configuration
[ http://issues.apache.org/jira/browse/TUSCANY-204?page=all ] Kevin Williams closed TUSCANY-204: -- Resolution: Fixed The DAS now assumes that a Data Object property named ID is the primary key in the absence of contrary configuration. I am closing this and suggest that individual JIRAs be opened for subsequent Convention over Configuration items. DAS should allow for convention to reduce need for configuration Key: TUSCANY-204 URL: http://issues.apache.org/jira/browse/TUSCANY-204 Project: Tuscany Type: New Feature Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx DAS should allow users to avoid configuration items by following specific conventions. For example, in the absence of configuration specifying the prmary key for a table, the DAS could assume that a table column named ID is the PK. Taking this a step further, in the absence of config info specifying a relationship, the DAS could assume any column named _ID is a foreign key key to table . A column named _c could be assumed to be a collision column while _v could be considered a version column. This feature will enable a large set of DAS clients to operate without specifying any separate configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-234) column names in config file that don't correspond to actual table names are silently ignored.
[ http://issues.apache.org/jira/browse/TUSCANY-234?page=comments#action_12414800 ] Kevin Williams commented on TUSCANY-234: Maybe instead of a heavy validation mode we could provide a warning-level message in the log file to report entries in the Config that do not match anything in the result-set. Not sure this is a good idea since it is reasonable for a client to issue a query that does not select all columns for a table. column names in config file that don't correspond to actual table names are silently ignored. - Key: TUSCANY-234 URL: http://issues.apache.org/jira/browse/TUSCANY-234 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Rick Rineholt Fix For: Java-Mx When adding a converter in the config file my case mis matched to the column name this is related to TUSCANY-233 but it seems that if there are no matches altogether there is no check. An exception needs to be thrown that states the table and column that was searched for. Without a fix like this it can real difficult for the end user to isolate this error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Final Tuscany M1 release distribution
Hi, The final Tuscany M1 distribution is available there: http://people.apache.org/~jsdelfino/test-incubating-M1. We will publish these files on our Download page once we have fixed the few web site related JIRA issues that we discussed on the Tuscany IRC chat this morning. The top level LICENSE.txt file and the LICENSE.txt in the Rhino container JAR have been updated to include the NPL1.1 license. The previous distribution has been moved to http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history//RC5. I tried the distribution on Linux Redhat Enterprise 4 and Windows XP SP2. Could some people in the group please try to download the files and install as well? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Hi, I have created some basic slides and UML diagrams when I looked into the sandbox code last week (I need to do some adjustments since more refactorings were checked in). I can upload them into the wiki and Jim/Jeremy can verify to see if it's helpful. Thanks, Raymond - Original Message - From: Kenneth Tam [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, June 05, 2006 11:55 AM Subject: Re: Recursive core architectural overview I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Kenneth Tam wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Friday would work for me too. Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. I think the key area from a conceptal side would be the SPI module. In M1, the interfaces and implementation were mixed together in the core module and we refactored this to move all the interfaces and base classes into spi with just the implementation in core. A typical container or binding extension should be able to depend just on SPI and not need the core (unless it decides to). The intention is that all the SPI classes should have JavaDoc that clearly explains what they are for - we may not be there yet, but that's the goal. Any questions on them would be good so that it can be fed back into code. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Raymond Feng wrote: Hi, I have created some basic slides and UML diagrams when I looked into the sandbox code last week (I need to do some adjustments since more refactorings were checked in). I can upload them into the wiki and Jim/Jeremy can verify to see if it's helpful. Thanks - that would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing changes
Jeremy and Jim, A number of issues for the spec have been identified in this thread. Who is going to raise and track them with the spec group? Simon Jeremy Boynes wrote: On 5/29/06, Jim Marino [EMAIL PROTECTED] wrote: On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote: snip/ If a .componentType sidefile exists, it provides the definitive list of the implementation's services, references and properties. We probably need to clarify the spec here since side files overlay the introspected information in the Java CI spec. This makes sense since having part of the metadata in annotations and part in a side file doesn't really make sense, or is at least very prone to error. I think this is one of the most confusing areas of the spec especially when you have liberal defaulting rules. For example, the Java spec defines introspection rules that allow an unadorned POJO to be the implementation but that poses a high risk of conflict with a componentType sidefile. Every operation in every service must be mapped to a public method in the implementation. The implementation need not implement the service interface (although if the interface is defined in Java then we would recommend that it did). One use case where it maybe doesn't besides mediation is a mixin but that may be a bit esoteric for applications I think any mixins have to be applied before SCA introspection is done - probably worth defining that in the spec as well. That would make this bit clear, although a client may still get a runtime problem if the mapping is not valid (similar to an AbstractMethodError). Every reference and property in the sidefile must be mapped to an injection site in the implementation. Sites will be located in the following order: 1) a public or protected method or field identified in the sidefile 2) a public or protected method annotated with the applicable annotation 3) a public or protected field annotated with the applicable annotation 4) a public or protected setter method with the same name 5) a public or protected field with the same name For @Reference and @Property we need to be careful to use the name attribute and preserve the mappings to method or field until the point of injection as this was the cause of bugs and hacks in M1. Yes - I'm going to add method mapping information to the JavaComponentType model object to ensure this is preserved. However, unlike M1 where we had Injector information in the model I'm going to defer that to build time (this allows JavaComponentType to be in the SPI but the actual injection mechanism to remain in the core impl). If no sidefile exists then the component type will be derived by introspection of the implementation class. If the class or any superclass has an @Service annotation then the services are explicitly defined by that annotation. The set of services exposed will be the union of all @Service annotations in the class hierarchy. For clarity, the service interface will be remotable if the interface is annotated @Remotable, otherwise it will only be available to local components. If no @Service annotation is present then the services are defined by the interfaces that are implemented by the class or its superclass and any super-interfaces thereof. This follows from below but it may be worth pointing out. If no @Remotable is present, then all services will be local. Conversely, if only @Remotable is present, then the specified interfaces will be remotable. The spec is a little ambiguous here: it is assumed that all implemented interfaces that have been annotated as @Remotable are the service interfaces provided by the component. This can be read as saying that only the annotated interfaces are the service interfaces and all others are ignored. I used the language in the next paragraph to allow local services to be explictly defined and to provide resonable default behaviour for the common case where the class implements a single service interface. If any interface has an @Remotable or @Service annotation then the set of services is defined as the union of all such interfaces. If no interface is annotated, then the component type will define a single service comprising all public methods that are not reference or property injection sites. If that service can be exactly mapped to an interface implemented by the class then the service interface will be defined in terms of that interface. snip/ We should also formalize a way to for extenders to have custom property injectors stored somewhere that were created by custom annotation processors. This will allow people to introduce behavior into the assembly process such as injection of resources (I'm thinking about things like JPA PersistenceManager) As I said above, I would prefer if the implementation of injection was separate from the model of what needed to be injected. For example, the model would contain the mapping from a property to an injection
Re: Recursive core architectural overview
Friday is OK for me, but I'd prefer not to go too late in this time zone. Can we do this from 8.00 to 10.00 am PDT? Simon Jeremy Boynes wrote: Kenneth Tam wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Friday would work for me too. Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. I think the key area from a conceptal side would be the SPI module. In M1, the interfaces and implementation were mixed together in the core module and we refactored this to move all the interfaces and base classes into spi with just the implementation in core. A typical container or binding extension should be able to depend just on SPI and not need the core (unless it decides to). The intention is that all the SPI classes should have JavaDoc that clearly explains what they are for - we may not be there yet, but that's the goal. Any questions on them would be good so that it can be fed back into code. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Yes this would be appreciated. Can you make sure it's in a common graphic format - I'm too cheap to shell out the $$ for a UML tool ;-) Jim On Jun 5, 2006, at 12:29 PM, Jeremy Boynes wrote: Raymond Feng wrote: Hi, I have created some basic slides and UML diagrams when I looked into the sandbox code last week (I need to do some adjustments since more refactorings were checked in). I can upload them into the wiki and Jim/Jeremy can verify to see if it's helpful. Thanks - that would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final Tuscany M1 release distribution
I downloaded on XP and Fedora. Ran BB and a select few samples that seemed to run, but nothing more than that. Jean-Sebastien Delfino wrote: Hi, The final Tuscany M1 distribution is available there: http://people.apache.org/~jsdelfino/test-incubating-M1. We will publish these files on our Download page once we have fixed the few web site related JIRA issues that we discussed on the Tuscany IRC chat this morning. The top level LICENSE.txt file and the LICENSE.txt in the Rhino container JAR have been updated to include the NPL1.1 license. The previous distribution has been moved to http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history//RC5. I tried the distribution on Linux Redhat Enterprise 4 and Windows XP SP2. Could some people in the group please try to download the files and install as well? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final Tuscany M1 release distribution
DAS Stand-alone sample and BigBank sample app look good on OS X (10.4.6) Jean-Sebastien Delfino wrote: Hi, The final Tuscany M1 distribution is available there: http://people.apache.org/~jsdelfino/test-incubating-M1. We will publish these files on our Download page once we have fixed the few web site related JIRA issues that we discussed on the Tuscany IRC chat this morning. The top level LICENSE.txt file and the LICENSE.txt in the Rhino container JAR have been updated to include the NPL1.1 license. The previous distribution has been moved to http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history//RC5. I tried the distribution on Linux Redhat Enterprise 4 and Windows XP SP2. Could some people in the group please try to download the files and install as well? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-407) Getting Involved page has dead links for Java Project Page and C++ Project Page
[ http://issues.apache.org/jira/browse/TUSCANY-407?page=all ] Rick Rineholt resolved TUSCANY-407: --- Resolution: Fixed Should be fixed. May take a day for the site to reflect the change. Getting Involved page has dead links for Java Project Page and C++ Project Page -- Key: TUSCANY-407 URL: http://issues.apache.org/jira/browse/TUSCANY-407 Project: Tuscany Type: Bug Components: Website Versions: Java-M1-website Reporter: Kevin Williams Fix For: Java-M1-website The dead links are on this page : http://incubator.apache.org/tuscany/getinvolved.html The equivalent links from the Overview page (http://incubator.apache.org/tuscany/index.html) are good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-289) Document how to extend Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-289?page=all ] Raymond Feng updated TUSCANY-289: - Attachment: ExtendingTuscany.pdf Document how to extend Tuscany -- Key: TUSCANY-289 URL: http://issues.apache.org/jira/browse/TUSCANY-289 Project: Tuscany Type: New Feature Components: Website Versions: Java-M1-website Reporter: Jean-Sebastien Delfino Assignee: Raymond Feng Fix For: Java-M1-website Attachments: ExtendingTuscany.odt, ExtendingTuscany.pdf This is a key item for our release, discussed on our Wiki at http://wiki.apache.org/ws/Tuscany/Tasks. The outline of a document has been created by Jeremy at http://wiki.apache.org/ws/Tuscany/Extending. Jeremy and Jim have volunteered to do this work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Document for Tuscany-289
Hi, I have uploaded the 1st version of the document into Tuscany-289 with OpenOffice Text, PDF and the HTML format (converted from MS word document, not so nice in term of HTML but easier to view the UML diagrams). http://issues.apache.org/jira/browse/TUSCANY-289?page=all Please review. Thanks, Raymond
Re: Final Tuscany M1 release distribution
Jean-Sebastien Delfino wrote: Hi, The final Tuscany M1 distribution is available there: http://people.apache.org/~jsdelfino/test-incubating-M1. We will publish these files on our Download page once we have fixed the few web site related JIRA issues that we discussed on the Tuscany IRC chat this morning. The top level LICENSE.txt file and the LICENSE.txt in the Rhino container JAR have been updated to include the NPL1.1 license. The previous distribution has been moved to http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history//RC5. I tried the distribution on Linux Redhat Enterprise 4 and Windows XP SP2. Could some people in the group please try to download the files and install as well? Thanks. The final M1 distribution is now available at http://people.apache.org/dist/incubator/tuscany/incubating-M1. I uploaded a KEYS file with my public key and .asc signature files for the files in the distribution. This is the first time I do this, so could the people in the group experienced with signing releases please take a look, try to verify the signatures and let me know if there's any problem? To verify the signature of the distribution on Linux do the following: gpg KEYS gpg --verify tuscany-incubating-M1-src.tar.gz.asc tuscany-incubating-M1-src.tar.gz You should see the following: gpg: Signature made Mon 05 Jun 2006 06:52:42 PM PDT using RSA key ID 6C822ED9 gpg: Good signature from Jean-Sebastien Delfino [EMAIL PROTECTED] Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-292) Document our logging guidelines
[ http://issues.apache.org/jira/browse/TUSCANY-292?page=all ] Jean-Sebastien Delfino updated TUSCANY-292: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document our logging guidelines --- Key: TUSCANY-292 URL: http://issues.apache.org/jira/browse/TUSCANY-292 Project: Tuscany Type: New Feature Components: Website Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assignee: Jeremy Boynes Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need these guidelines on our web site. Jeremy has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-291) Document our test case development guidelines
[ http://issues.apache.org/jira/browse/TUSCANY-291?page=all ] Jean-Sebastien Delfino updated TUSCANY-291: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document our test case development guidelines - Key: TUSCANY-291 URL: http://issues.apache.org/jira/browse/TUSCANY-291 Project: Tuscany Type: New Feature Components: Website Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assignee: Jim Marino Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need these guidelines on our web site. Jim has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-215) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository
[ http://issues.apache.org/jira/browse/TUSCANY-215?page=all ] Jean-Sebastien Delfino updated TUSCANY-215: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository --- Key: TUSCANY-215 URL: http://issues.apache.org/jira/browse/TUSCANY-215 Project: Tuscany Type: Sub-task Components: Build System Versions: Java-M2 Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-M2 We need to document the steps to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository. Dan suggested mvn source:jar javadoc:jar deploy. We need to add these steps to our Wiki or Web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-138) Incorrect filename reference in wiki, http://wiki.apache.org/ws/Tuscany/TomcatIntegration (Tuscany/TomcatIntegration section)
[ http://issues.apache.org/jira/browse/TUSCANY-138?page=all ]
Jean-Sebastien Delfino updated TUSCANY-138:
---
Fix Version: Java-M2
(was: Java-M1-website)
Version: Java-M2
(was: Java-M1-website)
Incorrect filename reference in wiki,
http://wiki.apache.org/ws/Tuscany/TomcatIntegration
(Tuscany/TomcatIntegration section)
-
Key: TUSCANY-138
URL: http://issues.apache.org/jira/browse/TUSCANY-138
Project: Tuscany
Type: Bug
Components: Website
Versions: Java-M2
Reporter: Rashmi Hunt
Priority: Minor
Fix For: Java-M2
Trying to setup Tuscany/TomcatIntegration as per
http://wiki.apache.org/ws/Tuscany/TomcatIntegration
Steps says to copy bunch of jars into ${catalina.base}/server/lib directory.
One of the file
in this list is ws-policy-SNAPSHOT.jar
There is no file with the name ws-policy-SNAPSHOT.jar in the repository.
Corect file name for WS-Policy is
policy-0.92-snapshot.jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-79) Document the JavaScript component type
[ http://issues.apache.org/jira/browse/TUSCANY-79?page=all ] Jean-Sebastien Delfino updated TUSCANY-79: -- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document the JavaScript component type -- Key: TUSCANY-79 URL: http://issues.apache.org/jira/browse/TUSCANY-79 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: Java-M2 Reporter: ant elder Assignee: ant elder Priority: Minor Fix For: Java-M2 Create some doc describing a JavaScript component and script file, and how to configure them with componentType side files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] Jean-Sebastien Delfino updated TUSCANY-295: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assignee: ant elder Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-296) Document the architecture of the Java container
[ http://issues.apache.org/jira/browse/TUSCANY-296?page=all ] Jean-Sebastien Delfino updated TUSCANY-296: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document the architecture of the Java container --- Key: TUSCANY-296 URL: http://issues.apache.org/jira/browse/TUSCANY-296 Project: Tuscany Type: New Feature Components: Website Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assignee: Jim Marino Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Jim has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-344) Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1
[ http://issues.apache.org/jira/browse/TUSCANY-344?page=all ] Jean-Sebastien Delfino updated TUSCANY-344: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1 -- Key: TUSCANY-344 URL: http://issues.apache.org/jira/browse/TUSCANY-344 Project: Tuscany Type: Improvement Components: Website Versions: Java-M2 Environment: Fedora Core 5 Reporter: Simon Laws Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-M2 There is no readily available rpm for svn on Fedora Core but Fedora Core 5 come with subversion 1.3.1 in the install. Add a note to the GetTuscanyLinux instructions here: http://wiki.apache.org/ws/Tuscany/GetTuscany/Linux -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO C++ runtime - build error on Linux
Hi, To prepare for the C++ release IRC chat tomorrow morning, I'm trying to build the C++ SDO runtime and am getting a build error: Environment: Redhat Linux Enterprise 4 on a Thinkpad Here's the error I'm getting: make[5]: Entering directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/test' if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../runtime/core/test -I../../../runtime/core/src-g -O2 -MT sdotest.o -MD -MP -MF .deps/sdotest.Tpo -c -o sdotest.o sdotest.cpp; \ then mv -f .deps/sdotest.Tpo .deps/sdotest.Po; else rm -f .deps/sdotest.Tpo; exit 1; fi sdotest.cpp: In static member function `static int sdotest::conversiontest()': sdotest.cpp:1135: error: integer constant is too large for long type sdotest.cpp: In static member function `static int sdotest::maintest()': sdotest.cpp:2569: error: integer constant is too large for long type sdotest.cpp:2575: error: integer constant is too large for long type make[5]: *** [sdotest.o] Error 1 On line 1135, in the following statement: dor-setLong(long, 0x); the constant is too big for a long. Same problem on lines 2569 and 2575. I suggest adding an import limits.h and using LONG_MAX to be more portable. After fixing these 3 lines the whole SDO runtime builds nicely. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
