Re: Java SCA dependency versions listed in various pom.xmls
+1 to using dependencyManagement if its done consistently as it can get confusing if some dependencies use it and some don't. ...ant On 11/6/06, Rick [EMAIL PROTECTED] wrote: Hello, Currently there are identical artifact dependencies listed throughout the SCA Java maven hierarchy that can be changed to different versions either intentionally or accidentally. For example axis2-kernel is specified in two levels of maven pom.xml At the sca level there is dependencyManagement element that uses the axis2Version property and there is also a reference in sca/tools/pom.xml that is hard coded to SNAPSHOT. This brings about the following questions: Is this a good practice? I this weekend changed one and didn't catch the other so my opinion is no, I think until the need arises that they require to be different this should be set in one place. If we agree what's the best solution? Use maven property values to keep them in sync, or just list the version at the top level (sca/pom.xml) under the dependencyManagement? If we take the latter approach, do we list ALL external dependencies there to be consistent? If we feel this should change should we still do this for M2 release? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] was Re: [VOTE] Invite Rajith Attapattu to be a Tuscany committer
Passed with 12 +1s, welcome Rajith! ...ant On 11/3/06, ant elder [EMAIL PROTECTED] wrote: I'd like to invite Rajith Attapattu to be a Tuscany committer. He's already a committer on the Apache WS project which is our project sponsor so he already has Tuscany commit rights, this is just to officially invite him to participate . Rajith has been active in Tuscany for a while now, has submitted large patches for the JMS binding which we now have in trunk and has plans for developing that further along with other messaging things for Tuscany which is an important area, not to mention his experience from the WS project. I think he'd be great to have as a Tuscany committer. Here's my +1. ...ant
Re: [jira] Closed: (TUSCANY-753) JMS Binding
You're officially one of us now so go for it Rajith. ...ant On 11/6/06, Rajith Attapattu [EMAIL PROTECTED] wrote: Hey Jim, I have fix for the annoying file system artifact created as by product of the unit test. I was wondering when I can check it in ? Unless I hear otherwise I will probably wait till Ant nominates me formally after the vote. Regards, Rajith On 11/2/06, Rajith Attapattu [EMAIL PROTECTED] wrote: Hey Jim, Thanks for your comments and observations. Yes creating those file system artifacts are real PIA. I will talk to the ActiveMQ guys and see if there is a way to turn that off. I will probably use the in-VM stuff from ActiveMQ, but was a little to excited to test the real stuff :) Like u said we can move that stuff to the integration test suite. So I will send another patch (as time permits) which will clean up the code with better error handling, as well as use EasyMock or in-VM to run the test case. I also need to add more simple JUnit tests to cover the code base. I also need to bring this in-line with the released JMS binding spec draft. So let me do this stuff incrementally and send a series of patches. Hopefully ant will not get tired of applying my patches :) I will address the more nagging problem of creating those file system artifacts first. Regards, Rajith On 11/2/06, Jim Marino [EMAIL PROTECTED] wrote: Hi Rajith, Thanks for the patch. I had a few comments regarding test cases... Having a testcase that is run from the checkin build create file system artifacts may be problematic since it can produce side- effects. Setting svn ignores isn't going to fix this so would it be possible to avoid having to create these artifacts? I was thinking this would involve two steps: 1. Have unit tests use EasyMock to stub out JMS APIs such as Destination to test the binding at a granular level independent of a particular JMS implementation. I would imagine there would not be many of these tests as the binding is mostly a wrapper around a JMS provider. These would just be normal JUnit test cases and not extend SCATestCase. 2. Have integration tests which test interoperating the binding with ActiveMQ. Eventually, these would be run as part of the integration test suite being worked on by Jeremy. For now, they could be test cases included as part of the checkin build until the integration test harness is operational. However, couldn't these integration tests use ActiveMQ's in-VM protocol? Also, would using the in-VM protocol eliminate the need to create file system artifacts as well as have port listeners? If there is no way around creating file system artifacts, then I think we really need to segregate these tests so they are not part of the checkin build. I'm happy to help out if needed. Thanks, Jim On Nov 2, 2006, at 1:04 AM, ant elder (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ] ant elder closed TUSCANY-753. - Resolution: Fixed Applied, thanks for the code Rajith! https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ services/bindings/binding.jms/ Right now the testcases create an ActiveMQ folder in the top level binding.jms folder, it would be better if that could be done within the target folder so its excluded from the SVN artifacts. If its a major problem i guess we could just add it to svn ignores but for now I haven't added this to the main build so we can look at this. JMS Binding --- Key: TUSCANY-753 URL: http://issues.apache.org/jira/browse/TUSCANY-753 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Rajith Attapattu Assigned To: ant elder Fix For: Java-Mx Attachments: helloworldws.zip, jms-binding- JIRA_753-01-11-06.patch, jmsbinding_jira753_25sep06.patch Hi All, I have attached a patch for the JMS binding. By no means this is 100% complete. But I decided to post the source code so that others can have a look and comment on the direction and help out if there is something wrong. The unit tests are failing so I haven't attached the test code. JMS binding still has a dependency on SDO since I modeled it on the axis2 binding. However Raymond has changed that in axis2 and I am hoping to do the same soon. Please be kind enough to have a look and start a disucssion on how we can move this forward. Regards, Rajith -- 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:
[jira] Commented: (TUSCANY-897) BPEL container based on Apache Ode
[ http://issues.apache.org/jira/browse/TUSCANY-897?page=comments#action_12447741 ] Sam Tam commented on TUSCANY-897: - Hi, I am a student and have been working a little bit in Apache Tuscany and Apache Ode. Now i am starting to work in creating a BPEL container in Tuscany. I have gone through the White paper and Spec... I have discussed with both committers of Apache Ode and Apache Tuscany about this ! I will contribute my level best ...for integration of SCA and BPEL Sam...Tam.. BPEL container based on Apache Ode -- Key: TUSCANY-897 URL: http://issues.apache.org/jira/browse/TUSCANY-897 Project: Tuscany Issue Type: New Feature Components: Java SCA Common Affects Versions: Java-Mx Reporter: ant elder Fix For: Java-Mx JIRA for attaching patches to create the Tuscany BPEL container based on Apache Ode. There's a white paper on SCA and BPEL at: http://osoa.org/display/Main/Service+Component+Architecture+Specifications A draft specification is available at: http://osoa.org/display/Main/Service+Component+Architecture+Specifications The Tuscany container is at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/ -- 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: Proposed time change of weekly IRC chat to 16:30 GMT
This change is good for me. Simon Rick wrote: Hello, Our web site states our weekly IRC chats are Monday's at 15:30 GMT. It was proposed during this week's IRC chat that the time be changed to 16:30 GMT to accommodate the majority of committers to stay at the same local time. Does anyone in the community have any issues with this proposed change? Thanks. http://incubator.apache.org/tuscany/get-involved.html - 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] Created: (TUSCANY-904) Expose DAS as SCA container
Expose DAS as SCA container --- Key: TUSCANY-904 URL: http://issues.apache.org/jira/browse/TUSCANY-904 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-Mx Environment: N/A Reporter: Amita Vadhavkar This is linked to master JIRA -864 and is created to track work on developing SCA container for DAS -- 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-904) Expose DAS as SCA container
[ http://issues.apache.org/jira/browse/TUSCANY-904?page=all ] Amita Vadhavkar updated TUSCANY-904: Attachment: SCAcontainerForDAS.doc dataaccess-container-staticPlusDynamic.jar The documentation attached describes the work done for developing SCA container for DAS. Expose DAS as SCA container --- Key: TUSCANY-904 URL: http://issues.apache.org/jira/browse/TUSCANY-904 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-Mx Environment: N/A Reporter: Amita Vadhavkar Attachments: dataaccess-container-staticPlusDynamic.jar, SCAcontainerForDAS.doc This is linked to master JIRA -864 and is created to track work on developing SCA container for DAS -- 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]
Adding 2 webapp jars to binary distro
With David's help to resolve my { and ( confusion (poor eyesight
when reading the Ant manual), I have completed my ant script for
building the calculator sample and I am now making good progress
with building the helloworldws sample (a webapp, so a bit more
challenging).
I noticed that two of the jars I need to include in the war file:
webapp-1.0-incubator-M2-SNAPSHOT.jar
webapp-host-1.0-incubator-M2-SNAPSHOT.jar
are not present in the standalone launcher (the rest are). In order
to avoid the need for ant users to download these jars from a maven
repo, I'd like to propose adding them to the binary distro. For
example, they could go in a new webapp directory. They are not large
and they would not impact use of the binary distro as a standalone
Tuscany launcher.
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBC stored procedure container using DAS
Hi Luciano, I have now created https://issues.apache.org/jira/browse/TUSCANY-904 and have same attachments with proper license option selected. Thanks for pointing this out. I am not using the JIRA-876 for this work as its name is misleading. Went through the patch at JIRA-898 and could see lot of common places where we can work together or I can get your suggestions for the work items. Have a few comments for the code in JIRA-898- -update command support using DAS is a bit different than for other commands where it uses SDO and not Command. -Also, a stored procedure can have IN and OUT params, so it may be essential to supply position and value of any param (like a Map, instead of Vector) Will you please review the attachment in JIRA-904 and give me your comments? Also, would like to know what timezone you are in and what time/date will be best for you to have an IRC chat. Please let me know so we can discuss together. Also, would like to get a view from Kevin Williams. If we three can chat together, it will be really very helpful. Regards, Amita On 11/6/06, Luciano Resende [EMAIL PROTECTED] wrote: Also, I noticed your attachments does not grant ASF license to use the code, you need to check when uploading the attachments in order for us to be able to use that in Apache. - Luciano On 11/6/06, Luciano Resende [EMAIL PROTECTED] wrote: I tought you were going to use the JIRA you created for this ? - https://issues.apache.org/jira/browse/TUSCANY-876 I was planning to introduce a sample das service and a client using - https://issues.apache.org/jira/browse/TUSCANY-898 Do you want to post your patches back to Tuscany-876 ? - Luciano On 11/6/06, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi , I have attached code jar and doc today to https://issues.apache.org/jira/browse/TUSCANY-898 Here I am trying to follow the approach of implementing SCA container for DAS. Please go through same and provide feedback. Regards, Amita On 10/23/06, Amita Vadhavkar [EMAIL PROTECTED] wrote: Yes, posting the question about spec as a separate mail. I am out of town for 4-5 days for some urgent personal work. Will continue working on this after I return. Regards, Amita On 10/21/06, Luciano Resende [EMAIL PROTECTED] wrote: You could probably also post your questions about the SCA specs on this forum, as couple people here participate on the SCA spec group. - Luciano On 10/21/06, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I am working actively on the container part. Apart from that have developed a sample based on the discussion going on in thread http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg0.html . and have asked for feedback using the same thread(sample attached). In this DAS is exposed as a service with support for execute(), but can be extended.Please have a look and give feedback. Also, for reaching the spec people to find out what are the existing things for the binding support for refering to stored procedure using SCA, have asked questions in feedback on OSOA site. Is there any other way? Regards, Amita On 10/19/06, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Kevin, Yes, I did go through that discussion. As the first step, I am trying for the stored procedure implementation. But definitely the bigger goal is the complete clean integration. Have created JIRAhttps://issues.apache.org/jira/browse/TUSCANY-876 for this specific item. We can link it to the wish list JIRA http://issues.apache.org/jira/browse/TUSCANY-864. Will check with you for any specifics on DAS, as and when I come across any problems. Thank you. Amita On 10/18/06, Kevin Williams [EMAIL PROTECTED] wrote: Hello Amita, A clean integration between RDB DAS and SCA is a very important and the DAS team is ready to help. I want to make sure you have seen this discussion: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] Thanks. --Kevin Amita Vadhavkar wrote: Thanks a lot Ant. I am going through this and also have a few quesitons. There is a JIRA http://issues.apache.org/jira/browse/TUSCANY-864which is in wish list for DAS and SCA integration. Shall we use the same for any work on the current topic or have a specific JIRA for the JDBC stored procedure container using DAS. Also, The SCA assembly model spec talks about A composite reference can be used to access db stored procedure - will you
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Hi Kevin, Thanks a lot for the comments. I have posted the code and doc on JIRA-904 for the container work. Also, am most likely missing something in the database connection portion. Would like to discuss with you. Will you please provide feedback on JIRA-904 attachments? I am checking with Luciano for a convenient date/time when we can chat, would be great if you can also join. I am in IST timezone. Regards, Amita On 11/6/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Amita, This is looking good. Some comments inline: Amita Vadhavkar wrote: Hi, I am trying to create a container for DAS-SCA too (not just for stored procedure) and will be able to send a working code in ML over the weekend. Below is summary of what I got so far from the previous mail discussions and some questions. The integration between DAS and SCA can happen at application level as service or at container level. 2 different possible approaches – static – e.g. getAllCustomers dynamic – e.g. execute(all customers); For application level service – it is the sample * sample-StoredProcedureService.jar* or what Luciano is providing in more details, is an example. In *sample-StoredProcedureService.jar* example dynamic approach is followed For container approach – again static or dynamic approach can be followed. For static – it's like providing service for getAllCompanies(), getAllCustomers() etc. whereas for dynamic its like execute(command) where command can be getAllCompanies, getAllCustomers. Etc. I am working on a container implementation where dynamic approach is followed. If I understand correctly, the container approach will provide the tightest integration with SCA and make things easier for end-users. Do you agree? There are 2 places where extensibility is required – 1) for providing different data access mechanisms. i.e. today there is RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl will be same, but the exampleconfig.xml will change. In the container I am working on - Scdl has a new tag Scdl has a new tag da:implementation.da script=customersOrders/CustomersOrders.xml dataAccessType=rdb/ Here, dataAccessType – is the key which tells whether it's RDB or something else. And the xml script provides the connection and data store details. 2) for RDB-DAS – providing support for different databases (this portion should be part of DAS and not SCA.) In the current container I am working on it is provided as a package - org.apache.tuscany.container.dataaccessshelper package - which should finally go into DAS codeline(?). Currently, there are two ways to specify a particular database: first, the user can pass a JDBC Connection to the DAS Factory when creating a DAS instance. The second is that a DataSource can be specified in the DAS Config xml file in which case the DAS is responsible for getting the connection. For static approach we may need some code generation tooling. Right. That is why I think it best to start with dynamic. But, we will want static support as well. Also could not understand how this can be merged into RESTful interfaces. (this was mentioned in some mail conversation) Regards, Amita On 10/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Luciano Resende wrote: Comments in-line... On 10/25/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote: Hi, I would also like to understand this a little better ... here I am thinking aloud and hope the others will help in getting my persceptions right... I guess firstly it is a question of how or where we want to position 'DAS Integration' in SCA. Is is something we want to integrate as the Application Layer, which I understand is what Amita is trying presently and which Jim refers to as component implementation. In this option we get to do some sort of a service wrapper to DAS and then it becomes a demonstration of two Tuscany subprojects integrating at application level. Yes, I think we have space to position DAS both ways, and integrating in the application layer by exposing DAS as a service would be a very easy and quick, this could be exposed as a sample app, and could show we are working on getting a better integration between DAS and SCA Or do we want to position DAS at the infrastructure layer as another extension type (either container or binding). I guess this is where Ant started this - proposing a JDBC container / binding for component implementation in StoredProcedures. I was thinking a DAS was a way to declaratively model heterogeneous data as a service and offer a mechanism for remoting that data. In other words, it provided the ability for an application to perform CRUD using a high-level contract (interface) and having those operations take place across
querying when patches are available for jiras
I notice from the filters link from the jira browse page (i.e. http://issues.apache.org/jira/secure/popups/savedfilters.jsp) that projects such as Derby and Geronimo are able to search on whether a patch is pending. This seems to be possible because their search editing panel has a custom field Patch Available. It would be really helpful if we could switch this behaviour on for Tuscany. Anyone know how to do that? Regards, Kelvin.
Re: A front-page for tuscany-java-sca downloads
Hi Raymond, Looks good. Just one trivial comment. There's a typo in the path of 7): calulator. Thanks for this On 11/6/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I put together a simple front-page for tuscany-java-sca M2 candidate downloads @ http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. Please review and provide feedback to us. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required?
Re: [SDO for C++] Making the definition of types more user friendly
Sorry for the delay, I was waiting to get M2 out of the way. Patch works and has been applied. Cheers, On 30/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Various people have complained about the fact that the process for defining types (metadata) in SDO for C++ locks the type system as soon as the first data object is created. I've submitted a patch under JIRA 546 that relaxes that restriction a fair bit. With the patch in place, you can now create new types whenevr you wish and every time a data object is created any types added since the last data object was created are merged into the type system. However, once a type is resolved in this way it becomes read-only (as it was before the patch). I've done a small amount of testing to show that existing functionality isn't broken, however, I'd be interested in some feedback on a) whether this works adn b) whether it is useful. Short answers: b) YES a) I'll let you know when I've tested it ;-) Cheers, -- Pete -- Pete
Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?
Hi, Has anyone out there had any sucess building inside eclipse using the subversion (http://subclipse.tigris.org/) and maven2 ( http://m2eclipse.codehaus.org/) plug-ins ? I'd like to be able to sync and build without stepping into command line mode... but this looks like wishful thinking. Despite various attempts I can't seem to get the combination to work - hoping to be able to work with Tuscany solely from within the cosey confines of eclipse, but can't seem to get it to work :( I'll append a second post of the failures I currently seeing to see if they make sense to anyone. If someone else has and/or can help me get it working then I'd be happy to write it up with screenshots etc so other can benefit (unless I'm the only one with this aspiration). Many thanks in advance Dan
Re: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?
On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Has anyone out there had any sucess building inside eclipse using the subversion (http://subclipse.tigris.org/) and maven2 ( http://m2eclipse.codehaus.org/) plug-ins ? I'd like to be able to sync and build without stepping into command line mode... but this looks like wishful thinking. Despite various attempts I can't seem to get the combination to work - hoping to be able to work with Tuscany solely from within the cosey confines of eclipse, but can't seem to get it to work :( I'll append a second post of the failures I currently seeing to see if they make sense to anyone. If someone else has and/or can help me get it working then I'd be happy to write it up with screenshots etc so other can benefit (unless I'm the only one with this aspiration). Many thanks in advance Dan I use eclipse 3.2 with the tigris svn plugin. I still check the code out of svn initially with command line SVN and build it, then run mvn -Peclipse eclipse:eclipse and import those projects into eclipse with file - import - General - import existing projects. From the on you can use team - sync to get updates and commit changes all within eclipse. Often still easier to use the command like SVN for somethings. ...ant
Re: Java SCA dependency versions listed in various pom.xmls
If we take the latter approach, do we list ALL external dependencies there to be consistent? I don't think we should list all dependencies there for a couple of reasons: 1. We need to be modular in the extensions and I'm concerned that by doing this we will wind up with a large list of dependencies in one location that cannot be managed easily (i.e. every time an extension changes, we need to modify the master pom) 2. We will likely run into issues when two or more extensions require different versions of the same dependency. How would we handle these cases under this approach? Jim If we feel this should change should we still do this for M2 release? - 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: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?
Hi Ant, one Q... if you svn outside eclipse what do you do to get team sync working in eclipse ? sounds like a good compromise, though would still prefer to work purely in eclipse - I'll do this if no-one else can help with my q Thanks, Dan On 07/11/06, ant elder [EMAIL PROTECTED] wrote: On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Has anyone out there had any sucess building inside eclipse using the subversion (http://subclipse.tigris.org/) and maven2 ( http://m2eclipse.codehaus.org/) plug-ins ? I'd like to be able to sync and build without stepping into command line mode... but this looks like wishful thinking. Despite various attempts I can't seem to get the combination to work - hoping to be able to work with Tuscany solely from within the cosey confines of eclipse, but can't seem to get it to work :( I'll append a second post of the failures I currently seeing to see if they make sense to anyone. If someone else has and/or can help me get it working then I'd be happy to write it up with screenshots etc so other can benefit (unless I'm the only one with this aspiration). Many thanks in advance Dan I use eclipse 3.2 with the tigris svn plugin. I still check the code out of svn initially with command line SVN and build it, then run mvn -Peclipse eclipse:eclipse and import those projects into eclipse with file - import - General - import existing projects. From the on you can use team - sync to get updates and commit changes all within eclipse. Often still easier to use the command like SVN for somethings. ...ant
Re: Adding 2 webapp jars to binary distro
On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SCA dependency versions listed in various pom.xmls
You can override that in a specific module (pom.xml) by explicitly having a specific version in your dependency. In general I like a place where we see all the dependencies. As a practice when we override in lower pom.xmls we could comment that we've done this. My gut feel is overriding at lower levels would be the rare exception and not the rule. Jim Marino wrote: If we take the latter approach, do we list ALL external dependencies there to be consistent? I don't think we should list all dependencies there for a couple of reasons: 1. We need to be modular in the extensions and I'm concerned that by doing this we will wind up with a large list of dependencies in one location that cannot be managed easily (i.e. every time an extension changes, we need to modify the master pom) 2. We will likely run into issues when two or more extensions require different versions of the same dependency. How would we handle these cases under this approach? Jim If we feel this should change should we still do this for M2 release? - 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: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?
You don't have to do anything, it just works as the eclipse svn plugin uses the same .svn info as the command line one. If you really don't want to use the command line at all you should be able to checkout the tuscany code from the svn repo from the eclipse svn repository exploring perspective, not sure how well setting up all the classpaths will work though as i've not tried that approach. ...ant On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi Ant, one Q... if you svn outside eclipse what do you do to get team sync working in eclipse ? sounds like a good compromise, though would still prefer to work purely in eclipse - I'll do this if no-one else can help with my q Thanks, Dan On 07/11/06, ant elder [EMAIL PROTECTED] wrote: On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Has anyone out there had any sucess building inside eclipse using the subversion (http://subclipse.tigris.org/) and maven2 ( http://m2eclipse.codehaus.org/) plug-ins ? I'd like to be able to sync and build without stepping into command line mode... but this looks like wishful thinking. Despite various attempts I can't seem to get the combination to work - hoping to be able to work with Tuscany solely from within the cosey confines of eclipse, but can't seem to get it to work :( I'll append a second post of the failures I currently seeing to see if they make sense to anyone. If someone else has and/or can help me get it working then I'd be happy to write it up with screenshots etc so other can benefit (unless I'm the only one with this aspiration). Many thanks in advance Dan I use eclipse 3.2 with the tigris svn plugin. I still check the code out of svn initially with command line SVN and build it, then run mvn -Peclipse eclipse:eclipse and import those projects into eclipse with file - import - General - import existing projects. From the on you can use team - sync to get updates and commit changes all within eclipse. Often still easier to use the command like SVN for somethings. ...ant
Re: Java SCA dependency versions listed in various pom.xmls
For shared dependencies this makes sense. However, I don't think this should be the case for non-shared dependencies. For example, if only my Foo extension depends on Bar, Bar should be called out in Foo's pom, not higher up. Jim On Nov 7, 2006, at 7:31 AM, Rick wrote: You can override that in a specific module (pom.xml) by explicitly having a specific version in your dependency. In general I like a place where we see all the dependencies. As a practice when we override in lower pom.xmls we could comment that we've done this. My gut feel is overriding at lower levels would be the rare exception and not the rule. Jim Marino wrote: If we take the latter approach, do we list ALL external dependencies there to be consistent? I don't think we should list all dependencies there for a couple of reasons: 1. We need to be modular in the extensions and I'm concerned that by doing this we will wind up with a large list of dependencies in one location that cannot be managed easily (i.e. every time an extension changes, we need to modify the master pom) 2. We will likely run into issues when two or more extensions require different versions of the same dependency. How would we handle these cases under this approach? Jim If we feel this should change should we still do this for M2 release? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release
[ http://issues.apache.org/jira/browse/TUSCANY-902?page=comments#action_12447833 ] Kelvin Goodson commented on TUSCANY-902: http://issues.apache.org/jira/browse/TUSCANY-886 contains a patch for the equivalent problem in the DAS distributions release distributions should have common root folder naming the release --- Key: TUSCANY-902 URL: http://issues.apache.org/jira/browse/TUSCANY-902 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson Priority: Minor The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that it would be better if all distributions relating to a given release contained all their filles in a commonly named root folder. -- 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: Adding 2 webapp jars to binary distro
I understand why the jars are there Jim, actually the servlet one is due to the current design of the axis binding not the kernel ServletHost, and I think we all understand that ultimately a kitchen sink distro isn't going to work, but thats _ultimately_, right now today in M2 we don't have JAXB and JPA and JMS and all the other things you mention, and we also don't have the things to help that you mention completed yet such as the maven artifact repository stuff or multi-parent classloader support. Given that, for this M2 release it may be easiest to just include the webapp jars as we have already done with the other ones. What is an alternative solution that you're suggesting? ...ant On 11/7/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
On Nov 7, 2006, at 8:03 AM, ant elder wrote: I understand why the jars are there Jim, actually the servlet one is due to the current design of the axis binding not the kernel ServletHost, ServletHost is also referenced by other extensions as it is assumed to be part of the host spi so it's not just Axis. and I think we all understand that ultimately a kitchen sink distro isn't going to work, but thats _ultimately_, right now today in M2 we don't have JAXB and JPA and JMS and all the other things you mention, and we also don't have the things to help that you mention completed yet such as the maven artifact repository stuff or multi-parent classloader support. That's not the point. One of the primary goals of this release was modularity. This breaks that. Given that, for this M2 release it may be easiest to just include the webapp jars as we have already done with the other ones. What is an alternative solution that you're suggesting? Use Maven or the artifact repository Meraaj and Jeremy worked on. Jim ...ant On 11/7/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...- bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - 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: Java SCA dependency versions listed in various pom.xmls
Hi, I guess we will anyways do what Jim is mentioning here i.e. only have the shared dependencies up in the dependencymanagement. For example in the case of sca-tools I would check if any of the required depedencies and versions have already been mentioned in the dependencyManagement - if they match then I leave it at that otherwise I specify explicitly in the sca-tools pom. - Venkat On 11/7/06, Jim Marino [EMAIL PROTECTED] wrote: For shared dependencies this makes sense. However, I don't think this should be the case for non-shared dependencies. For example, if only my Foo extension depends on Bar, Bar should be called out in Foo's pom, not higher up. Jim On Nov 7, 2006, at 7:31 AM, Rick wrote: You can override that in a specific module (pom.xml) by explicitly having a specific version in your dependency. In general I like a place where we see all the dependencies. As a practice when we override in lower pom.xmls we could comment that we've done this. My gut feel is overriding at lower levels would be the rare exception and not the rule. Jim Marino wrote: If we take the latter approach, do we list ALL external dependencies there to be consistent? I don't think we should list all dependencies there for a couple of reasons: 1. We need to be modular in the extensions and I'm concerned that by doing this we will wind up with a large list of dependencies in one location that cannot be managed easily (i.e. every time an extension changes, we need to modify the master pom) 2. We will likely run into issues when two or more extensions require different versions of the same dependency. How would we handle these cases under this approach? Jim If we feel this should change should we still do this for M2 release? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SCA dependency versions listed in various pom.xmls
On Nov 7, 2006, at 8:35 AM, Venkata Krishnan wrote: Hi, I guess we will anyways do what Jim is mentioning here i.e. only have the shared dependencies up in the dependencymanagement. For example in the case of sca-tools I would check if any of the required depedencies and versions have already been mentioned in the dependencyManagement - if they match then I leave it at that otherwise I specify explicitly in the sca-tools pom. That sounds right. Raymond, does this mesh with your understanding? Jim - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?
Hi, I too use a mix of Eclipse plug in and SVN. Initially, I checked out the source using command line SVN and after building the eclipse projects using commandline mavein (as Ant has described) I import the projects into eclipse. From then on all of SVN interactions - update, commit, patch creation etc. works from within eclipse. Some time back I did try checkout from within eclipse itself, it did work but then you must have to create and set up the eclipse projects alongside ( not sure if this has changed now) the check out and was very cumbersome. In do all maven builds from the command line. - Venkat On 11/7/06, ant elder [EMAIL PROTECTED] wrote: You don't have to do anything, it just works as the eclipse svn plugin uses the same .svn info as the command line one. If you really don't want to use the command line at all you should be able to checkout the tuscany code from the svn repo from the eclipse svn repository exploring perspective, not sure how well setting up all the classpaths will work though as i've not tried that approach. ...ant On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi Ant, one Q... if you svn outside eclipse what do you do to get team sync working in eclipse ? sounds like a good compromise, though would still prefer to work purely in eclipse - I'll do this if no-one else can help with my q Thanks, Dan On 07/11/06, ant elder [EMAIL PROTECTED] wrote: On 11/7/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Has anyone out there had any sucess building inside eclipse using the subversion (http://subclipse.tigris.org/) and maven2 ( http://m2eclipse.codehaus.org/) plug-ins ? I'd like to be able to sync and build without stepping into command line mode... but this looks like wishful thinking. Despite various attempts I can't seem to get the combination to work - hoping to be able to work with Tuscany solely from within the cosey confines of eclipse, but can't seem to get it to work :( I'll append a second post of the failures I currently seeing to see if they make sense to anyone. If someone else has and/or can help me get it working then I'd be happy to write it up with screenshots etc so other can benefit (unless I'm the only one with this aspiration). Many thanks in advance Dan I use eclipse 3.2 with the tigris svn plugin. I still check the code out of svn initially with command line SVN and build it, then run mvn -Peclipse eclipse:eclipse and import those projects into eclipse with file - import - General - import existing projects. From the on you can use team - sync to get updates and commit changes all within eclipse. Often still easier to use the command like SVN for somethings. ...ant
Fwd: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release
Hi Kelvin In DAS, I created the patch to make DAS distributions to be unpacked in a specific subdirectory relative from the current directory (e.g tuscany-das-1.0-incubator-M2-src). From the subject of this JIRA, I got little confused, are you saying all tuscany sub-projects should have same root directory (e.g das, sdo, sca) ? or are you saying all distributions from a given sub-project should have same root (e.g bin, src, sample) ? I think both are not tru for what I did for DAS as source would go to tuscany-das-1.0-incubator-M2-src and binary distribution would go to tuscany-das-1.0-incubator-M2-bin for example... BTW, I tried to follow the convention being used by Axis. - Luciano Resende -- Forwarded message -- From: Kelvin Goodson (JIRA) tuscany-dev@ws.apache.org Date: Nov 7, 2006 7:46 AM Subject: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release To: tuscany-dev@ws.apache.org [ http://issues.apache.org/jira/browse/TUSCANY-902?page=comments#action_12447833] Kelvin Goodson commented on TUSCANY-902: http://issues.apache.org/jira/browse/TUSCANY-886 contains a patch for the equivalent problem in the DAS distributions release distributions should have common root folder naming the release --- Key: TUSCANY-902 URL: http://issues.apache.org/jira/browse/TUSCANY-902 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson Priority: Minor The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.htmlidentified that it would be better if all distributions relating to a given release contained all their filles in a commonly named root folder. -- 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] Closed: (TUSCANY-876) JDBC Stored proceduce container using DAS
[ http://issues.apache.org/jira/browse/TUSCANY-876?page=all ] Luciano Resende closed TUSCANY-876. --- Resolution: Duplicate Duplicate of Tuscany-904 JDBC Stored proceduce container using DAS - Key: TUSCANY-876 URL: http://issues.apache.org/jira/browse/TUSCANY-876 Project: Tuscany Issue Type: New Feature Affects Versions: Java-Mx Reporter: Amita Vadhavkar http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09892.html So, initially this JIRA will be used to implement for stored procedure feature and later can be linked to the generic JIRA http://issues.apache.org/jira/browse/TUSCANY-864 for the entire integration -- 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: Adding 2 webapp jars to binary distro
I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer
Re: [jira] Closed: (TUSCANY-876) JDBC Stored proceduce container using DAS
This wasn't a really a duplicate was it, isn't a JDBC stored procedure binding/container slightly different from whats been talked about for the DAS and SCA integration? ...ant On 11/7/06, Luciano Resende (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-876?page=all ] Luciano Resende closed TUSCANY-876. --- Resolution: Duplicate Duplicate of Tuscany-904 JDBC Stored proceduce container using DAS - Key: TUSCANY-876 URL: http://issues.apache.org/jira/browse/TUSCANY-876 Project: Tuscany Issue Type: New Feature Affects Versions: Java-Mx Reporter: Amita Vadhavkar http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09892.html So, initially this JIRA will be used to implement for stored procedure feature and later can be linked to the generic JIRA http://issues.apache.org/jira/browse/TUSCANY-864 for the entire integration -- 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: A front-page for tuscany-java-sca downloads
Hi Raymond, Just a couple of very minor observations. 1) In the last step, when excuting the sample you have mentioned c:. It would be good if you can mention in the first step as ... Create a local directory such as c:\tuscany.m2. Also wherever you refer to tuscany.m2 you may prefix the drive as well, just for consistency. 2) How about If you have been able to successfuly setup and run this sample then you must be able to see the following instead of The sample runs successfully when you see the following output: Thanks - Venkat On 11/7/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I put together a simple front-page for tuscany-java-sca M2 candidate downloads @ http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/ http://people.apache.org/%7Erfeng/tuscany/incubator-M2/downloads/. Please review and provide feedback to us. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-876) JDBC Stored proceduce container using DAS
Yes, I too would imagine so. I would imagine that this is something that can be done with just JDBC - nothing to relate with DAS as such. Is that right? - Venkat On 11/7/06, ant elder [EMAIL PROTECTED] wrote: This wasn't a really a duplicate was it, isn't a JDBC stored procedure binding/container slightly different from whats been talked about for the DAS and SCA integration? ...ant On 11/7/06, Luciano Resende (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-876?page=all ] Luciano Resende closed TUSCANY-876. --- Resolution: Duplicate Duplicate of Tuscany-904 JDBC Stored proceduce container using DAS - Key: TUSCANY-876 URL: http://issues.apache.org/jira/browse/TUSCANY-876 Project: Tuscany Issue Type: New Feature Affects Versions: Java-Mx Reporter: Amita Vadhavkar http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09892.html So, initially this JIRA will be used to implement for stored procedure feature and later can be linked to the generic JIRA http://issues.apache.org/jira/browse/TUSCANY-864 for the entire integration -- 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: [jira] Closed: (TUSCANY-876) JDBC Stored proceduce container using DAS
Maybe I have misunderstood, and tought Amita said she was doing something little more generic and would work not only for Stored Procedures, that's why she created a new JIRA... If this is not the case I could re-open the JIRA - Luciano On 11/7/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes, I too would imagine so. I would imagine that this is something that can be done with just JDBC - nothing to relate with DAS as such. Is that right? - Venkat On 11/7/06, ant elder [EMAIL PROTECTED] wrote: This wasn't a really a duplicate was it, isn't a JDBC stored procedure binding/container slightly different from whats been talked about for the DAS and SCA integration? ...ant On 11/7/06, Luciano Resende (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-876?page=all ] Luciano Resende closed TUSCANY-876. --- Resolution: Duplicate Duplicate of Tuscany-904 JDBC Stored proceduce container using DAS - Key: TUSCANY-876 URL: http://issues.apache.org/jira/browse/TUSCANY-876 Project: Tuscany Issue Type: New Feature Affects Versions: Java-Mx Reporter: Amita Vadhavkar http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09892.html So, initially this JIRA will be used to implement for stored procedure feature and later can be linked to the generic JIRA http://issues.apache.org/jira/browse/TUSCANY-864 for the entire integration -- 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: Adding 2 webapp jars to binary distro
I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they
Re: Updating the website
I think this has been fixed. cd /www/incubator.apache.org/tuscany/ svn update At revision 472177. http://issues.apache.org/jira/browse/INFRA-1017 Andrew Borley wrote: Thanks for sorting this out Rick. The odd thing is that I used to have the correct privileges to do this - something must have gone wrong when minotaur was reinstated. Cheers Andy On 11/6/06, cr22rc [EMAIL PROTECTED] wrote: I don't think it really has anything to do with svn. I think this is simply a unix permission issue as I've reported before. I have done everything I can think of. I've opened a jira, I've popped on the IRC chat and was politely told to work through our project mentors. I've sent them now two notes. From my understanding this takes someone that has root privileges on minotaur about 5 minutes of work, if that. Andrew Borley wrote: OK, it appears this is because I've somehow been dropped off a group, or I'm in the wrong group on people.apache.org - doing id -Gn on minotaur lists me as belonging to ajborley, apcvs and ws groups. Doing id -Gn pgrobbins (or jboynes, jmarino, etc) gives pgrobbins, apcvs and incubator groups which means that some people can update the site but not others (including kelvingoodson, antelder and rfeng). I expect this has something to do with svn permissions - as a tuscany committer I get svn access to all the ws projects so I'm in the svn ws group. Does anyone know how I can get put back in the incubators group? Cheers Andy On 11/3/06, cr22rc [EMAIL PROTECTED] wrote: Just to keep you up to date, I was informed I should work this through our project mentors. To which I've sent a note off to Sam Ruby and Davanum Srinivas. Rick wrote: Hello I opened a Jira on this http://issues.apache.org/jira/browse/INFRA-1017 and I went to the apache infrastructure (asfinfra) irc channel and left a message and a pointer to the Jira. I don't know if this is the right way to go about this, but figure at worst I'll get my hand slapped :-) Andrew Borley wrote: Hi, I'm trying to update the website with some C++ M2 information via the following process: log into people.apache.org cd /www/incubator.apache.org/tuscany svn update But I'm getting an svn failure:Can't open file '.svn/lock': Permission denied. It looks like all the files in /www/incubator.apache.org/tuscany/.svn are read-only after the reinstatement of minotaur I don't have access rights to do a chmod on them. svn cleanup produces the same error. Can anyone in Tuscany get this to work? Or should we go to the infrastructure folks? And how do I go about contacting them? Cheers! Andy - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SCA dependency versions listed in various pom.xmls
On 11/6/06, Rick [EMAIL PROTECTED] wrote: Hello, Currently there are identical artifact dependencies listed throughout the SCA Java maven hierarchy that can be changed to different versions either intentionally or accidentally. For example axis2-kernel is specified in two levels of maven pom.xml At the sca level there is dependencyManagement element that uses the axis2Version property and there is also a reference in sca/tools/pom.xml that is hard coded to SNAPSHOT. This brings about the following questions: Is this a good practice? I this weekend changed one and didn't catch the other so my opinion is no, I think until the need arises that they require to be different this should be set in one place. If we agree what's the best solution? Use maven property values to keep them in sync, or just list the version at the top level (sca/pom.xml) under the dependencyManagement? If we take the latter approach, do we list ALL external dependencies there to be consistent? If we feel this should change should we still do this for M2 release? I have tried to use dependencyManagement where practical but Axis provides a different challenge in that there are many Axis artifacts that all need to be at the same version level. For that, I used a property to define the common version and then attempted to reference that everywhere rather than restate; this would apply to dependency elements in both dependencyManagement and dependencies sections. I do not think we should list ALL external dependencies in a single dependencyManagement section as that couples all modules to that parent pom through the version information it contains. If modules are independent, then they should each list their dependencies to avoid that coupling; if they are not independent then we should organize the tree (and the release packaging) to reflect that coupling. Venkat's approach to that sounds reasonable. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed time change of weekly IRC chat to 16:30 GMT
+1 On 11/6/06, Rick [EMAIL PROTECTED] wrote: Hello, Our web site states our weekly IRC chats are Monday's at 15:30 GMT. It was proposed during this week's IRC chat that the time be changed to 16:30 GMT to accommodate the majority of committers to stay at the same local time. Does anyone in the community have any issues with this proposed change? Thanks. http://incubator.apache.org/tuscany/get-involved.html - 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: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release
Luciano, my comments in the Jira were intended to be scoped by the component that it was raised under, i.e. Java SDO Implementation, so my plan is to do pretty much equivalent to what you have done for das with sdo. I just added a pointer to your Jira, as you seem to have found the maven incantations quicker than I. Cheers, Kelvin. On 07/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Kelvin In DAS, I created the patch to make DAS distributions to be unpacked in a specific subdirectory relative from the current directory (e.g tuscany-das-1.0-incubator-M2-src). From the subject of this JIRA, I got little confused, are you saying all tuscany sub-projects should have same root directory (e.g das, sdo, sca) ? or are you saying all distributions from a given sub-project should have same root (e.g bin, src, sample) ? I think both are not tru for what I did for DAS as source would go to tuscany-das-1.0-incubator-M2-src and binary distribution would go to tuscany-das-1.0-incubator-M2-bin for example... BTW, I tried to follow the convention being used by Axis. - Luciano Resende -- Forwarded message -- From: Kelvin Goodson (JIRA) tuscany-dev@ws.apache.org Date: Nov 7, 2006 7:46 AM Subject: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release To: tuscany-dev@ws.apache.org [ http://issues.apache.org/jira/browse/TUSCANY-902?page=comments#action_12447833 ] Kelvin Goodson commented on TUSCANY-902: http://issues.apache.org/jira/browse/TUSCANY-886 contains a patch for the equivalent problem in the DAS distributions release distributions should have common root folder naming the release --- Key: TUSCANY-902 URL: http://issues.apache.org/jira/browse/TUSCANY-902 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson Priority: Minor The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.htmlidentified that it would be better if all distributions relating to a given release contained all their filles in a commonly named root folder. -- 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: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release
Thanks for the clarification. On 11/7/06, kelvin goodson [EMAIL PROTECTED] wrote: Luciano, my comments in the Jira were intended to be scoped by the component that it was raised under, i.e. Java SDO Implementation, so my plan is to do pretty much equivalent to what you have done for das with sdo. I just added a pointer to your Jira, as you seem to have found the maven incantations quicker than I. Cheers, Kelvin. On 07/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Kelvin In DAS, I created the patch to make DAS distributions to be unpacked in a specific subdirectory relative from the current directory (e.g tuscany-das-1.0-incubator-M2-src). From the subject of this JIRA, I got little confused, are you saying all tuscany sub-projects should have same root directory (e.g das, sdo, sca) ? or are you saying all distributions from a given sub-project should have same root (e.g bin, src, sample) ? I think both are not tru for what I did for DAS as source would go to tuscany-das-1.0-incubator-M2-src and binary distribution would go to tuscany-das-1.0-incubator-M2-bin for example... BTW, I tried to follow the convention being used by Axis. - Luciano Resende -- Forwarded message -- From: Kelvin Goodson (JIRA) tuscany-dev@ws.apache.org Date: Nov 7, 2006 7:46 AM Subject: [jira] Commented: (TUSCANY-902) release distributions should have common root folder naming the release To: tuscany-dev@ws.apache.org [ http://issues.apache.org/jira/browse/TUSCANY-902?page=comments#action_12447833 ] Kelvin Goodson commented on TUSCANY-902: http://issues.apache.org/jira/browse/TUSCANY-886 contains a patch for the equivalent problem in the DAS distributions release distributions should have common root folder naming the release --- Key: TUSCANY-902 URL: http://issues.apache.org/jira/browse/TUSCANY-902 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson Priority: Minor The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.htmlidentified that it would be better if all distributions relating to a given release contained all their filles in a commonly named root folder. -- 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: Java SCA dependency versions listed in various pom.xmls
Ok, so all we need to do is remove the specific version being listed in the tooling pom.xml since that should be sync with the Axis binding we're shipping. Jeremy Boynes wrote: On 11/6/06, Rick [EMAIL PROTECTED] wrote: Hello, Currently there are identical artifact dependencies listed throughout the SCA Java maven hierarchy that can be changed to different versions either intentionally or accidentally. For example axis2-kernel is specified in two levels of maven pom.xml At the sca level there is dependencyManagement element that uses the axis2Version property and there is also a reference in sca/tools/pom.xml that is hard coded to SNAPSHOT. This brings about the following questions: Is this a good practice? I this weekend changed one and didn't catch the other so my opinion is no, I think until the need arises that they require to be different this should be set in one place. If we agree what's the best solution? Use maven property values to keep them in sync, or just list the version at the top level (sca/pom.xml) under the dependencyManagement? If we take the latter approach, do we list ALL external dependencies there to be consistent? If we feel this should change should we still do this for M2 release? I have tried to use dependencyManagement where practical but Axis provides a different challenge in that there are many Axis artifacts that all need to be at the same version level. For that, I used a property to define the common version and then attempted to reference that everywhere rather than restate; this would apply to dependency elements in both dependencyManagement and dependencies sections. I do not think we should list ALL external dependencies in a single dependencyManagement section as that couples all modules to that parent pom through the version information it contains. If modules are independent, then they should each list their dependencies to avoid that coupling; if they are not independent then we should organize the tree (and the release packaging) to reflect that coupling. Venkat's approach to that sounds reasonable. -- 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: Adding 2 webapp jars to binary distro
Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library Wouldn't if we added javadoc, SDOgen, Java2WSDL, WSDL2Java, War Plugin commandline to this be essentially a Tuscany SDK? distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not,
Re: Adding 2 webapp jars to binary distro
Jeremy, Thanks for the quick response. I am trying to be pragmatic here and deal with simple use cases. I haven't yet worked out the best way to deal with external or transitive dependencies from an ant build environment (though I do have some thoughts), but having a complete story for this is not needed to build a simple webapp. Adding these 2 jars would be a simple change that would make the first use encounter with Tuscany quite a bit easier for ant users. I am not proposing a library with extension dependencies like the ones you mentioned (either direct or transitive). I think there are a lot of issues with this, mainly because these dependencies are not part of Tuscany but are part of other projects. The 2 webapp jars are part of Tuscany and would be included in the Tuscany binary distro as a convenience to Tuscany users. IDE-specific packages are something we might get to in the future. I am not trying to be anything like that ambitious at the moment. Yes, we could insist that all Tuscany application developers build with maven. I don't think that would be a wise approach if we want to build a broad-based community. At least there should be some level of support for other build environments, or enough indication of what is going on under the maven covers that people can create other build setups themselves if they want to. Simple ant scripts can serve as this kind of documentation. You're right that a war doesn't need the standalone distribution to be present in order to run. Having a way to use our binary distribution in library mode, at least for the Tuscany artifacts that it contains, seems attractive to me if the cost is only adding 2 small jars. I'm quite a newbie with ant so I don't think my war building script in its current form provides the slickest possible approach. I'd be happy to make it available so that people can look at it and perhaps suggest improvements. It currently takes quite a literal approach to recreating the exact same directory and file structure as the maven build produces. I'll create a JIRA and attach the 2 scripts I have created so far (standalone and war). Simon Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet
RE: Proposed time change of weekly IRC chat to 16:30 GMT
+1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Boynes Sent: 07 November 2006 18:06 To: tuscany-dev@ws.apache.org Subject: Re: Proposed time change of weekly IRC chat to 16:30 GMT +1 On 11/6/06, Rick [EMAIL PROTECTED] wrote: Hello, Our web site states our weekly IRC chats are Monday's at 15:30 GMT. It was proposed during this week's IRC chat that the time be changed to 16:30 GMT to accommodate the majority of committers to stay at the same local time. Does anyone in the community have any issues with this proposed change? Thanks. http://incubator.apache.org/tuscany/get-involved.html - 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] This message has been checked for all email viruses by MessageLabs * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Hello Amita,
This looks promising. I notice your test case uses explicit updates and
inserts. While this is supported by the DAS it is not the preferred
usage which is to allow the RDB DAS to generate the CUD statements from
the SDO change history. Could you modify the example to read a data
graph and then post the changes back via applyChanges? Maybe the
equivalent of this simple test from the DAS test suite:
public void testReadModifyApply4() throws Exception {
DAS das = DAS.FACTORY.createDAS(getConfig(CustomerConfig.xml),
getConnection());
// Read customer with particular ID
Command select = das.getCommand(getCustomer);
select.setParameter(1, 1);
DataObject root = select.executeQuery();
DataObject customer = (DataObject) root.get(CUSTOMER[1]);
// Modify customer
customer.set(LASTNAME, Pavick);
das.applyChanges(root);
// Verify the change
root = select.executeQuery();
assertEquals(Pavick,
root.getDataObject(CUSTOMER[1]).getString(LASTNAME));
}
Also, this service interface seems difficult to work with since command
identifiers and argument values are encoded in the params Vector
public interface CustomersOrdersService {
void execute(Vector params);
DataObject executeQuery(Vector params);
void applyChanges(Vector params);
DataObject executeAdhoc(Vector params);//adhoc query implementation
DataObject getAllCustomers(Vector paramsList);
}
Do you think it possible to implement something like the following
interface:
public interface DynamicRDBDASService {
DataObject execute(String commandName, List params);
DataObject executeAdHoc(String queryString, List params);
void applyChanges();
}
The name is kind of long (suggestions welcome) but, I think this
interface could be generic and set of available commands is driven by
the provided DAS config file. I am not sure how we might support SP OUT
parameters but we can think about that later.
I does seem like you and Luciano should team up on this.
Thanks!
--
Kevin
Amita Vadhavkar wrote:
Hi Kevin,
Thanks a lot for the comments. I have posted the code and doc on JIRA-904
for the container work. Also, am most likely missing something in the
database
connection portion. Would like to discuss with you.
Will you please provide feedback on JIRA-904 attachments?
I am checking with Luciano for a convenient date/time when we can chat,
would
be great if you can also join. I am in IST timezone.
Regards,
Amita
On 11/6/06, Kevin Williams [EMAIL PROTECTED] wrote:
Hi Amita,
This is looking good. Some comments inline:
Amita Vadhavkar wrote:
Hi,
I am trying to create a container for DAS-SCA too (not just for stored
procedure) and will be able to send a working code in ML over the
weekend.
Below is summary of what I got so far from the previous mail
discussions and
some questions.
The integration between DAS and SCA can happen at application level as
service or at container level.
2 different possible approaches –
static – e.g. getAllCustomers
dynamic – e.g. execute(all customers);
For application level service – it is the sample *
sample-StoredProcedureService.jar* or what Luciano is providing in
more
details, is an example. In *sample-StoredProcedureService.jar*
example
dynamic approach is followed
For container approach – again static or dynamic approach can be
followed.
For static – it's like providing service for getAllCompanies(),
getAllCustomers() etc. whereas for dynamic its like execute(command)
where
command can be getAllCompanies, getAllCustomers. Etc.
I am working on a container implementation where dynamic
approach is followed.
If I understand correctly, the container approach will provide the
tightest integration with SCA and make things easier for end-users. Do
you agree?
There are 2 places where extensibility is required –
1) for providing different data access mechanisms. i.e. today
there is
RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
scdl will
be same, but the exampleconfig.xml will change.
In the container I am working on - Scdl has a new tag
Scdl has a new tag
da:implementation.da script=customersOrders/CustomersOrders.xml
dataAccessType=rdb/
Here, dataAccessType – is the key which tells whether it's RDB or
something
else. And the xml script provides the connection and data store
details.
2) for RDB-DAS – providing support for different databases (this
portion should be part of DAS and not SCA.) In the current container
I am
working on it is provided as a package -
org.apache.tuscany.container.dataaccessshelper package - which should
finally go into DAS codeline(?).
Currently, there are two ways to specify a particular database: first,
the user can pass a JDBC Connection to the DAS Factory when creating a
DAS
[jira] Resolved: (TUSCANY-718) make -noEMF code generation the default
[ http://issues.apache.org/jira/browse/TUSCANY-718?page=all ] Frank Budinsky resolved TUSCANY-718. Resolution: Fixed Committed revision 472217. make -noEMF code generation the default --- Key: TUSCANY-718 URL: http://issues.apache.org/jira/browse/TUSCANY-718 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-Mx Reporter: Kapil Katyal Priority: Minor Fix For: Java-Mx Attachments: patch1.txt Need to make the noEMF option on the codegen tool the default immediately after M2 -- 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]
WARNING for SDO codegen users
I just committed TUSCANY-718, which makes the -noEMF option the default SDO code generator pattern. The new pattern generates code without EMF dependencies, but being new is also likely to have more bugs then the old pattern. If you run into any problems with the new pattern, you can switch back to the old one by using the -useEMFPatterns option when you run the generator. One more warning is that if you generate the new pattern code into the same directory where you had previously generated the old pattern, you won't be able to run the code because there will be some old files that will interfere with the new classes. Make sure to delete the old files before regenerating. Thanks, Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating the website
Yep, working for me now - thanks Rick! Andy On 11/7/06, Rick [EMAIL PROTECTED] wrote: I think this has been fixed. cd /www/incubator.apache.org/tuscany/ svn update At revision 472177. http://issues.apache.org/jira/browse/INFRA-1017 Andrew Borley wrote: Thanks for sorting this out Rick. The odd thing is that I used to have the correct privileges to do this - something must have gone wrong when minotaur was reinstated. Cheers Andy On 11/6/06, cr22rc [EMAIL PROTECTED] wrote: I don't think it really has anything to do with svn. I think this is simply a unix permission issue as I've reported before. I have done everything I can think of. I've opened a jira, I've popped on the IRC chat and was politely told to work through our project mentors. I've sent them now two notes. From my understanding this takes someone that has root privileges on minotaur about 5 minutes of work, if that. Andrew Borley wrote: OK, it appears this is because I've somehow been dropped off a group, or I'm in the wrong group on people.apache.org - doing id -Gn on minotaur lists me as belonging to ajborley, apcvs and ws groups. Doing id -Gn pgrobbins (or jboynes, jmarino, etc) gives pgrobbins, apcvs and incubator groups which means that some people can update the site but not others (including kelvingoodson, antelder and rfeng). I expect this has something to do with svn permissions - as a tuscany committer I get svn access to all the ws projects so I'm in the svn ws group. Does anyone know how I can get put back in the incubators group? Cheers Andy On 11/3/06, cr22rc [EMAIL PROTECTED] wrote: Just to keep you up to date, I was informed I should work this through our project mentors. To which I've sent a note off to Sam Ruby and Davanum Srinivas. Rick wrote: Hello I opened a Jira on this http://issues.apache.org/jira/browse/INFRA-1017 and I went to the apache infrastructure (asfinfra) irc channel and left a message and a pointer to the Jira. I don't know if this is the right way to go about this, but figure at worst I'll get my hand slapped :-) Andrew Borley wrote: Hi, I'm trying to update the website with some C++ M2 information via the following process: log into people.apache.org cd /www/incubator.apache.org/tuscany svn update But I'm getting an svn failure:Can't open file '.svn/lock': Permission denied. It looks like all the files in /www/incubator.apache.org/tuscany/.svn are read-only after the reinstatement of minotaur I don't have access rights to do a chmod on them. svn cleanup produces the same error. Can anyone in Tuscany get this to work? Or should we go to the infrastructure folks? And how do I go about contacting them? Cheers! Andy - 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] - 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] - 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] Assigned: (TUSCANY-905) FK references not correctly resolved when an alias is used
[ http://issues.apache.org/jira/browse/TUSCANY-905?page=all ] Brent Daniel reassigned TUSCANY-905: Assignee: Brent Daniel FK references not correctly resolved when an alias is used -- Key: TUSCANY-905 URL: http://issues.apache.org/jira/browse/TUSCANY-905 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel There's a potential NPE in InsertGenerator.getAttributeProperties() and UpdateGenerator.getChangedFields() when foreign key fields have propertyName mappings. Both need to be updated to search for foreign key field Property objects by the propertyName. -- 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] Resolved: (TUSCANY-905) FK references not correctly resolved when an alias is used
[ http://issues.apache.org/jira/browse/TUSCANY-905?page=all ] Brent Daniel resolved TUSCANY-905. -- Resolution: Fixed FK references not correctly resolved when an alias is used -- Key: TUSCANY-905 URL: http://issues.apache.org/jira/browse/TUSCANY-905 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel There's a potential NPE in InsertGenerator.getAttributeProperties() and UpdateGenerator.getChangedFields() when foreign key fields have propertyName mappings. Both need to be updated to search for foreign key field Property objects by the propertyName. -- 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] Created: (TUSCANY-906) Provide ant scripts to build selected samples
Provide ant scripts to build selected samples - Key: TUSCANY-906 URL: http://issues.apache.org/jira/browse/TUSCANY-906 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Environment: Java5, Windows XP Reporter: Simon Nash The samples in the M2 branch are all set up to be built using maven. For non-maven users, there is currently no alternative approach to building that is supported or documented. This will be a significant inhibitor to non-maven users picking up and using the M2 release. We should include ant scripts for at least least some of the samples to provide an alternative approach that works out of the box for ant and is easy to customize for other build environments. -- 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-906) Provide ant scripts to build selected samples
[ http://issues.apache.org/jira/browse/TUSCANY-906?page=all ] Simon Nash updated TUSCANY-906: --- Attachment: build.xml ant script for building the standalone calculator sample Provide ant scripts to build selected samples - Key: TUSCANY-906 URL: http://issues.apache.org/jira/browse/TUSCANY-906 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Environment: Java5, Windows XP Reporter: Simon Nash Attachments: build.xml, build.xml The samples in the M2 branch are all set up to be built using maven. For non-maven users, there is currently no alternative approach to building that is supported or documented. This will be a significant inhibitor to non-maven users picking up and using the M2 release. We should include ant scripts for at least least some of the samples to provide an alternative approach that works out of the box for ant and is easy to customize for other build environments. -- 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-906) Provide ant scripts to build selected samples
[ http://issues.apache.org/jira/browse/TUSCANY-906?page=all ] Simon Nash updated TUSCANY-906: --- Attachment: build.xml ant script for building the webapp helloworldws sample (requires adding 2 webapp* jar files to the binary distro) Provide ant scripts to build selected samples - Key: TUSCANY-906 URL: http://issues.apache.org/jira/browse/TUSCANY-906 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Environment: Java5, Windows XP Reporter: Simon Nash Attachments: build.xml, build.xml The samples in the M2 branch are all set up to be built using maven. For non-maven users, there is currently no alternative approach to building that is supported or documented. This will be a significant inhibitor to non-maven users picking up and using the M2 release. We should include ant scripts for at least least some of the samples to provide an alternative approach that works out of the box for ant and is easy to customize for other build environments. -- 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: Candidate M2 Distros @ http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/
It's not clear to me when or when you don't need it, but do we need for any or all of these distros a STATUS.txt file to be included? As an example http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/spec/sdo/1.0-incubator-M2/STATUS.txt Raymond Feng wrote: Hi, I uploaded the M2 candidate distros to http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. Please review and provide feedbacks to us. The javadoc for osoa spec has not been included yet. I try to avoid changing the pom.xml to produce javadoc as it's tagged. Maybe I can run mvn javadoc:jar manually. Anyway it's work in progress. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
Rick wrote: Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library Wouldn't if we added javadoc, SDOgen, Java2WSDL, WSDL2Java, War Plugin commandline to this be essentially a Tuscany SDK? Yes, it would, and for M3 it would be good to talk about whether this is a useful thing to provide. At the moment I am focused on the minimum needed to solve the specific problem of building simple webapps using ant scripts that don't require custom tasks. I have attached the 2 ant scripts that I have completed so far to TUSCANY-906. I'd appreciate suggestions for improvement, especially to the webapp one. In their current state, they can't handle extension dependencies. I'm going to look into creating a custom ant task that will support this in a similar manner to the Tuscany maven war plugin. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache Tuscany Free Webinar, TOMORROW- Wed. November 8th at 8 AM pacific
-- Forwarded message -- From: haleh mahbod [EMAIL PROTECTED] Date: Oct 18, 2006 7:26 PM Subject: Apache Tuscany Free Webinar, Wed. November 8th at 8 AM pacific - Mark your Calendar! To: tuscany-dev@ws.apache.org, tuscany-user@ws.apache.org *Apache **Tuscany**: Not the Same Old Architecture* Do you think of the popular term SOA as the Same Old Architecture concept? The Apache Tuscany Project moves SOA (Service Oriented Architecture) beyond buzzwords and vague arm-waving into reality. The project aims to create a next-generation services infrastructure in open source based on the principles behind the Service Component Architecture (SCA). With Apache Tuscany, application developers will be able to create, assemble, and deploy service networks in ways that are not easily done or possible with existing middleware. This webinar will provide an overview of how Apache Tuscany simplifies the task of creating and assembling service-based applications using SCA. It will also cover where the Tuscany project is headed and how it will help developers build tomorrow's applications today. Speakers: Jeremy Boynes and Jim Marino *Jeremy Boynes, Gluecode CTO, IBM Corporation** * Jeremy works at IBM on emerging technologies for Service Oriented Architecture and is an active contributor to Apache Tuscany and other open source projects. Prior to acquisition by IBM, Jeremy was CTO for Gluecode Software and one of the founders of the Apache Geronimo J2EE project. *Jim Marino, Senior Principal Technologist, Office of the CTO, BEA System** * Jim Marino works at BEA Systems in the office of the CTO on emerging technologies. He is currently involved in the development of the SCA specifications and the Apache Tuscany Project. Prior to BEA, Jim was with Art Technology Group and a number of Bay Area startups. *Seminar Attendance Information * *(This free webinar is hosted by BEA for **Tuscany** . Thank you)* · Test your computer's configuration: http://esd.placeware.com/LM2005test · Click the meeting URL: https://www.livemeeting.com/cc/bea/join?id=110106aarole=attendpw=ATTBEA *or *if you can't click the above meeting URL, click the following link: https://www.livemeeting.com/cc/bea 1. When you click on either URL, the Join Meeting page appears. In the following fields, verify or enter this information: o*Name:* (Enter your first and last name) o*Meeting ID:* 110106aa o*Meeting Key:* ATTBEA 3. Click *Join Meeting*. 4. If prompted, install and run the Live Meeting console software. It will take a few moments for the Live Meeting console to launch. *Audio* Once you log in to the Live Meeting console, you should hear the event's streaming audio. If you do not have WMP 9 installed you will be prompted to install it before the audio is available to you. If you have WMP 9 installed but you still do not hear the audio, please confirm that your PC speakers are on and that the volume is turned up. If you continue to experience difficulties, please contact Event Support (see Contact Live Meeting Event Support below) or use backup audio (see below). Thank you and we hope to see you there. Software Requirements and Support info To attend the Web conference you will need: · A computer with access to the Internet to view the visual portion of the event. · A functioning sound card and speakers or headphones for your PC. · Windows Media Player (WMP) 9 or later. · A compatible computer configuration. To test your computer: 1. Click the following link: http://esd.placeware.com/LM2005test *Note:* If you are unable to click this link, you can also cut and paste the link into the address bar of your browser. 2. Install and run Live Meeting console software if necessary. 3. You should see a Live Meeting console with 3 revolving slides. If you are able to see all three slides your test is successful. 4. If you are not able to see the slides or if your system is stalled, please contact Event Support (see Contact Live Meeting Event Support below). *Note:* The Web-based Meeting console does not support the new embedded audio features (IAB). *Back-up telephone audio* If you are unable to connect to the audio through the Internet Audio Broadcast, you can dial in to the audio over a traditional telephony line: US/Canada: (877) 698-6760 International: 503-295-8000 PIN: 6760 *Contact Live Meeting Event Support* For technical assistance, please contact Event Support at: US/Canada toll free: (1) (800) 893-8779 International: (1) (971) 544-3222 Quick Tips · To restore the original layout of your Live Meeting console, go to the * View* menu, and click *Restore Default Layout*. · To view relevant meeting login details, go to the *View* menu, and click *Meeting Information*. User Notes · When you enter the event, you will be prompted to install and run the Live Meeting Console software. If you cancel the software
[jira] Created: (TUSCANY-907) Schema Import is noisy when schemaLocation is an abolute URI
Schema Import is noisy when schemaLocation is an abolute URI Key: TUSCANY-907 URL: http://issues.apache.org/jira/browse/TUSCANY-907 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Java-M1 Reporter: Caroline Maynard See http://pecl.php.net/bugs/bug.php?id=9243. SDO for PHP user is importing a schema with import statements like import namespace=http://ping.chip.org/xml/pid; schemaLocation=http://ping.chip.org/xml/pid.xsd/ These are unconventional, since the schemaLocation is not usually an absolute URI, but they are valid. They see a lot (I mean a lot) of warning messages like: SDO_DAS_XML::create(http://ping.chip.org/phr/xml/http://ping.chip.org/phr/xml/types.xsd) [function.SDO-DAS-XML-create]: failed to open stream:HTTP request failed! HTTP/1.1 404 Not Found where, as you can see, an invalid URI is being created and used. However the schema is read successfully. There are potentially quite a few issues here around the handling of libxml error messages, but I'll restrict myself to the behaviour of SDOSchemaSAX2Parser::startSecondaryParse This tries to deal with four different ways to combine the path to the current schema with the schemaLocation attribute of the import element. Eventually the imported schema is found, but only after URIs like the one in the message above are created and used. I wasn't too happy with this particular method, so I perhaps went to the other extreme with the patch I shall attach, where I let libxml combine the two values according to RFC 2396. It works for me, but you may well have testcases where it fails, and want to approach the problem some other way. Whether or not you like the patch, I think something should be done to avoid the flurry of warnings about ill-formed URIs like the above. -- 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-907) Schema Import is noisy when schemaLocation is an abolute URI
[ http://issues.apache.org/jira/browse/TUSCANY-907?page=all ] Caroline Maynard updated TUSCANY-907: - Attachment: Tuscany-907.patch Possible patch for Tuscany-907 Schema Import is noisy when schemaLocation is an abolute URI Key: TUSCANY-907 URL: http://issues.apache.org/jira/browse/TUSCANY-907 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Java-M1 Reporter: Caroline Maynard Attachments: Tuscany-907.patch See http://pecl.php.net/bugs/bug.php?id=9243. SDO for PHP user is importing a schema with import statements like import namespace=http://ping.chip.org/xml/pid; schemaLocation=http://ping.chip.org/xml/pid.xsd/ These are unconventional, since the schemaLocation is not usually an absolute URI, but they are valid. They see a lot (I mean a lot) of warning messages like: SDO_DAS_XML::create(http://ping.chip.org/phr/xml/http://ping.chip.org/phr/xml/types.xsd) [function.SDO-DAS-XML-create]: failed to open stream:HTTP request failed! HTTP/1.1 404 Not Found where, as you can see, an invalid URI is being created and used. However the schema is read successfully. There are potentially quite a few issues here around the handling of libxml error messages, but I'll restrict myself to the behaviour of SDOSchemaSAX2Parser::startSecondaryParse This tries to deal with four different ways to combine the path to the current schema with the schemaLocation attribute of the import element. Eventually the imported schema is found, but only after URIs like the one in the message above are created and used. I wasn't too happy with this particular method, so I perhaps went to the other extreme with the patch I shall attach, where I let libxml combine the two values according to RFC 2396. It works for me, but you may well have testcases where it fails, and want to approach the problem some other way. Whether or not you like the patch, I think something should be done to avoid the flurry of warnings about ill-formed URIs like the above. -- 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: Apache Tuscany Free Webinar, TOMORROW- Wed. November 8th at 8 AM pacific
I've uploaded the slides for tomorrow's presentation at: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/doc/ tuscany.webinar.final.pdf Jim On Nov 7, 2006, at 4:01 PM, haleh mahbod wrote: -- Forwarded message -- From: haleh mahbod [EMAIL PROTECTED] Date: Oct 18, 2006 7:26 PM Subject: Apache Tuscany Free Webinar, Wed. November 8th at 8 AM pacific - Mark your Calendar! To: tuscany-dev@ws.apache.org, tuscany-user@ws.apache.org *Apache **Tuscany**: Not the Same Old Architecture* Do you think of the popular term SOA as the Same Old Architecture concept? The Apache Tuscany Project moves SOA (Service Oriented Architecture) beyond buzzwords and vague arm-waving into reality. The project aims to create a next-generation services infrastructure in open source based on the principles behind the Service Component Architecture (SCA). With Apache Tuscany, application developers will be able to create, assemble, and deploy service networks in ways that are not easily done or possible with existing middleware. This webinar will provide an overview of how Apache Tuscany simplifies the task of creating and assembling service-based applications using SCA. It will also cover where the Tuscany project is headed and how it will help developers build tomorrow's applications today. Speakers: Jeremy Boynes and Jim Marino *Jeremy Boynes, Gluecode CTO, IBM Corporation** * Jeremy works at IBM on emerging technologies for Service Oriented Architecture and is an active contributor to Apache Tuscany and other open source projects. Prior to acquisition by IBM, Jeremy was CTO for Gluecode Software and one of the founders of the Apache Geronimo J2EE project. *Jim Marino, Senior Principal Technologist, Office of the CTO, BEA System** * Jim Marino works at BEA Systems in the office of the CTO on emerging technologies. He is currently involved in the development of the SCA specifications and the Apache Tuscany Project. Prior to BEA, Jim was with Art Technology Group and a number of Bay Area startups. *Seminar Attendance Information * *(This free webinar is hosted by BEA for **Tuscany** . Thank you)* · Test your computer's configuration: http://esd.placeware.com/LM2005test · Click the meeting URL: https://www.livemeeting.com/cc/bea/join? id=110106aarole=attendpw=ATTBEA *or *if you can't click the above meeting URL, click the following link: https://www.livemeeting.com/cc/bea 1. When you click on either URL, the Join Meeting page appears. In the following fields, verify or enter this information: o*Name:* (Enter your first and last name) o*Meeting ID:* 110106aa o*Meeting Key:* ATTBEA 3. Click *Join Meeting*. 4. If prompted, install and run the Live Meeting console software. It will take a few moments for the Live Meeting console to launch. *Audio* Once you log in to the Live Meeting console, you should hear the event's streaming audio. If you do not have WMP 9 installed you will be prompted to install it before the audio is available to you. If you have WMP 9 installed but you still do not hear the audio, please confirm that your PC speakers are on and that the volume is turned up. If you continue to experience difficulties, please contact Event Support (see Contact Live Meeting Event Support below) or use backup audio (see below). Thank you and we hope to see you there. Software Requirements and Support info To attend the Web conference you will need: · A computer with access to the Internet to view the visual portion of the event. · A functioning sound card and speakers or headphones for your PC. · Windows Media Player (WMP) 9 or later. · A compatible computer configuration. To test your computer: 1. Click the following link: http://esd.placeware.com/LM2005test *Note:* If you are unable to click this link, you can also cut and paste the link into the address bar of your browser. 2. Install and run Live Meeting console software if necessary. 3. You should see a Live Meeting console with 3 revolving slides. If you are able to see all three slides your test is successful. 4. If you are not able to see the slides or if your system is stalled, please contact Event Support (see Contact Live Meeting Event Support below). *Note:* The Web-based Meeting console does not support the new embedded audio features (IAB). *Back-up telephone audio* If you are unable to connect to the audio through the Internet Audio Broadcast, you can dial in to the audio over a traditional telephony line: US/Canada: (877) 698-6760 International: 503-295-8000 PIN: 6760 *Contact Live Meeting Event Support* For technical assistance, please contact Event Support at: US/Canada toll free: (1) (800) 893-8779 International: (1) (971) 544-3222 Quick Tips · To restore the original layout of your Live Meeting console, go to the * View* menu,
Important issues around the SCA Candidate M2 distros, wasRe: Candidate M2 Distros @ http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/
Couple issues: The STATUS file is missing as Rick mentioned, the updated version is available at: - https://svn.apache.org/repos/asf/incubator/tuscany/STATUS LICENSE does not include licenses from each sub-component mentioned in the NOTICE file... See related comments for SDO distribution - http://www.mail-archive.com/general%40incubator.apache.org/msg11279.html RAT is still finding couple files with missing ASF headers: - !? HelloWorldWSAsyncClient.java - !? InnerCompositeClient.java - !? AbstractOperationOutboundInvocationHandler.java - !? CompositeReferenceCallbackTargetInvokerInvocationExceptionTestCase.java - !? JNDIPropertyFactoryTestCase.java - !? ipo.xml - !? AbstractInboundInvocationHandlerTestCase.java - !? AbstractOutboundInvocationHandlerTestCase.java - !? .pmd - !? ClassloaderHook.java - !? Constants.java - !? TuscanySessionListenerTestCase.java - !? InvalidCompositePath.java - !? hello_world_doc_lit.wsdl - !? .checkstyle - !? .pmd - !? hello_world_doc_lit.wsdl - !? hello_world_doc_lit_inout.wsdl - !? log4j-tests.properties - !? log4j.properties - etc, etc, etc Checking for old ASF header style: $ grep -rli --exclude=*.svn-base licensors samples samples/standalone/calculator-combo/readme.html samples/standalone/calculatorRMIService/readme.html samples/webapp/calculatorws/readme.html $ grep -rli --exclude=*.svn-base licensors sca sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/NoRemoteMethodException.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/NoRemoteServiceException.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiBinding.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiBindingBuilder.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiBindingException.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiInvoker.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiReference.java sca/runtime/osgi/src/main/java/org/apache/tuscany/osgi/binding/OSGiService.java sca/runtime/osgi/src/main/resources/META-INF/sca/osgibinding.scdl Well, I'll have a second look later this week, but you guys should look into addressing these issues before submitting to vote. - Luciano On 11/7/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Rick. Are you saying we're missing STATUS.txt? Thanks, Raymond - Original Message - From: cr22rc [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 07, 2006 1:58 PM Subject: Re: Candidate M2 Distros @ http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/ It's not clear to me when or when you don't need it, but do we need for any or all of these distros a STATUS.txt file to be included? As an example http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/spec/sdo/1.0-incubator-M2/STATUS.txt Raymond Feng wrote: Hi, I uploaded the M2 candidate distros to http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. Please review and provide feedbacks to us. The javadoc for osoa spec has not been included yet. I try to avoid changing the pom.xml to produce javadoc as it's tagged. Maybe I can run mvn javadoc:jar manually. Anyway it's work in progress. Thanks, Raymond - 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]
