Board Report for June 2007
Dear WS Committers, Please update the board report page with notable happening (releases, committers etc): http://wiki.apache.org/ws/ReportForJun2007 Old reports are available for comparison: http://wiki.apache.org/ws/FrontPage/BoardReports thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could a Wiki admin please export the web site? was: Steps to update the Web site
Hernan, Could you please post the "magic" steps? thanks, dims On 6/8/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: Done! Cheers! Hernan Jean-Sebastien Delfino wrote: > Luciano Resende wrote: >> Comments inline >> >> On 6/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >>> [snip] >>> haleh mahbod wrote: >>> > >>> > http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 >>> > >>> > This document is purely sharing the wiki stucture and explains how to >>> > move >>> > cwiki to the website. >>> > >>> > >>> >>> According to this doc a change to the Wiki representing the Tuscany Web >>> site is: >>> >>> 1. Exported to Html based on change activity >>> Does that mean "exported on each change to a Wiki page"? I think this is >>> what I've observed but could you please confirm? If it's the case then >>> I'd suggest to make it more clear in the doc. >>> >> >> Yes, it's every page... I'll update the doc. >> >>> 2. Copied to the web site using an SVN update every 5, 25, 40 and 55 >>> after the hour? >>> I made a change to the Wiki (added a news entry about the 0.90 release >>> to http://cwiki.apache.org/confluence/display/TUSCANY/Home) at 5:26pm >>> PDT. It is 9:17pm PDT and I can't see my change at >>> http://incubator.apache.org/tuscany/. >>> >>> So I must have missed a step... What do I need to do to get a Wiki >>> change propagated to the Web site? >>> >> >> You might be having the same issue as described on the following post >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18528.html >> >>> Thanks >>> >>> -- >>> Jean-Sebastien >>> >>> > > Could someone with Wiki admin rights please export the web site Wiki as > suggested in that post? I added a news entry for the Tuscany SCA 0.90 > release, and it's not reflected on the web site yet. > > Thanks. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Permission denied when trying to commit changes
Andy, Please try now. Sorry for the delay. -- dims On 6/26/07, ant elder <[EMAIL PROTECTED]> wrote: Probably dims needs to update your karma. I've not seen the response back from root for you id yet, you may need to just wait a little longer. ...ant On 6/26/07, Andy Grove <[EMAIL PROTECTED]> wrote: > I am trying to submit my first change now that I have committer status but I'm getting a 403 Forbidden error. > > Authentication realm: <https://svn.apache.org:443> ASF Committers > Username: myusername > Password for 'myusername': ** > svn: Commit failed (details follow): > svn: MKACTIVITY of '/repos/asf/!svn/act/20b54094-59ad-2e4b-b6f4-9b67020e49ce': 403 Forbidden ( https://svn.apache.org) > > I used the following URL when running the checkout command: > > https://svn.apache.org/repos/asf/incubator/tuscany/java > > Can anyone give me any pointers to what the problem might be? I have changed both my SSH and SVN passwords from the initially supplied password. > > Thanks, > > Andy Grove > Product Architect, HydraSDO > Rogue Wave Software > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Update from board regarding our oversight of WS project.
Team, The board would like WS reports to move towards the style and development that the Jakarta and Incubator reports are done (i.e., owners for subprojects developing their parts, and the overall chair acting as editor). For Inspiration, See [1] So, Firstly, Please volunteer (take ownership!!) to take charge for reports for your subproject. If i don't hear from anyone on a specific subproject, i will assume that no one is interested in that subproject anymore and we can start the process of pruning that subproject. FYI, the Spring cleaning is done [2] Secondly, If there are folks who are not on the ws pmc, but who should be, then please bring up their nomination on private AT ws.apache.org I really hope the exisiting PMC members and the new ones will rejuvenate our board reporting duty and continued oversight of the "umbrella" WS project. It may be time to do some spring cleaning of the pmc too as there are quite a few folks who are not active anymore. One option is to change them to Emeritus status. If anyone falls into this category, please let chime in. BTW, i was a bit late in submission, we have to do another board report for this month. I've started a page here: http://wiki.apache.org/ws/ReportForJul2007 thanks, dims [1] http://wiki.apache.org/incubator/June2007 [2] http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update from board regarding our oversight of WS project.
Folks, The matrix is still sparse :) Please sign up!!! http://wiki.apache.org/ws/FrontPage/BoardReports -- dims On 7/3/07, Kaushalye Kapuruge <[EMAIL PROTECTED]> wrote: Hi Dims, I volunteer for Apache Rampart-C project. Cheers, Kaushalye Kaushalye Kapuruge wrote: > Hi Dims, > I volunteer for Apache Rampart-C project. > Cheers, > Kaushalye > > Davanum Srinivas wrote: >> Team, >> >> The board would like WS reports to move towards the style and >> development that the Jakarta and Incubator reports are done (i.e., >> owners for subprojects developing their parts, and the overall chair >> acting as editor). For Inspiration, See [1] >> >> So, Firstly, Please volunteer (take ownership!!) to take charge for >> reports for your subproject. If i don't hear from anyone on a specific >> subproject, i will assume that no one is interested in that subproject >> anymore and we can start the process of pruning that subproject. FYI, >> the Spring cleaning is done [2] >> >> Secondly, If there are folks who are not on the ws pmc, but who should >> be, then please bring up their nomination on private AT ws.apache.org >> >> I really hope the exisiting PMC members and the new ones will >> rejuvenate our board reporting duty and continued oversight of the >> "umbrella" WS project. It may be time to do some spring cleaning of >> the pmc too as there are quite a few folks who are not active anymore. >> One option is to change them to Emeritus status. If anyone falls into >> this category, please let chime in. >> >> BTW, i was a bit late in submission, we have to do another board >> report for this month. I've started a page here: >> http://wiki.apache.org/ws/ReportForJul2007 >> >> thanks, >> dims >> >> [1] http://wiki.apache.org/incubator/June2007 >> [2] >> http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL PROTECTED] >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pruning committers and pmc members
Folks, Believe it or not! we have 230 people who have karma to our svn: https://svn.apache.org/repos/asf/webservices/ Out of these only about 74 people have made commits in the last 1 year. You can get this info by using the svn log: svn log -v --revision 2006-07-05:HEAD https://svn.apache.org/repos/asf/webservices/ I'd like to start a process of pruning both the committer list and the pmc members list. As am sure some of the pmc members have not been active recently either as i alluded to you in the prev email about the board report. Here's something i came up with. Basically i will add a text file in https://svn.apache.org/repos/asf/webservices/admin which will have the names of all the committers and an option right next to their name with Y/N and question being would you like to keep your commit rights. Example. dims [Y/N] I can pre-fill this to Y for everyone who have made commits in the last 1 year to reduce work for already active people. At the end of say 2 weeks from kicking off the process, we will collect the final tally and prune the svn karma to those who chose to edit the file. If someone missed the deadline or want to get back karma say in a couple of months, they can send a quick email to the pmc (private AT ws.apache.org) and one of us can add it right back. How about we use the same process for PMC members too? I can add another file for pmc members and here i will not prefill anyones option. All PMC members have to edit the file and modify the option next to their name. At the end, same 2 weeks, we can declare those who did not choose to be active as Emeritus. For PMC members, there is a higher threshold, if one of the Emeritus members want to get back into the game, they will have to drop an email and we will hold a vote. This is because, we need to notify the board for *every* pmc member change and there are legal implications and a higher threshold. Sounds good? comments? thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pruning committers and pmc members
We are just discussing the mechanics. it's not ready yet. -- dims On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Dims, Davanum Srinivas wrote: > Folks, > > Believe it or not! we have 230 people who have karma to our svn: > https://svn.apache.org/repos/asf/webservices/ > > Out of these only about 74 people have made commits in the last 1 > year. You can get this info by using the svn log: > svn log -v --revision 2006-07-05:HEAD > https://svn.apache.org/repos/asf/webservices/ > > I'd like to start a process of pruning both the committer list and the > pmc members list. As am sure some of the pmc members have not been > active recently either as i alluded to you in the prev email about the > board report. > > Here's something i came up with. Basically i will add a text file in > https://svn.apache.org/repos/asf/webservices/admin which will have the > names of all the committers and an option right next to their name > with Y/N and question being would you like to keep your commit rights. > Example. > > dims [Y/N] > > I can pre-fill this to Y for everyone who have made commits in the > last 1 year to reduce work for already active people. At the end of > say 2 weeks from kicking off the process, we will collect the final > tally and prune the svn karma to those who chose to edit the file. If > someone missed the deadline or want to get back karma say in a couple > of months, they can send a quick email to the pmc (private AT > ws.apache.org) and one of us can add it right back. > > How about we use the same process for PMC members too? I can add > another file for pmc members and here i will not prefill anyones > option. All PMC members have to edit the file and modify the option > next to their name. At the end, same 2 weeks, we can declare those who > did not choose to be active as Emeritus. For PMC members, there is a > higher threshold, if one of the Emeritus members want to get back into > the game, they will have to drop an email and we will hold a vote. > This is because, we need to notify the board for *every* pmc member > change and there are legal implications and a higher threshold. > > Sounds good? comments? > > thanks, > dims > Sounds fine to me. I don't see the file you point to in https://svn.apache.org/repos/asf/webservices/admin ...did I miss something or is it simply not ready yet? Yours, Mike --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update from board regarding our oversight of WS project.
Folks, 4 Projects have no volunteers yet...Axis/Axis2/JaxMe/XMLRPC http://wiki.apache.org/ws/FrontPage/BoardReports The board meeting is on 18th this month. Please update info on your project here: http://wiki.apache.org/ws/ReportForJul2007 thanks, dims On 7/3/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Folks, The matrix is still sparse :) Please sign up!!! http://wiki.apache.org/ws/FrontPage/BoardReports -- dims On 7/3/07, Kaushalye Kapuruge <[EMAIL PROTECTED]> wrote: > Hi Dims, > I volunteer for Apache Rampart-C project. > Cheers, > Kaushalye > > Kaushalye Kapuruge wrote: > > Hi Dims, > > I volunteer for Apache Rampart-C project. > > Cheers, > > Kaushalye > > > > Davanum Srinivas wrote: > >> Team, > >> > >> The board would like WS reports to move towards the style and > >> development that the Jakarta and Incubator reports are done (i.e., > >> owners for subprojects developing their parts, and the overall chair > >> acting as editor). For Inspiration, See [1] > >> > >> So, Firstly, Please volunteer (take ownership!!) to take charge for > >> reports for your subproject. If i don't hear from anyone on a specific > >> subproject, i will assume that no one is interested in that subproject > >> anymore and we can start the process of pruning that subproject. FYI, > >> the Spring cleaning is done [2] > >> > >> Secondly, If there are folks who are not on the ws pmc, but who should > >> be, then please bring up their nomination on private AT ws.apache.org > >> > >> I really hope the exisiting PMC members and the new ones will > >> rejuvenate our board reporting duty and continued oversight of the > >> "umbrella" WS project. It may be time to do some spring cleaning of > >> the pmc too as there are quite a few folks who are not active anymore. > >> One option is to change them to Emeritus status. If anyone falls into > >> this category, please let chime in. > >> > >> BTW, i was a bit late in submission, we have to do another board > >> report for this month. I've started a page here: > >> http://wiki.apache.org/ws/ReportForJul2007 > >> > >> thanks, > >> dims > >> > >> [1] http://wiki.apache.org/incubator/June2007 > >> [2] > >> http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL PROTECTED] > >> > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update from board regarding our oversight of WS project.
Team, Looks like we missed the mark by a mile!. I am thoroughly disappointed. We have 2 projects with No volunteers and 8 projects with *NO* reports. If the volunteers are not interested anymore, Please appeal to someone else to take up the responsibility. At this point, i will recommend that we archive jaxme and xmlrpc (after a release like Jochen mentioned) and if the situation persists (with no reports from the other projects), then we should do the archive the other projects as well. Project - Volunteer/Report -- axis - Yes/Yes axis2- Yes/No commons - Yes/No jaxme- No/No juddi- Yes/Yes kandula - Yes/Yes muse - Yes/No rampart - Yes/Yes sandesha - Yes/No savan- Yes/No scout- Yes/Yes synapse - Yes/Yes woden- Yes/Yes wsif - Yes/No wss4j- Yes/Yes xmlrpc - No/No Thanks, dims On 7/2/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Team, The board would like WS reports to move towards the style and development that the Jakarta and Incubator reports are done (i.e., owners for subprojects developing their parts, and the overall chair acting as editor). For Inspiration, See [1] So, Firstly, Please volunteer (take ownership!!) to take charge for reports for your subproject. If i don't hear from anyone on a specific subproject, i will assume that no one is interested in that subproject anymore and we can start the process of pruning that subproject. FYI, the Spring cleaning is done [2] Secondly, If there are folks who are not on the ws pmc, but who should be, then please bring up their nomination on private AT ws.apache.org I really hope the exisiting PMC members and the new ones will rejuvenate our board reporting duty and continued oversight of the "umbrella" WS project. It may be time to do some spring cleaning of the pmc too as there are quite a few folks who are not active anymore. One option is to change them to Emeritus status. If anyone falls into this category, please let chime in. BTW, i was a bit late in submission, we have to do another board report for this month. I've started a page here: http://wiki.apache.org/ws/ReportForJul2007 thanks, dims [1] http://wiki.apache.org/incubator/June2007 [2] http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website ACL
Ant, Please drop an email to apmail AT apache.org. thanks, dims On 7/16/07, ant elder <[EMAIL PROTECTED]> wrote: On 7/15/07, ant elder <[EMAIL PROTECTED]> wrote: > If we could get cwiki change emails sent to the tuscany-commit mailing list so its easy to give some oversight then I'd be in favour of a very low bar of entry. I had a try at doing this by setting up a cwiki user using the [EMAIL PROTECTED] email address and adding that user as a watcher of the cwiki space. This works but all the emails from [EMAIL PROTECTED] to the tuscany-commits list require moderation which is a bit of a pain. Does any one know of a way around this? We need some way to allow [EMAIL PROTECTED] to post to the tuscany-commits list without having to subscribe it to the list so we don't send all the commit emails to [EMAIL PROTECTED] (CC'ing you dims as you seem to have lots of mailing lits powers so may know some way around this?) ...ant -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report for Sept 2006
Team, It's time for updating the board about what we have been upto. Please take a few minutes to update the wiki as usual. Yes, All committers are welcome to add content. All PMC members, please make an effort as it is part of your duty as PMC members. http://wiki.apache.org/ws/ReportForSep2006 Thanks, dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report for Sept 2006
Dear ws committers, Remainder: *PLEASE* update wiki with status of your projects thanks, dims On 9/1/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Team, It's time for updating the board about what we have been upto. Please take a few minutes to update the wiki as usual. Yes, All committers are welcome to add content. All PMC members, please make an effort as it is part of your duty as PMC members. http://wiki.apache.org/ws/ReportForSep2006 Thanks, dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Permissions
Ant, Added you as an admin. -- dims On 10/9/06, ant elder <[EMAIL PROTECTED]> wrote: This comes up every time we add a new committer, looks like right now Jeremy is the only one able to do this, see: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07691.html Dims, any chance I could be granted this power as well so we have someone in a different timezone to Jeremy who's able to do this? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi > > Can I assign JIRAs to myself and then update them futher as I work or > close > them ? How do I do that ? > > I had raised http://issues.apache.org/jira/browse/TUSCANY-809 releated to > updating license headers and want to close that now as I have committed > the > updates. > > Thanks > > - Venkat > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rajith Attapattu to be a Tuscany committer
+1 from me. On 11/3/06, Simon Nash <[EMAIL PROTECTED]> wrote: +1 (non-binding) Simon ant elder 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 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unix patch program
-p0
-- dims
On 11/8/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I have been using Eclipse to apply patches from contributors and I
continue to have problems when patches contain additions. I would like
to try the Unix patch utility. Can someone provide the options needed
when using the Unix "patch" command to apply a patch created from some
relative location, to the same location to be patched? I think I just
need the correct value for "p":
patch -pnum
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A few issues around axis2 1.1 maven artifacts
incubation artifacts can't go to maven central repo... -- dims On 11/14/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On 11/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, Dims. > > Is it OK to release our stuff (Tuscany M2) based on the following two > repositories? > > http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven > http://ws.zones.apache.org/repository > If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A few issues around axis2 1.1 maven artifacts
I think so. -- dims On 11/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Sorry that I confused you. I didn't mean to upload Tuscany artifacts to the maven central repo. I was wondering if we can use the two repos I mentioned as the remote repositories to be referenced by our M2 artifacts in maven (http://people.apache.org/repo/m2-incubating-repository/). Thanks, Raymond - Original Message ----- From: "Davanum Srinivas" <[EMAIL PROTECTED]> To: Cc: Sent: Tuesday, November 14, 2006 12:28 PM Subject: Re: A few issues around axis2 1.1 maven artifacts > incubation artifacts can't go to maven central repo... > > -- dims > > On 11/14/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> On 11/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> > Hi, Dims. >> > >> > Is it OK to release our stuff (Tuscany M2) based on the following two >> > repositories? >> > >> > http://people.apache.org/repo/m1-ibiblio-rsync-repository >> >> It would be better to use the M1 repo at ibiblio >> http://www.ibiblio.org/maven >> >> > http://ws.zones.apache.org/repository >> > >> >> If this is mirrored I'd suggest using that, if not I don't think you >> have a option :-) >> -- >> Jeremy >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) > > - > 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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
+1 frome me. (belated) On 11/14/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Probably. -1 is nice and bombastic and makes people pay attention (rob me of my drama why don't you!). Said -1 is withdrawn when the vote is complete. Hen On 11/14/06, Craig L Russell <[EMAIL PROTECTED]> wrote: > Hi Henri, > > Point of order. > > I don't believe that you really are voting -1 on the release. Rather, > you are pointing out that the vote is incomplete until 3 binding > votes of the Incubator PMC are received. I think there is a big > difference... > > Craig > > On Nov 14, 2006, at 2:43 PM, Henri Yandell wrote: > > > -1 on the release. > > > > The simple rule is - you need 3 PMC votes to release (or add a > > committer). > > > > You currently have 1 (Robert's). That should be enough if Sam and Dims > > (your mentors) vote; however they currently haven't voted on either > > the [EMAIL PROTECTED] thread or the original. > > > > Hen > > > > On 11/14/06, Sam Ruby <[EMAIL PROTECTED]> wrote: > >> More than 72 hours have passed, and presumably everybody on the > >> incubator PMC that cares to vote has done so (Thanks Robert!). > >> Please > >> proceed with the release. > >> > >> If anybody objects to this process, point them my way. > >> > >> - Sam Ruby > >> > >> Original Message > >> Subject: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 > >> artifacts > >> Date: Sun, 5 Nov 2006 14:10:40 -0800 > >> From: Luciano Resende <[EMAIL PROTECTED]> > >> Reply-To: general@incubator.apache.org > >> To: general@incubator.apache.org > >> > >> The Tuscany PPMC has voted to Release DAS for Java API > >> Implementation as > >> part of the M2 release. > >> In accordance with Incubator release procedures we are asking the > >> Incubator > >> PMC to approve this release. > >> > >> Vote thread : > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10257.html > >> > >> Vote result : > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10373.html > >> > >> The release candidate is available at: > >> > >> > >> http://people.apache.org/~kelvingoodson/das_java/RC4b/ >> people.apache.org/%7Ekelvingoodson/das_java/RC4b/> > >> > >> The release is taged at : > >> > >> > >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/ > >> 1.0-incubator-M2/ > >> > >> > >> > >> What's new in DAS Java M2 > >> > >>DAS Core features > >> > >> - MySQL support > >> - Static Data Objects > >> - Dynamic root for static graphs > >> - "Unique" attribute on relationships > >> - Explicit ResultSet shape definition > >> - Improved logging > >> - Programmatic Configuration > >> - Helper for empty SDO Graph > >> - Convention over configuration > >> - Column named "ID" is the PK > >> - Column named "xxx_ID" is the FK to table "xxx" > >> > >>DAS Samples > >> - Tomcat integration and automated DAS samples testing > >> (htmlUnit) > >> - DAS Samples now have all dependencies and source code > >> inside the > >> sample war > >> > >>For detailed user documentation and feature descriptions, > >> access Tuscany > >> DAS Wiki page > >> - http://wiki.apache.org/ws/Tuscany/TuscanyJava/ > >> DAS_Java_Overview > >> <https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/ > >> 1.0-incubator-M2/> > >> > >> Thanks > >> - Luciano Resende > >> > >> > >> - > >> 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] > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release
This the kind of thing usually added in release notes as well.. -- dims On 11/28/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, My opinion is that 'we release what we have presently because IMO we should not be pushing M2 any further. It would also be good if we can publish the potential problem in our website and ask users to check back at the website for patches. This way we just get done with M2 and move forward. I do not favour waiting anymore nor introducing additional stuff for M2 at this point in time (such as modularizing it). - Venkat On 11/28/06, Simon Nash <[EMAIL PROTECTED]> wrote: > > On yesterday's IRC chat we discussed WSCOMMONS-131, which causes the > current Tuscany M2 RC to have a SNAPSHOT dependency on axiom-api. > This creates a "time bomb" which would cause the Axis2 binding > in Tuscany SCA Java M2 to stop working at some future time when > incompatible changes are made to the axiom-api trunk. > > On the chat we identified 3 options that we could consider for > how to deal with this problem. > > 1. release what we have > 2. release without axis > 3. wait until axis is fixed > > Other options were discussed but did not get much support. For the > three that I have listed above (as summarized by Meeraj on the chat), > there are some variations and refinements. I have tried to summarize > the main points that were made in the chat in the paragraphs below. > > For option 1, we could mitigate the problem by explaining it in our > M2 release documentation, and we could release an update to the > Axis2 binding (a mandatory patch) that fixes the problem as soon as > new axis2 and axiom releases are available. As long as there is no > breaking change to axiom-api before the new release is available, > this means at all times we would have a combination that works. > The downside is that it looks bad to release something that we know > is broken (or will become broken in the future), even though there > is a patch available to fix the brokenness. > > For option 2, we could remove the Axis2 binding and testcases that > depend on it. Or we could just remove the Axis2 binding and > document that the Axis2 testcases don't work at the present time. > Then we could release the missing pieces as soon as there is a new > Axis2 release that fixes the problem. The disadvantage of this is > that this removes a large part of the funtionality and value of the > M2 release. Alternatively, we could create a more modular release > structure (which will be needed in the future) and repackage M2 in > a more modular form with separate releases of the core and extensions. > This has the same disadvantage that the initial release doesn't have > all the functionality that we had intended for M2. However, it does > not require extra effort (over the long term), since it brings forward > some work that we will have to do anyway. The problem with bringing it > forward is that we would would be doing it under time pressure to get > something out, thus creating tension between allowing full consideration > of how the modular structure would work (including some tricky issues > about compatibility of the modular parts), and doing the restructure > quickly so that we can release M2. > > Option 3 has less in the way of variations and sub-options. The big > unknonwn with this is how long we would need to wait, and how damaging > to Tuscany it is to wait compared with the downsides of option 1 or 2. > Given the experience of how long we had to wait for Axis2 1.1, there > is concern about another another long wait. However, this new release > would be a simple patch to 1.1, so it should be possible to get it out > very quickly. There is currently no information about how soon a > new release may be available. > > Is this a fair summary of the options? Would anyone like to add > additional rationale either pro or con any of these, or express their > preference(s) for or against any of them, or add any new options that > we might seriously consider? > >Simon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Folks, Fact #1: WSCOMMONS-131 is fixed in SVN. Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is to do the release this week. What's the ruckus all about? (Please don't make me all the emails :) thanks, dims [1] http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200611.mbox/[EMAIL PROTECTED] On 11/28/06, Jim Marino <[EMAIL PROTECTED]> wrote: > On the chat we identified 3 options that we could consider for > how to deal with this problem. > > 1. release what we have > 2. release without axis > 3. wait until axis is fixed > > Other options were discussed but did not get much support. For the > three that I have listed above (as summarized by Meeraj on the chat), > there are some variations and refinements. I have tried to summarize > the main points that were made in the chat in the paragraphs below. > > For option 1, we could mitigate the problem by explaining it in our > M2 release documentation, and we could release an update to the > Axis2 binding (a mandatory patch) that fixes the problem as soon as > new axis2 and axiom releases are available. As long as there is no > breaking change to axiom-api before the new release is available, > this means at all times we would have a combination that works. > The downside is that it looks bad to release something that we know > is broken (or will become broken in the future), even though there > is a patch available to fix the brokenness. > I would characterize the downside in different terms, similar to what Jeremy has mentioned: we would be putting out a release that ultimately will not work. Having a patch doesn't really fix the problem. That said, it seems we are trying to make a decision without enough facts. I propose we find the answers to several questions (or at least get more information) before attempting to make a decision on the best way of going. How big of an impact are the required changes for Axis? And, what is the likely timeframe of these changes, days, a week, a month, etc.? If discover that it is a few weeks then we can step back and ask why we are considering a release then patch strategy in the first place. There seems to be an assumption that we have to release now as opposed to waiting or taking the time to do a proper fix. Why is this the case since if someone needs access to the code they can just check it out from the repo and build? If it is a convenience for applications developers, then having them wait just a little longer (they can also just check the code out if they are in a rush) is really not that much of a problem given that they should not be using Tuscany or SCA for any project that is intended for production. If we find the fix will require months or an undetermined length of time (which does not seem likely), why not refactor for modularity in trunk, assess its impact and then decide if we want to move the changes to to M2 and cut a modular release that addresses the problem? In the meantime, we have the advantage of assessing progress on the Axis fix. It may take a couple of weeks to do this but is it really critical we get something out this week? Producing a release that we know is broken seems like we are marching to an artificial deadline without enough facts. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
(Please don't make me *READ* all the emails :) On 11/28/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Folks, Fact #1: WSCOMMONS-131 is fixed in SVN. Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is to do the release this week. What's the ruckus all about? (Please don't make me all the emails :) thanks, dims [1] http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200611.mbox/[EMAIL PROTECTED] On 11/28/06, Jim Marino <[EMAIL PROTECTED]> wrote: > > On the chat we identified 3 options that we could consider for > > how to deal with this problem. > > > > 1. release what we have > > 2. release without axis > > 3. wait until axis is fixed > > > > Other options were discussed but did not get much support. For the > > three that I have listed above (as summarized by Meeraj on the chat), > > there are some variations and refinements. I have tried to summarize > > the main points that were made in the chat in the paragraphs below. > > > > For option 1, we could mitigate the problem by explaining it in our > > M2 release documentation, and we could release an update to the > > Axis2 binding (a mandatory patch) that fixes the problem as soon as > > new axis2 and axiom releases are available. As long as there is no > > breaking change to axiom-api before the new release is available, > > this means at all times we would have a combination that works. > > The downside is that it looks bad to release something that we know > > is broken (or will become broken in the future), even though there > > is a patch available to fix the brokenness. > > > I would characterize the downside in different terms, similar to what > Jeremy has mentioned: we would be putting out a release that > ultimately will not work. Having a patch doesn't really fix the problem. > > That said, it seems we are trying to make a decision without enough > facts. I propose we find the answers to several questions (or at > least get more information) before attempting to make a decision on > the best way of going. How big of an impact are the required changes > for Axis? And, what is the likely timeframe of these changes, days, a > week, a month, etc.? > > If discover that it is a few weeks then we can step back and ask why > we are considering a release then patch strategy in the first place. > There seems to be an assumption that we have to release now as > opposed to waiting or taking the time to do a proper fix. Why is this > the case since if someone needs access to the code they can just > check it out from the repo and build? If it is a convenience for > applications developers, then having them wait just a little longer > (they can also just check the code out if they are in a rush) is > really not that much of a problem given that they should not be using > Tuscany or SCA for any project that is intended for production. > > If we find the fix will require months or an undetermined length of > time (which does not seem likely), why not refactor for modularity in > trunk, assess its impact and then decide if we want to move the > changes to to M2 and cut a modular release that addresses the > problem? In the meantime, we have the advantage of assessing progress > on the Axis fix. It may take a couple of weeks to do this but is it > really critical we get something out this week? > > Producing a release that we know is broken seems like we are marching > to an artificial deadline without enough facts. > > Jim > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Thanks Jim/Jeremy :) Please look at the pom's in the svn. the SNAPSHOT jars are here: http://ws.zones.apache.org/repository/org.apache.ws.commons.axiom/jars/ thanks, dims On 11/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Nov 28, 2006, at 1:24 PM, Davanum Srinivas wrote: > Folks, > > Fact #1: WSCOMMONS-131 is fixed in SVN. > Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is > to do the release this week. > > What's the ruckus all about? (Please don't make me all the emails :) Well, now, nothing :-) Are there any artifacts for 1.2.1 that we can take a look at? -- Jeremy -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Aha! so there's a catch. We still haven't started the process for a Axis2 1.1.1. Hoping to do that with a thorough JIRA scrub this week or early next week. To see what needs to be fixed for a quick 1.1.1 release. Will let you all know when we have some idea. thanks, dims On 11/29/06, Simon Nash <[EMAIL PROTECTED]> wrote: Thanks, Dims. We will need a new release of Axis2 as well, since the POMs in Axis2 1.1 point to Axiom 1.2. Will this be available at the same time as the new release of Axiom? Simon Davanum Srinivas wrote: > Thanks Jim/Jeremy :) > > Please look at the pom's in the svn. the SNAPSHOT jars are here: > http://ws.zones.apache.org/repository/org.apache.ws.commons.axiom/jars/ > > thanks, > dims > > On 11/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> On Nov 28, 2006, at 1:24 PM, Davanum Srinivas wrote: >> >> > Folks, >> > >> > Fact #1: WSCOMMONS-131 is fixed in SVN. >> > Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is >> > to do the release this week. >> > >> > What's the ruckus all about? (Please don't make me all the emails :) >> >> Well, now, nothing :-) >> >> Are there any artifacts for 1.2.1 that we can take a look at? >> -- >> Jeremy >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Folks, Can't you just use maven's exclusion mechanism: http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_exclusion to exclude the specific version of axiom and add a specific dependency on the new one? thanks, dims On 11/29/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Aha! so there's a catch. We still haven't started the process for a Axis2 1.1.1. Hoping to do that with a thorough JIRA scrub this week or early next week. To see what needs to be fixed for a quick 1.1.1 release. Will let you all know when we have some idea. thanks, dims On 11/29/06, Simon Nash <[EMAIL PROTECTED]> wrote: > Thanks, Dims. > > We will need a new release of Axis2 as well, since the POMs in > Axis2 1.1 point to Axiom 1.2. Will this be available at the > same time as the new release of Axiom? > >Simon > > Davanum Srinivas wrote: > > Thanks Jim/Jeremy :) > > > > Please look at the pom's in the svn. the SNAPSHOT jars are here: > > http://ws.zones.apache.org/repository/org.apache.ws.commons.axiom/jars/ > > > > thanks, > > dims > > > > On 11/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > >> On Nov 28, 2006, at 1:24 PM, Davanum Srinivas wrote: > >> > >> > Folks, > >> > > >> > Fact #1: WSCOMMONS-131 is fixed in SVN. > >> > Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is > >> > to do the release this week. > >> > > >> > What's the ruckus all about? (Please don't make me all the emails :) > >> > >> Well, now, nothing :-) > >> > >> Are there any artifacts for 1.2.1 that we can take a look at? > >> -- > >> Jeremy > >> > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report for December 2006
Team, It's our turn again for reporting to the board. Please add notable happenings etc in your respective projects to the wiki page as usual: http://wiki.apache.org/ws/ReportForDec2006 All committers and PMC members..please help fulfill this duty to the Apache board. Please see old archived reports for inspiration. http://wiki.apache.org/ws/FrontPage/BoardReports thanks, dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Final content for SCA Java M2
gt;> org/apache/tuscany/sca/runtime/webapp/1.0-incubator-M2/webapp-1.0- >>> incubator-M2.jar >>> org/apache/tuscany/sca/services/containers/spring/1.0-incubator-M2/ >>> spring-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/services/databinding/parent/1.0-incubator-M2/ >>> parent-1.0-incubator-M2.pom >>> org/apache/tuscany/sca/services/databinding/databinding-axiom/1.0- >>> incubator-M2/databinding-axiom-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/services/databinding/databinding-sdo/1.0- >>> incubator-M2/databinding-sdo-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/services/bindings/parent/1.0-incubator-M2/ >>> parent-1.0-incubator-M2.pom >>> org/apache/tuscany/sca/services/bindings/axis2/1.0-incubator-M2/ >>> axis2-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/services/bindings/rmi/1.0-incubator-M2/ rmi-1.0- >>> incubator-M2.jar >>> org/apache/tuscany/sca/services/maven/1.0-incubator-M2/maven-1.0- >>> incubator-M2.jar >>> org/apache/tuscany/sca/runtime/webapp-host/1.0-incubator-M2/webapp- >>> host-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/runtime/standalone/1.0-incubator-M2/ >>> standalone-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/runtime/standalone-host/1.0-incubator-M2/ >>> standalone-host-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/commands/parent/1.0-incubator-M2/parent-1.0- >>> incubator-M2.pom >>> org/apache/tuscany/sca/commands/launcher/1.0-incubator-M2/ >>> launcher-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/sca-tools/1.0-incubator-M2/sca-tools-1.0- >>> incubator-M2.jar >>> org/apache/tuscany/sca/plugins/parent/1.0-incubator-M2/parent-1.0- >>> incubator-M2.pom >>> org/apache/tuscany/sca/plugins/tuscany-war-plugin/1.0-incubator-M2/ >>> tuscany-war-plugin-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/plugins/tuscany-plugin-wsdl2java/1.0- incubator- >>> M2/tuscany-plugin-wsdl2java-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/plugins/tuscany-plugin-java2wsdl/1.0- incubator- >>> M2/tuscany-plugin-java2wsdl-1.0-incubator-M2.jar >>> org/apache/tuscany/sca/distribution/1.0-incubator-M2/ distribution-1.0- >>> incubator-M2.pom >>> org/apache/tuscany/sca/distribution/1.0-incubator-M2/ distribution-1.0- >>> incubator-M2-bin.zip >>> org/apache/tuscany/sca/distribution/1.0-incubator-M2/ distribution-1.0- >>> incubator-M2-bin.tar.gz >>> org/apache/tuscany/sca/samples/parent/1.0-incubator-M2/parent-1.0- >>> incubator-M2.pom >>> org/osoa/sca-api-r0.95/1.0-incubator-M2/sca-api-r0.95-1.0-incubator- >>> M2.jar >>> org/apache/tuscany/commonj-api_r1.1/1.0-incubator-M2/commonj- >>> api_r1.1-1.0-incubator-M2.jar >>> >>> - >>> 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] > > > -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report for December 2006
Please do this soon, i will consolidate the feedback tomorrow. Board meeting is next week. thanks, dims On 12/5/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Team, It's our turn again for reporting to the board. Please add notable happenings etc in your respective projects to the wiki page as usual: http://wiki.apache.org/ws/ReportForDec2006 All committers and PMC members..please help fulfill this duty to the Apache board. Please see old archived reports for inspiration. http://wiki.apache.org/ws/FrontPage/BoardReports thanks, dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report for March 2007
Team, It's our turn again for reporting to the board. Please add notable happenings etc in your respective projects to the wiki page as usual: http://wiki.apache.org/ws/ReportForMar2007 All committers and PMC members..please help fulfill this duty to the Apache board. Please see old archived reports for inspiration. http://wiki.apache.org/ws/FrontPage/BoardReports thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Jeremy, Please allow time for discussion. Please withdraw this vote as it is getting hijacked because discussion is not over yet. thanks, dims On 3/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Raymond Feng wrote: > Hi, > > Here's my vote. > > [X] +1 we should do this > [ ] -1 keep things as they are > > The vote is based on my understanding of the benefits of > interface-based models as follows. > > 1) Better pluggability for the model implementation and loading: We > can easily generate the model and loading code using Java/XML binding > frameworks such as JAXB, SDO and XMLBeans. > > 2) Better relationship between model objects: One java class can > implement multiple interfaces, for example, we can use "Extensible" > interface to represent the SCDL extensibilities and "Promotable" to > represent models eligible for promotion. > > 3) Better isolation for dependencies: Other modules only have to > depend on the model interfaces for compilation. We don't have to > release the model interfaces if we just have to fix issues in the > implementation classes without breaking the contract. > > 4) Simpler interface-based mocking for unit tests > > 5) Other projects use interface-based modeling such as Axiom, DOM, > WSDL4J and Woden > > Thanks, > Raymond > > - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, March 20, 2007 7:23 AM > Subject: [VOTE] Rewrite kernel model to be based on interfaces > > >> The current model is based on simple POJOs. Sebastien has proposed >> rewriting the configuration model to be based on interfaces with >> separate implementation and factory classes. This will have a major >> impact on the kernel code and all extensions. This vote is not about >> what is in the model, it's is about how the model itself is implemented. >> >> [ ] +1 we should do this >> [ ] -1 keep things as they are >> >> If I was going to vote I would probably vote +1 since I'm doing this work :) but I'm not ready to vote on it yet, as I'm not sure why a vote thread popped up so quickly, independent of the thread I started yesterday to get input from our community and have a technical discussion on the subject: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working in trunk, was: Componentizing our SCA runtime kernel
"we decided to abandon"...was there a VOTE? Please refresh my memory. thanks, dims On 3/21/07, Jim Marino <[EMAIL PROTECTED]> wrote: On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote: > Hi Sebastien > > My understanding is that these are separate modules that are not > going to > destabelize the trunk at the moment. My personal opinion is that it > would be > OK to have this work done in the trunk as most of new work is being > developed. The proposed model changes will require a significant re-write of the kernel and re-introduce an old design that we decided to abandon about a year ago. Is that what people want to do? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working in trunk, was: Componentizing our SCA runtime kernel
Got it! thanks. -- dims On 3/21/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: I think this was the final email, in the thread of discussion we had on different ways of doing the model. Ta Meeraj -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:54 AM To: tuscany-dev@ws.apache.org Subject: Re: Working in trunk, was: Componentizing our SCA runtime kernel "we decided to abandon"...was there a VOTE? Please refresh my memory. thanks, dims On 3/21/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote: > > > Hi Sebastien > > > > My understanding is that these are separate modules that are not > > going to destabelize the trunk at the moment. My personal opinion is > > that it would be OK to have this work done in the trunk as most of > > new work is being developed. > > The proposed model changes will require a significant re-write of the > kernel and re-introduce an old design that we decided to abandon about > a year ago. > > Is that what people want to do? > > Jim > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. -- Forwarded message -- From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Date: Tue, 18 Jul 2006 03:30:27 - Subject: Moving chianti to trunk With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Revolutions or a Mess!!
Folks, I don't really like what's going on. Too much conflicts between people. Whatever be the issue of the day, I see 2 sets of people in constant confrontation. The constant branching/merging is not healthy or productive. Is there any effort or hope of reconciliation or should we start looking at other options? Thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
Jeremy, I'd like to see some progress on the community front! Let's see this approach agreed upon and fleshed out a bit more. thanks, dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: > Jeremy. This sounds like a simpler approach than what is there now. > I like > the idea but a question. > > 1) move everything that does not logical depend on > org.apache.tuscany:sca:1.0-incubating to contrib > > from your previous definition do you mean those things that are not > considered to be independent. Or do you mean things that could be > independent but just aren't packaged that way now. I assume that > you mean > the latter as your next point is to go ahead and make them > independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. > > Also is the global parent version 1.0-incubating or 1.0-incubating- > SNAPSHOT. > I note that now you have it without SNAPSHOT but its children with > SNAPSHOT. > Are you just saying that the global parent doesn't get packaged/ > released > per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
Jeremy, Please take a look at axis2 poms and geronimo poms. you don't need to install the parent pom before building modules. you can specify relative path to the parent. -- dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: OK. If we're going to hold the vote, I'll pull the candidate artifacts. We can republish them later. That does mean that everyone will need to install the sca parent pom from the tag in SVN before any of the modules in trunk will build. -- Jeremy On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote: > Jeremy, > > I'd like to see some progress on the community front! Let's see this > approach agreed upon and fleshed out a bit more. > > thanks, > dims > > On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: >> > Jeremy. This sounds like a simpler approach than what is there now. >> > I like >> > the idea but a question. >> > >> > 1) move everything that does not logical depend on >> > org.apache.tuscany:sca:1.0-incubating to contrib >> > >> > from your previous definition do you mean those things that are not >> > considered to be independent. Or do you mean things that could be >> > independent but just aren't packaged that way now. I assume that >> > you mean >> > the latter as your next point is to go ahead and make them >> > independent. >> >> Yes things aren't really independent due to the intermediate poms in >> the physical directory tree. >> >> > >> > Also is the global parent version 1.0-incubating or 1.0-incubating- >> > SNAPSHOT. >> > I note that now you have it without SNAPSHOT but its children with >> > SNAPSHOT. >> > Are you just saying that the global parent doesn't get packaged/ >> > released >> > per-se SNAPSHOT or not. >> >> This is the pom defined in the tag here: >>https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ >> sca/1.0-incubating >> >> which is a stable artifact - one we have voted to release but are >> waiting for the IPMC to approve. It will not move. >> >> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS >> THREAD]] >>http://mail-archives.apache.org/mod_mbox/incubator-general/ >> 200703.mbox/[EMAIL PROTECTED] >> >> The things in trunk are not stable and so have a SNAPSHOT version. >> -- >> Jeremy >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > Developers > > - > 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] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
+1 to move back to "single version and a project you can build from the top with mvn" On 3/23/07, ant elder <[EMAIL PROTECTED]> wrote: On 3/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > OK, I give up on this, and I'll try not bring this subject up anymore !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are "independently versioned modules" worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? ...ant -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Objective of the following sandbox - tuscany/sandbox/sebastien/java
Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Back on the trunk
Folks, My 2 cents. Am looking for some serious commitment from everyone to work together on the branch. Please be civil, courteous to each other. It means don't just revert someone else's check-in because you don't like it. It also means don't use "-1" just because you can. Please don't go off on a tangent (sandbox/branch) at the drop of a hat. I hope everyone puts on their best behavior and do not engage in name calling. Please address everyone one as an individual and don't guess about someone's intentions. All of us wear multiple hats. If you want to know something from someone, just ask them directly. Please don't look for conspiracy scenarios. For the time being assume that everyone is starting fresh. I know it is too much to ask for after so much bad blood. Please don't let everyone's efforts go down the drain. Finally, everyone please get back on the trunk and get cranking. If we don't come together now as a community, we never will. thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
ployed artifacts they would depend on would >> be stable >> > released ones - this is directly inline with the stability goals >> > expressed by the likes of Dave Booz. In general, >> aggregations should >> > not depend on SNAPSHOTs or a head revision except where absolutely >> > necessary. >> > >> > Mario's pain was caused because we had not put together an >> assembly of >> > the modules needed for the demo. It was the wee hours of >> the morning, >> > I hope you understand. Once the dust settled, the modular, >> independent >> > nature of what we had allowed us to put together a very simple >> > assembly for building exactly that (independent of any >> other activity >> > in trunk). You can see this here: >> > >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- >> > demo >> > >> > > >> > > You also mentioned before that we have M2 experience >> of a top down >> > > build not working, I'm not sure about all the details >> that comes to >> > > your mind when you say that, but I remember some build >> brakes (and I >> > > think this is acceptable in trunk, right ?) >> > >> > No, not really. >> > >> > > and we could set some conventions like, modules that are >> "unstable >> > > at the moment" would be removed from the maven profile >> (and maybe a >> > > JIRA would be created)... later on, when the module is >> back to it's >> > > stability, whoever fixed the issue would close the JIRA (if >> > > any) and put the module back to the stable profile. >> > >> > The problem of this approach is that it couples everything >> together >> > through the parent pom. Even if a separate parent is used, >> the reactor >> > will attempt to use common dependency versions across the modules. >> > This means that modules get coupled together based on the >> versions of >> > their dependencies and so we lose the independence between them. >> > >> > Basically, unless they all use the same version then they >> won't all >> > build. >> > >> > > >> > > Also, this is not about MAVEN PROFILE versus ASSEMBLY. >> I'm sure >> > > both can co-exist together in perfect harmony, and it would >> > > definitely be a good solution for members of the >> community that are >> > > interested only in a subset of Tuscany (e.g some >> embedder that only >> > > requires the kernel, and a Spring extension for >> example), and these >> > > assembly modules could be created as needed >> > > >> > > These profiles would probably make the user experience >> of someone >> > > that comes to evaluate Tuscany trunk much easier, as already >> > > mentioned by Mario [1], and help others to be more productive as >> > > already expressed on various other threads [2][3]. >> > >> > This is where we disagree. Doing what you suggest couples >> all modules >> > at a single monolithic version level. That may be desirable in a >> > commercial product but is not a way to scale an open >> source community. >> > >> > One of the problems we have is that the documentation on >> the build and >> > the pom structure is misleading and confusing users. I >> wanted to clean >> > that up by removing bad poms such as java/pom.xml but was >> overruled. >> > >> > > >> > > If I understand your concerns, having the convention of moving >> > > unstable modules out of the maven profile should help, >> but maybe you >> > > could explain what worries you, that you are fighting so >> hard not to >> > > allow people to build different modules with a simple >> mvn command. >> > > Nevertheless, it's good practice to build before committ, right ? >> > >> > Please can we not make this personal - I am not fighting >> hard not to >> > allow anything. I am trying to find a middle ground that >> allows people >> > who need to build groups of modules to do so and at the same time >> > preserve the independence between the modules. >> > >> > I do not know of a way to make what you want work with >> independently >> > versioned modules. I have proposed something that people >> seemed to be >> > able to live with and which I believe works. Let's hear >> technically >> > viable alternatives. >> > >> > -- >> > Jeremy >> > >> > >> > >> - >> > 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. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ways of working together [was - RE: Build structure - having cake and still eating]
Meeraj, Thanks!. No, am not advocating any technical direction. That is for you all to decide. All i insist is that everyone converge on the trunk. That's where we will make releases from. thanks, dims On 3/24/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Dims, I am more than happy to find a middle ground where everyone can work together. I was just pointing out the technical issues with a top down pom. Worst case as a compromise, I may even agree to a top-down pom, even though I don't agree with it from a technical perspective, so that we can work together. On a side note what I suggested on the thread "Objective of the following sandbox", is that there had been lot of discussion and work in the last two months on stuff around the kernel. As I said, I am happy to discuss Sebastien's proposal. However, that should not be done in isolation. We should also take into consideration, the work we have done so far and why we want to start from scratch rather than improve the kernel incrementally. I am all for modularizing the kernel, this is something we all agree on. However, that doesn't mean we start from scratch. Some of the issues Sebastien has raised were discussed on the list more than ten moths ago, and we as a community took a decision to take the direction we now have in kernel. In my opinion that is water under bridge. However, if we need to go back and discuss those things again, I am happy to do it. But as I said, these discussions shouldn't be done in isolation, there should also be a strong rationale on what is so wrong with the current kernel, that it needs to be changed so drastically. Thanks Meeraj >> -Original Message- >> From: Davanum Srinivas [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 13:31 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> Meeraj, >> >> Using assemblies is ok. It does not have to be published. >> Once everyone is in the same bandwagon, then it's ok to >> publish. Till then, please find a way to work with >> assemblies w/o having to rely on published artifacts. If >> this is a maven problem, then find another way to solve the >> problem or ask at least raise an issue with maven folks. >> As for myself, am putting my foot down on publishing till >> everyone shares. This is getting more and more like 3-4 year >> olds in the sandbox not sharing their toys and saying hey >> you did not talk to me when i talked to you. So shut up now. >> Everyone has a life, everyone has priorities. When folks >> come to the table, the conversation should begin again. >> Again, Please figure out a way everyone can work. >> >> thanks, >> dims >> >> On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> > Luciano, >> > >> > Your hijacked version of pom portrays all the issues >> associated with a >> > top down pom with a single version in a complex project. You have >> > included the modules you want to build. It may not be of >> any use to >> > me, if I want to build a separate set of modules. So what >> is the point >> > in committing your pom to the source tree, if it is of use to only >> > yourself? >> > >> > Then the solution would be to build the whole thing. That >> would never >> > scale for complexity. Why would I want to build the whole kitchen >> > sink, if I am interested in building only a subset that is >> pertinent >> > to the task I am working on? A single version and top down >> build that >> > builds everything, IMHO, would create unnecessary coupling >> in complex projects. >> > >> > >> > If we rely on a top down build that builds everything, >> regardless of >> > area of the project we are working on, I would say we lack >> clarity in >> > terms of how the project is architecturally modularized. >> > >> > And for new comers to build samples, I agree with Jeremy >> that the best >> > thing to do is use mvn assemblies based on published artifacts. >> > >> > On a side note, I think you should never give up :) IMHO we should >> > have these constructive discussions, as long as they are >> in the best >> > interest of the community and the project. >> > >> > ta >> > Meeraj >> > >> > >> -Original Message- >> > >> From: Luciano Resende [mailto:[EMAIL PROTECTED] >> > >> Sent: 24 March 2007 00:05 >> > >> To: tuscany-dev@ws.apache
Re: Build structure - having cake and still eating
Jeremy, All excellent reasons!! Let's get a release out that everyone can back as a team and we can revisit this after that. For now, let's live with relativePath and it's consequences. No, please don't drag me into the technical discussions. that will make me take sides which i don't want to do. Objective again is to get a release out where all of us though unhappy for one reason or another but are willing to back it up as a community and works almost ok for all of us :) thanks, dims On 3/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 24, 2007, at 6:30 AM, Davanum Srinivas wrote: > Using assemblies is ok. It does not have to be published. Once > everyone is in the same bandwagon, then it's ok to publish. Till then, > please find a way to work with assemblies w/o having to rely on > published artifacts. If this is a maven problem, then find another way > to solve the problem or ask at least raise an issue with maven folks. Dims Our build to date relies on the ability to reuse stable, common definitions such as this: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating/pom.xml What we are talking about publishing here is one parent pom, in line with mvn best practice. I don't think anyone has any issue with what's in it. There are several ways in which this can "work" without publishing things, but all of them have technical disadvantages. For example, you can use in the parent element of your pom, but that ties the logical project structure to the physical directory structure. That precludes you from reusing unstable modules via svn externals or copy, and means that if you want to refer to stable modules users would need to check out from the root *INCLUDING ALL TAGS, BRANCHES AND C++ CODE.* This is not SVN best practice. We can fix that by restructuring the project so that tags live alongside modules but that is a fairly radical change in layout. Alternatively, we can remove the dependency on a parent and repeat the plugin definitions that it contains in the pom for every module. The disadvantage of course is that there is a lot of repetition of common definitions. This is not Maven best practice. A third option is simply not to use Maven, or perhaps to use a hybrid of Maven and something else (e.g. Ant). Finally, I understand the stick here, but there is a difference between waving the stick and beating people with it. Changing the rules on publication requires broad technical changes in the project going against best practice for the tools we use - I ask that you actively involve yourself in the discussions around those rather than just telling others to find a way to make it work. > As for myself, am putting my foot down on publishing till everyone > shares. This is getting more and more like 3-4 year olds in the > sandbox not sharing their toys and saying hey you did not talk to me > when i talked to you. So shut up now. Everyone has a life, everyone > has priorities. When folks come to the table, the conversation should > begin again. Again, Please figure out a way everyone can work. At the start of this thread, I thought we /were/ making progress with good discussion between myself, Raymond, Meeraj, Simon and Jim and general agreement on a compromise solution. Then Luciano throws his toys out the pram and we are back to square one. I am at the table and willing to keep talking. Maybe we should change the subject, perhaps "are independently versioned modules worth it?" -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt a near-zero-tolerance "Be Nice" policy
+1 from me. On 3/26/07, ant elder <[EMAIL PROTECTED]> wrote: I'd like to have a near-zero-tolerance "Be Nice" policy on the Tuscany mailing lists where we don't allow participants to slam anyone's posts. When replying to email we need to do it in a way that maintains the original authors dignity. We've some tough things to work out over the next days and we're only going to achieve any real consensus if we all feel the environment allows us to say what we really think. I'd really like to see everyone vote on this, surely if nothing else this is something we can all agree on? Here's my +1. ...ant -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt a near-zero-tolerance "Be Nice" policy
Touché :) On 3/26/07, Frank Budinsky <[EMAIL PROTECTED]> wrote: +1, and here's a first test case of saying what I "really think". I hope nobody is going to "slam" me :-) I think Ant's suggestion should go without saying. The fact that we need to have a vote as juvenile as this one, makes it hard for any of us to "maintain our dignity". Frank. "kelvin goodson" <[EMAIL PROTECTED]> wrote on 03/26/2007 02:38:51 PM: > +1 > > On 26/03/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > I'd like to have a near-zero-tolerance "Be Nice" policy on the Tuscany > > mailing lists where we don't allow participants to slam anyone's posts. > > When > > replying to email we need to do it in a way that maintains the original > > authors dignity. > > > > We've some tough things to work out over the next days and we're only > > going > > to achieve any real consensus if we all feel the environment allows us to > > say what we really think. > > > > I'd really like to see everyone vote on this, surely if nothing else this > > is > > something we can all agree on? > > > > Here's my +1. > > > >...ant > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discussion] Tuscany kernel modulization
"the wholesale, revolutionary rewrite of the kernel"...Pointers please to exact emails. thanks, dims On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: Nice diagram, Raymond, thanks for putting this together. What I'm struggling with is that this seems fairly similar to the way the code is organized now. Most of the boxes there already exist and have interfaces to abstract away their implementation. Everything in "Cross-cutting system services" is that way and the same for "Container/Binding/Databinding/IDL Extensions" and "Pluggable Federations." These are all components implemented using the Tuscany "system" programming model - basically, a simplified, POJO based IoC model decorated (to the least extent possible) with SCA annotations. Each of those components already has an interface to define the function it provides. We assemble those components using SCA assembly. That makes sense to me because as an SCA runtime we have to support SCA assembly - so not only will we need the code to do that, it makes things familiar to users as there is a common language. We could assemble the runtime another way, for example using Spring XML or Java code, but then users need to be familiar with two assembly mechanisms and that seems like confusing and unnecessary complexity. One reason the SPI module is so large is that it does define many the interfaces for the components in you diagram. I think there is room for a reorganization there to clarify the usage of those interfaces. I would propose we start with that rather than the wholesale, revolutionary rewrite of the kernel that has been suggested. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discussion] Tuscany kernel modulization
I don't see any of the following terms in those emails...Let me take another tack "I think there is room for a reorganization there to clarify the usage of those interfaces.". Can you please send a write up in wiki on how to do the reorganization. You can either augment/enhance what Raymond wrote or start fresh. thanks, dims On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15991.html r522186 r521957 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15318.html in relation to r517804 And, of course, the code in SVN. Lastly, we've been here before - r419320 -- Jeremy On Mar 27, 2007, at 2:35 PM, Davanum Srinivas wrote: > "the wholesale, revolutionary rewrite of the kernel"...Pointers please > to exact emails. > > thanks, > dims > > On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> Nice diagram, Raymond, thanks for putting this together. >> >> What I'm struggling with is that this seems fairly similar to the way >> the code is organized now. Most of the boxes there already exist and >> have interfaces to abstract away their implementation. Everything in >> "Cross-cutting system services" is that way and the same for >> "Container/Binding/Databinding/IDL Extensions" and "Pluggable >> Federations." >> >> These are all components implemented using the Tuscany "system" >> programming model - basically, a simplified, POJO based IoC model >> decorated (to the least extent possible) with SCA annotations. Each >> of those components already has an interface to define the function >> it provides. >> >> We assemble those components using SCA assembly. That makes sense to >> me because as an SCA runtime we have to support SCA assembly - so not >> only will we need the code to do that, it makes things familiar to >> users as there is a common language. We could assemble the runtime >> another way, for example using Spring XML or Java code, but then >> users need to be familiar with two assembly mechanisms and that seems >> like confusing and unnecessary complexity. >> >> One reason the SPI module is so large is that it does define many the >> interfaces for the components in you diagram. I think there is room >> for a reorganization there to clarify the usage of those interfaces. >> I would propose we start with that rather than the wholesale, >> revolutionary rewrite of the kernel that has been suggested. >> >> -- >> Jeremy >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > Developers > > - > 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] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discussion] Tuscany kernel modulization
Please keep Sebastien's emails in mind. Please don't throw all away all ideas from his work/email. The objective is to get everyone on the trunk. Let's try to find a way to get everyone to achieve their goals. We may not get there in the first release. But we should have a good story to go along with the release with end-to-end scenarios. Now, i'll shut up. It's upto you all to find the "Middle Way" literally. thanks, dims [1] http://en.wikipedia.org/wiki/Middle_way On 3/27/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: I don't see any of the following terms in those emails...Let me take another tack "I think there is room for a reorganization there to clarify the usage of those interfaces.". Can you please send a write up in wiki on how to do the reorganization. You can either augment/enhance what Raymond wrote or start fresh. thanks, dims On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15991.html > > r522186 > r521957 > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15318.html > in relation to > r517804 > > And, of course, the code in SVN. > > Lastly, we've been here before - r419320 > > -- > Jeremy > > On Mar 27, 2007, at 2:35 PM, Davanum Srinivas wrote: > > > "the wholesale, revolutionary rewrite of the kernel"...Pointers please > > to exact emails. > > > > thanks, > > dims > > > > On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> Nice diagram, Raymond, thanks for putting this together. > >> > >> What I'm struggling with is that this seems fairly similar to the way > >> the code is organized now. Most of the boxes there already exist and > >> have interfaces to abstract away their implementation. Everything in > >> "Cross-cutting system services" is that way and the same for > >> "Container/Binding/Databinding/IDL Extensions" and "Pluggable > >> Federations." > >> > >> These are all components implemented using the Tuscany "system" > >> programming model - basically, a simplified, POJO based IoC model > >> decorated (to the least extent possible) with SCA annotations. Each > >> of those components already has an interface to define the function > >> it provides. > >> > >> We assemble those components using SCA assembly. That makes sense to > >> me because as an SCA runtime we have to support SCA assembly - so not > >> only will we need the code to do that, it makes things familiar to > >> users as there is a common language. We could assemble the runtime > >> another way, for example using Spring XML or Java code, but then > >> users need to be familiar with two assembly mechanisms and that seems > >> like confusing and unnecessary complexity. > >> > >> One reason the SPI module is so large is that it does define many the > >> interfaces for the components in you diagram. I think there is room > >> for a reorganization there to clarify the usage of those interfaces. > >> I would propose we start with that rather than the wholesale, > >> revolutionary rewrite of the kernel that has been suggested. > >> > >> -- > >> Jeremy > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > > Developers > > > > - > > 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] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Jim, Meeraj, If the stream of -1's contnue, am afraid there isn't going to be a single release at all. thx, dims On 3/28/07, Jim Marino <[EMAIL PROTECTED]> wrote: On Mar 28, 2007, at 12:51 AM, ant elder wrote: > Here's the vote on this I said [1] I'd start to get closure on this > issue. > > The proposal is to have top-level pom for the Java SCA project that > enables > building all the modules together - kernel, services, runtimes, > extensions > etc, and for that to work all those modules need to use the same > version > name. > > Here's my +1. > > ...ant > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > msg16024.html There has been no proposal for how to resolve the issue about building extensions using multiple versions of kernel and how modules on different release schedules requiring different levels of kernel or plugins will be handled. Until we can come up with a solution for these issues, I feel I have to vote against the proposal. -1 Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Meeraj, well go over the archives and count how many times you, jim and jeremy have -1'ed something. The correct vote for "I am happy to go with the majority view, if that is what the community wants." is -0 *NOT* -1. When you do a -1 you are supposed to work hard to come up with a refined proposal that takes in your viewpoint or help come up with a proposal that evertone can rally around. I see no effort in consensus building in any of the threads i reviewed after a -1. This is an open source project, you can have the best goddamn architecture in the whole wide world. If there is no community to back the work. It will get thrown out of the incubator. Sorry, that's the way Apache works. Incubator is not only for legal purposes but also to help build communities. This is not the way an open source project should work. Forget about incubator projects, we have closed Top level project (example Avalon) too because everyone was at cross purposes and no one was cooperating with any one else. Yes, a few of the people who started the fracas did say exactly what you said.."I disagree fundamnetally from a technical perspective". See this email and check if it is the same situation you all are in. Finally did the three of you VOTE in the "Be Nice" thread? That just tells me a lot of things. thanks, dims [1] http://mail-archives.apache.org/mod_mbox/avalon-dev/200211.mbox/[EMAIL PROTECTED] On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Dims, I don't think there is a stream of -1s. This is an issue on which, unfortunately, I disagree fundamnetally from a technical perspective, with the percieved majority view. It will be hypocritical of me to +1, if I don't agree with it. However, I am happy to go with the majority view, if that is what the community wants. Ta Meeraj From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wed 3/28/2007 11:24 PM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together Jim, Meeraj, If the stream of -1's contnue, am afraid there isn't going to be a single release at all. thx, dims On 3/28/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > On Mar 28, 2007, at 12:51 AM, ant elder wrote: > > > Here's the vote on this I said [1] I'd start to get closure on this > > issue. > > > > The proposal is to have top-level pom for the Java SCA project that > > enables > > building all the modules together - kernel, services, runtimes, > > extensions > > etc, and for that to work all those modules need to use the same > > version > > name. > > > > Here's my +1. > > > > ...ant > > > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > > msg16024.html > > > > There has been no proposal for how to resolve the issue about > building extensions using multiple versions of kernel and how modules > on different release schedules requiring different levels of kernel > or plugins will be handled. > > Until we can come up with a solution for these issues, I feel I have > to vote against the proposal. > > -1 > > Jim > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany / Avalon
Bringing this up since i see many many parallels between what's happenning here now and what happened with Avalon. Please don't let this [4] happen here. [1] http://mail-archives.apache.org/mod_mbox/avalon-dev/200211.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/avalon-dev/200211.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/avalon-dev/200412.mbox/[EMAIL PROTECTED] [4] http://avalon.apache.org/closed.html -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] Next version - What should be in it
Folks, Let's keep the ball rolling...Can someone please come up with a master list of "extensions, bindings, services, samples" which can then help decide what's going to get into the next release. Please start a wiki page to document the master list. Once we are done documenting the list. We can figure out which ones are MUST, which ones are nice to have, which ones are out of scope. Then we can work backwards to figure out How tightly or loosely coupled each piece is/should be and how we could decouple them if necessary using interfaces/spi/whatever... Quote from Bert Lamb: "I think there should be a voted upon core set of extensions, bindings, services, samples, whatever that should be part of a monolithic build." http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html Quote from Ant Elder: The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html Thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Jim, I started another DISCUSS thread to "look at these", you still need to let everyone know what you think of this VOTE. thanks, dims On 3/29/07, Jim Marino <[EMAIL PROTECTED]> wrote: On Mar 29, 2007, at 10:28 AM, Jeremy Boynes wrote: > On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: > >> Hi Jeremy, >> >> Here is a problem that most of us are facing with the Trunk and is >> hindering >> us to effectively contribute to the trunk. I see there is one >> solution that >> has been proposed to making this simpler with some compromises. >> If this is >> not agreeable what is the alternative for those of us who are >> waiting for a >> solution to this. Whats the simple way for any of us - including >> somebody >> getting in afresh - to quickly jump in and start contributing >> without having >> to worry about the build intricacies. Should we consider Bert's >> suggestion? > > At the moment, this is a straight up/down binary vote on a fairly > vague proposal, one that some people have specific technical > concerns over. There are other proposals out there but we seem to > have lost sight of that. IMO, yes, we should consider Bert's > proposal, and mine for assemblies, and anything else anyone can > think of that is less divisive. > I'd prefer we look at these as well. Jim --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Jeremy, I started another DISCUSS thread to "keep talking", you still need to let everyone know what you think of this VOTE. thanks, dims On 3/29/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote: > Hi Jeremy, > > Here is a problem that most of us are facing with the Trunk and is > hindering > us to effectively contribute to the trunk. I see there is one > solution that > has been proposed to making this simpler with some compromises. If > this is > not agreeable what is the alternative for those of us who are > waiting for a > solution to this. Whats the simple way for any of us - including > somebody > getting in afresh - to quickly jump in and start contributing > without having > to worry about the build intricacies. Should we consider Bert's > suggestion? At the moment, this is a straight up/down binary vote on a fairly vague proposal, one that some people have specific technical concerns over. There are other proposals out there but we seem to have lost sight of that. IMO, yes, we should consider Bert's proposal, and mine for assemblies, and anything else anyone can think of that is less divisive. > Theres been may a time when you have helped us out of various > technical > difficulties. Here is yet another time I request for help from you > for a > way out of this. Thanks. My suggestion is, keep talking. The important thing here is about seeing if we can work together to reach consensus. What the technical outcome is really doesn't matter. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving on
Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving on
Let's wait and see. No clue yet. Clearly some people value their technical prowess more than their desire to build community. thanks, dims On 3/31/07, Valerio Schiavoni <[EMAIL PROTECTED]> wrote: Is this a fork of Tuscany ? If so, I would be a bit disappointed... On 3/31/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Team, > > FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. > http://code.google.com/p/fabric3/ > > Please wish them best of luck. > > thanks, > dims > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://valerioschiavoni.blogspot.com http://jroller.com/page/vschiavoni - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving on
That's why i said "Let's wait and see. No clue yet." :) -- dims On 3/31/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: So far this is just a lot of speculation - all we have is a project name and three people. If Asankha and I happened to set up a code.google project I don't think it would be fair to assume we were deserting Synapse! Paul On 3/31/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Let's wait and see. No clue yet. Clearly some people value their > technical prowess more than their desire to build community. > > thanks, > dims > > On 3/31/07, Valerio Schiavoni <[EMAIL PROTECTED]> wrote: > > Is this a fork of Tuscany ? > > > > If so, I would be a bit disappointed... > > > > On 3/31/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > Team, > > > > > > FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. > > > http://code.google.com/p/fabric3/ > > > > > > Please wish them best of luck. > > > > > > thanks, > > > dims > > > > > > -- > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > http://valerioschiavoni.blogspot.com > > http://jroller.com/page/vschiavoni > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN layout
+1 from me.
On 12/17/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> Before we import any code I think we should give a little thought to how
> we would like to lay out the repository. With the number of bits and at
> least two different languages this will be a little trickier than usual.
>
> I think that it is important that someone can checkout a single URL and
> expect to get to work. That means that all the things they are likely to
> be working on should be grouped together. However, this should not
> result in multiple versions of a project being checked out due to SVN
> tags being located together.
>
> It should also be easy to tag/branch a module so that people can work on
> revolutionary changes in a private area without having to check out the
> entire tree.
>
> With that in mind, I'd like to suggest the following initial tree under
> https://svn.apache.org/repos/asf/incubator/tuscany/
>
> site # tree for the website
> java # main development tree for Java implementation
> java/spec/... # tree for spec artifacts
> java/sdo/... # tree for the SDO runtime
> java/das/... # tree for the DAS runtime
> java/sca/... # tree for the SCA runtime
> java/tools/...# tree for tools
> java/samples/... # tree for samples of all technologies
> java/testing/... # tree for acceptance/compatibility testsuite
> cxx # main development tree for C++ (structure like java tree)
> branches/${branchName}/...# a copy of any subtree from above
> tags/${tagName}/... # a tag of any subtree above
> sandbox/${name}/... # a experimental copy of any subtree
>
> This is close to the current layout with a few minor changes.
> Thoughts?
> --
> Jeremy
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: PHP subproject
Hi,
in addition to this list, please jump on axis-c-dev@ mailing list we
are doing a Axis2/PHP based on Axis2/C. we need help with that.
thanks,
dims
On 12/19/05, Lee Provoost <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm a master computer science student at the software technology group
> of the university of utrecht (netherlands). SOA technologies will be
> part of my master thesis and the Tuscany project seems very interesting
> for my project. I have also years of experience in PHP, I did several
> projects for insurance companies and software companies and I am very
> interested in participating in the PHP subproject.
>
> Can anyone give me some pointers to material or persons to talk to
> regarding this sub project? In a later stage I would also be interested
> in being involved in the BPEL subproject.
>
> Kind regards
>
> Lee Provoost
>
> --
> Lee Provoost
> Software Technology Group
> Department of Information and Computing Sciences
> University of Utrecht, P.O. Box 80089 3508 TB, Utrecht, The Netherlands
> {l.provoost} @students.uu.nl
> http://blogs.webcoder.be/lee
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Please add the following IONA engineers as Tuscany submitters...
Michael, Please go through how Apache works: http://www.apache.org/foundation/how-it-works.html#meritocracy Thanks, dims On 12/21/05, Greenberg, Michael <[EMAIL PROTECTED]> wrote: > Hello, > > I propose that the following IONA engineers be added as committers to > the Tuscany project: > > Michael Greenberg[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED]> > Adi Sakala[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > Steve Vinoski[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > Dan Kulp [EMAIL PROTECTED] > mailto:[EMAIL PROTECTED]> > Andrea Smyth[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED]> > > Our intentions are to contribute to the integration of Tuscany with > Celtix. > > Sincerely, > Mike > > Michael J. Greenberg > Director of Engineering -- SOA Networks > [EMAIL PROTECTED] > - > IONA Technologies, Inc. > 200 West Street > Waltham, MA 02451 USA > Tel: (781) 902-8160 > Fax: (781)-902-8001 > Cell: (603)-767-1244 > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Response to Dims...
Michael, Welcome to the group! It's a bit late in the process, we will have to use the normal yardstick. Please start looking at the code in JIRA and posting patches, questions etc.and we will see how it goes from there. Looking forward to working with you all. thanks, dims On 12/22/05, Greenberg, Michael <[EMAIL PROTECTED]> wrote: > Hi Dims, > > Sorry, I am not yet a subscriber (but soon will be!) to this mailing > list so I couldn't respond to your message. My colleagues drew my > attention to it, though. > > Apologies for any confusion created by my e-mail yesterday. I realize it > appears as though I didn't understand the normal process for becoming a > committer to an Apache project. The reason for my post was that the > initial Tuscany committers had asked if IONA would be willing to have > engineers be among the initial committers. There were several > volunteers, however they were omitted due to a miscommunication. I was > asked to correct this by sending an e-mail to the initial committers, > and I thought sending the request to this mailing list was the best way > to do that. > > I do realize that once a project starts at Apache, new committers are > only selected based on merit. I will leave it to the WS PMC to determine > whether you see what we're trying to do here as correcting an > administrative error, or if you would prefer to evaluate the merit of > each proposed IONA contributor individually. In either case, all the > individuals identified in my e-mail yesterday are willing to contribute > to this project. > > Sincere regards, > Mike > > > Michael J. Greenberg > Director of Engineering -- SOA Networks > [EMAIL PROTECTED] > - > IONA Technologies, Inc. > 200 West Street > Waltham, MA 02451 USA > Tel: (781) 902-8160 > Fax: (781)-902-8001 > Cell: (603)-767-1244 > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Eclipse dependencies
Nice! thanks. On 12/30/05, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > FYI, i asked the maven team to upload all needed eclipse dependencies on > ibiblio. > > See http://www.ibiblio.org/maven2/org/eclipse/ > > Cheers, > Guillaume Nodet > > -- Davanum Srinivas : http://wso2.com/blogs/
Fwd: pruning projects @ ws
Folks, OOPS! forwarding again with correct bcc's. These are my thoughts...what do you all think? We are spreading our efforts too thin and we need to seriously think about down-sizing a bit and focusing our efforts. Feel free to start a separate thread for a specific project(s) that you are interested in keeping alive. Addressing: Not much traffic/activity. Can we collapse this into Axis 1.X since it is specific to that version EWS : Not much traffic/activity. Archive it? Mirae : Not much traffic/activity. Archive it? Muse : Not much recent activity. Can we do one single project with Muse/Pubscribe/WSRF Pubscribe : Not much recent activity. Can we do one single project with Muse/Pubscribe/WSRF WSRF : Not much recent activity. Can we do one single project with Muse/Pubscribe/WSRF Scout : Donate to Geronimo? SOAP : Time to pull the plug? Archive it? TSIK : Not much traffic/activity. Think about stopping incubation? WSIF : Last legs? Time to pull the plug? Of course, if any project (not just the ones listed above) wants to become a separate TLP, that's another option as well. Thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/
Re: port build to maven2
Usual process is as follows - Open a JIRA bug, run "svn diff" on your box, zip up the output, upload the zip to JIRA, make sure you grant the license to ASF (there's a choice when u upload the files). thanks, dims On 1/9/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > If no one else is working on this, and there is consensus > > that it is a desirable thing to do, I volunteer to port > > the build to maven2. > > > > Is there a patch submission mechanism for folks who are > > not committers? > > > > > Thanks Jack! > > We're in the process of establishing the new project layout so this is > probably the right time to do this. On the other hand we need to make > sure that Maven 2 is stable enough. I think we can keep both the maven 1 > and 2 builds in place until we get maven 2 working well, and then decide > when we want to phase out the maven 1 build. > > So I'm +1 on this. What do the other people in the group think? > > I'm expecting to find an Apache convention / best practices for > submitting patches. Maybe Ken, Jeremy or Eddie can jump in and describe > to the group how they've been handling patches on other Apache > projects? or point us to a document on the Apache site describing the > usual process? > > -- > Jean-Sebastien Delfino > > -- Davanum Srinivas : http://wso2.com/blogs/
Fwd: Preparing the Incubator Quarterly Board Report for 2006Q1
Folks, Can you please add information about current status of your projects etc in this wiki page? Any tidbits even small is useful. thanks, dims -- Forwarded message -- From: Noel J. Bergman <[EMAIL PROTECTED]> Date: Jan 10, 2006 11:11 PM Subject: Preparing the Incubator Quarterly Board Report for 2006Q1 To: general@incubator.apache.org I have prepared a Wiki page to help prepare this quarter's board report. http://wiki.apache.org/incubator/IncubatorBoardReport2006Q1 Please edit your section by FRIDAY, JANUARY 13, 2006. Every project is expected to provide a quarterly report. If I missed a section, you are still required to contribute to the quarterly report, so please just add yourself. Mentors: you are not required to author the content, but you are responsible to make sure that it gets done. Please let us know of any issues, such as legal, community growth, remaining criteria to be satisfied before the project can graduate from the Incubator, how Incubation is going, anything that we can do to improve the Incubation experience, etc. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/
Re: Tuscany website
i added links from main ws page as well :) http://ws.apache.org/ -- dims On 1/12/06, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > The main page of the Tuscany web site is now live at: > > http://incubator.apache.org/tuscany/ > > I am working to get all the subsidiary pages up and live > on the site. > > > Mike Edwards. > -- Davanum Srinivas : http://wso2.com/blogs/
Re: CTR Policy
yep. that's the default. On 1/12/06, Kevin Williams <[EMAIL PROTECTED]> wrote: > Will we be following the Commit-Then-Review policy to apply code changes? > Thanks, > --Kevin > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: AXIS2 integration (SDO<-->AXIOM and more...)
FYI, we are using woostox in Axis2 (http://woodstox.codehaus.org/) as the stax parser. -- dims On 1/12/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > Raymond, > > Since SDO 2 is trying to encapsulate (hide) EMF in its implementation, I > suppose this is a proposal for the SDO 2 project. Maybe it would be even > better to provide these more generally in the EMF project at Eclipse and > then we just provide access to them through SDO 2. Have you discussed this > with the EMF team at Eclipse? > > I thought that SDO/EMF <--> DOM was already working. What problems did you > find? > > I also thought SAX --> SDO should already work ... just not the other > direction. Isn't that right? > > Regardless of where we implement these functions, we'd need someone to > write them ... any volunteers? > > One thing that I'm wondering about is where does the StAX implementation > come from. I thought it wasn't going to available until JDK 1.6? > > Frank. > > "Raymond Feng" <[EMAIL PROTECTED]> wrote on 01/11/2006 08:17:36 PM: > > > I would like to start the disucssion on AXIS2 integration for Tuscany. > > > > I started to prototype the AXIS2 support for Tuscany web service > > binding. Following the similar approach as we do for Axis 1.x, the > > key enabling factor is the serialization/deserialization from SDO to > > AXIOM and vice versa. Generally speaking, it's all about the > > transformations between different XML bindings for the same data. > > Please see the attached the diagram for some examples. > > > > As the default data model for Tuscany, SDO DataObject is used to > > represent the input/output/fault message for web services. (Later > > on, it could be pluggable.) > > > > In Axis 1.x, the SOAP envelope is a DOM-based model. > > > > Serialization: SDO --> DOM (SOAP) > > Deserialization: DOM --> SDO > > > > Due to some issues of the DOM support in the SDO 1.0 implementation, > > we made some workarounds in the current code base. So the real path > > may look like this: > > > > Serialization: SDO --> String --> SOAP > > Deserialization: SOAP --> String --> SAX --> SDO > > > > In Axis 2, SOAP messages are modeled using AXIOM (AXis Object Model) > > which is an XML object model working on StAX (Streaming API for XML) > > parsing optimized for SOAP 1.1/1.2 Messages. The ideal path should be: > > > > Serialization: SDO --> StAX --> SOAP (AXIOM) > > Deserialization: SOAP (AXIOM) --> StAX --> SDO > > > > The StAX support is not there yet in the current SDO implementation. > > So I took a hacky way and managed to make this path work with the > > Axis2 0.93 driver for the outbound Web Service call. > > > > Serialization: SDO --> AXIOM (by the special XMLSaveImpl which > > creates AXIOM attributes/elements/text in a similar way as DOM) > > Deserialization: AXIOM --> StAX --> StAX2SAXAdapter --> SAX --> SDO > > > > Now it becomes desirable to have a set of flexible SDO2 > > serializer/deserializers (or XMLResource in the SDO/EMF term) as > follows: > > > > SAX: Generate SAX events from DataObject and load DataObject from SAX > events > > Stax: Implement StAX XMLStreamReader for a given DataObject and load > > DataObject from XMLStreamReader (potentially can support lazy- > > loading of DataObject?) > > DOM: Create DOM tree from DataObject and load DataObject from DOM > > > > IMHO, these utilities will not only benifit the SDO/Axis > > integration, but also the transformation between SDO and other > > models like JAXB and XMLBeans. > > > > Ideas? Opinions? > > > > Thanks, > > Raymond > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Support for RPC encoded web services?
Jack, Could u please hop over to axis-dev@ to pitch in towards rpc/encoded stuff? thanks, dims On 1/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > ant elder wrote: > > > > There's still lots of RPC-encoded services out there so not supporting > > it at all seems a bit harsh, be more user friendly to take the Axis2 > > approach aim for 80% support. Could you post the code somewhere that > > you say needs porting over? > > I am interested in support for RPC-encoded services, too, so I'm > willing to help work on this. > > -- > Jack Unrue > [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Roadmap for the next few weeks
Guys, Just because you told us, we ripped out axiom and it is now in ws-commons :) -- dims On 2/14/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Jim Marino wrote: > > > >>No problem that you are not Lance ;) I think a JMS binding > >>would be great. One of the work items we need to do is to > >>figure out a new binding strategy, particularly as we migrate > >>to Axis2. I think it would be a good idea to also validate this > >>against a JMS binding. I have the start of some ideas for that > >>I'll post to the list so we can begin discussion. I think the > >>binding work can be done in parallel to some of the changes we > >>are making in the proxy/wire/invocation/ builder layer. So, > >>when I'll try and write up those thoughts and we can discuss > >>in more detail. > > > > > > Sounds good. Dims has on a couple occasions invited me to get > > involved with Axis2, which is a fine idea, but I'm not sure why > > non-SOAP bindings such as JMS (or File, Email, etc) have to be > > integrated into Tuscany via a SOAP stack. Or am I misunderstanding > > what Axis2 is bringing to the table as far as Tuscany is > > concerned? > > > > I can see cases where an XML infoset is being sent over these type of > transport and I think Axis2 would provide a lot of infrastructure for > doing that. > > However, there will also be cases where a non-XML representation is > being used and other binding mechanisms would be more applicable. > > I think we need the flexibility here to support all these types of binding. > > -- > Jeremy > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Does the webservice EP servlet need to create a HttpSession?
Yes, this can be deferred. Please log a bug report (patch would be
even better :)
-- dims
On 3/5/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> In WebServiceEntryPointServlet:
> private static SessionContext
> getSessionContext(HttpServletRequest httpServletRequest) {
> HttpSession httpSession = httpServletRequest.getSession(true);
>
> This forces a session to be created so that a Axis2 SessionContext
> object can be associated with it. Creating a session adds quite a lot of
> overhead for a web container especially in distributed configurations.
>
> Is this something that Axis2 requires or is there a way to defer this
> until some operation actually requires it?
>
> --
> Jeremy
>
--
Davanum Srinivas : http://wso2.com/blogs/
Fwd: Board Report for Mar 2006
BCC forwarding to all the dev lists. -- Forwarded message -- From: Davanum Srinivas <[EMAIL PROTECTED]> Date: Mar 11, 2006 7:26 AM Subject: Board Report for Mar 2006 To: "general@ws.apache.org" Team, Please update the board report page with notable happening (releases, committers etc): http://wiki.apache.org/ws/ReportForMar2006 Old reports are available for comparison: http://wiki.apache.org/ws/FrontPage/BoardReports thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ -- Davanum Srinivas : http://wso2.com/blogs/
Re: Component replacement and random thoughts....
Daniel, Does [1] mean that there is no com.sun / jax-ws RI dependendency anymore in Celtix? thanks, -- dims [1] http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/celtix?view=rev&rev=742 On 3/17/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > (I apologize in advance for the length of this email... After meeting > with Jim and Sebastien for the last two days, there are a LOT of thoughts > swirling around in my head) > > One of the questions that came up in the discussions was something along > the lines of "if a user wants to replace the Axis 2 ws implementation > with Celtix, how would they do it?"Or, more generally: "In tuscany, > if I want to replace with where is functionally > equivalent, how can I do it?" ( being a binding.*, container.*, > etc...) > > The "simple" answer is something along the lines of: delete the jars, > add the jars, muck with the classpath, done.However, that really > sucks. Telling users to muck with things down on that level is usually > not a good idea and can generally result in bad things happening.The > other problem with this approach is that there is no way that a user > could use BOTH and in the same system since is completely > deleted. > > One idea I came up with is a concept of "aliasing".All components > would always register with a very specific name. Instead of binding.ws, > it would be binding.axis2; instead of container.js, it would be > container.rhino, etc... Tuscany would then have some configuration > that would "bind" the specific name to the "generic" name. This could > come from a config file, a system property, etc If the user want > to change the underlying implementation of one of the generic > > One advantage of this that the user then has more control in their > assembly.If they want to use a more "portable" form and allow the > sca/tuscany runtime to use the default, they can do something like > "implementation.js" or "binding.ws" and the tuscany runtime would use the > appropriate one that is configured.However, if the user wants the > specific version (using some advanced feature of axis or something...), > they can specifically use "binding.axis2" or "implementation.rhino". It > allows complete coexistence. In a module, you could actually use both > "binding.axis2" and "binding.celtix" as well as the default "binding.ws" > that may or may not point to one of them. > > > The next "issue" this brings up is how to provide a usable system if the > user HASN'T configured anything (zero config) as well as validate that a > user that has configured something hasn't shot themself in the foot.On > thought with this is that when something registers with the system, it > not only registers it's name, but also can return a list of services it > can provide.Example:Name: binding.axis2, Provides: binding.ws > > With that additional bit of information, the runtime could automatically > wire stuff up with no configuration as well as validate configuration. > (example: I alias "binding.ws" to "binding.jsonrpc". That shouldn't > work since jsonrpc doesn't provide that service.) In the case where > there are two or more implementations that provide a service, it could be > a "first one registered" or "undetermined" or anything. The other > thing about this is that a single "thing" could possibly provide > multiple services.Example:Name: binding.celtix Provides: > binding.ws, binding.corba, binding.blah) > > Anyway, I just wanted to start a discussion about this.This is going > to be important as we start getting Celtix more integrated. > > Thanks! > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Component replacement and random thoughts....
Nice work! -- dims On 3/17/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > Basically, that commit removed the Sun Reference implementation of JAXWS. > However, we still require the jaxws API jar (since that is our public > API) and we still use the Sun JAXB 2.0 reference implementation (until > someone creates an open source alternative) and the Sun SAAJ 1.3 > reference implementation (until we find another implementation with less > bugs or have time to fix the bugsin one of the open source alternatives). > I think we also currently use the Sun StAX parser, but I'm going to try > to move that to woodstox next week. > > Of course, we need a BUNCH of the Sun API jars. activation, jsr250, jms, > jsr181, jaxws, jaxb, jsr173, saaj, etc > > Basically, up to that point, we had been using the JAX-WS reference > implementation code generator.For some reason, their code generator > jar also required their runtime jar. (which seems completely backwords > to me) This commit switched us completely over to our own code > generator which allowed us to completely remove the Sun reference impl > runtime jar and tools jar. > > Enjoy! > Dan > > > On Friday 17 March 2006 15:39, Davanum Srinivas wrote: > > Daniel, > > > > Does [1] mean that there is no com.sun / jax-ws RI dependendency > > anymore in Celtix? > > > > thanks, > > -- dims > > > > [1] > > http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/celtix?view=rev&rev= > >742 > > > > On 3/17/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > (I apologize in advance for the length of this email... After > > > meeting with Jim and Sebastien for the last two days, there are a LOT > > > of thoughts swirling around in my head) > > > > > > One of the questions that came up in the discussions was something > > > along the lines of "if a user wants to replace the Axis 2 ws > > > implementation with Celtix, how would they do it?"Or, more > > > generally: "In tuscany, if I want to replace with where > > > is functionally equivalent, how can I do it?" ( being a > > > binding.*, container.*, etc...) > > > > > > The "simple" answer is something along the lines of: delete the > > > jars, add the jars, muck with the classpath, done.However, > > > that really sucks. Telling users to muck with things down on that > > > level is usually not a good idea and can generally result in bad > > > things happening.The other problem with this approach is that > > > there is no way that a user could use BOTH and in the same > > > system since is completely deleted. > > > > > > One idea I came up with is a concept of "aliasing".All components > > > would always register with a very specific name. Instead of > > > binding.ws, it would be binding.axis2; instead of container.js, it > > > would be container.rhino, etc... Tuscany would then have some > > > configuration that would "bind" the specific name to the "generic" > > > name. This could come from a config file, a system property, > > > etc If the user want to change the underlying implementation > > > of one of the generic > > > > > > One advantage of this that the user then has more control in their > > > assembly.If they want to use a more "portable" form and allow the > > > sca/tuscany runtime to use the default, they can do something like > > > "implementation.js" or "binding.ws" and the tuscany runtime would use > > > the appropriate one that is configured.However, if the user wants > > > the specific version (using some advanced feature of axis or > > > something...), they can specifically use "binding.axis2" or > > > "implementation.rhino". It allows complete coexistence. In a > > > module, you could actually use both "binding.axis2" and > > > "binding.celtix" as well as the default "binding.ws" that may or may > > > not point to one of them. > > > > > > > > > The next "issue" this brings up is how to provide a usable system if > > > the user HASN'T configured anything (zero config) as well as validate > > > that a user that has configured something hasn't shot themself in the > > > foot.On thought with this is that when something registers with > > > the system, it not only registe
Re: Project structure
dependencies > > * provides the fabric for the runtime (Contexts) > > * provides APIs for providing plugin extensions > > * provides SPIs for embedding in host environments > > * can be built separately and used by extensions in binary form > > (implying versioning and stability on the extension APIs) > > * has a rule that incompatible changes to the API require the changer > > to upgrade and test all extensions in the Tuscany project and with > > a specific vote to accept them > > > > Baseline services that are distributed with the core that: > > * provide a deployment model for extensions (include loading, > > context building, package handling (classpath)) > > * provide critical system services (monitoring, admin enablement) > > * provide system services needed to support baseline extensions > > (security provider, transaction manager, work manager, ...) > > * has the same rule on API changes for those services as the core > > > > Baseline extensions that are distributed with the core: > > * programming models that are part of the specification > > (currently Java, futures being C++, Spring, J2EE, BPEL, ...) > > * transport bindings that are part of the specification > > (currently WS, futures being JMS, ...) > > * data bindings that are part of the specification > > (currently SDO, futures being JAXB, ...) > > * policy handlers that are part of the specification > > (futures being Security, Transaction, ...) > > > > Optional services that can be used to extend the runtime: > > * programming models that are not part of the specification > > (currently JavaScript, future being PHP, ???) > > * transport bindings that are not part of the specification > > (currently JSON-RPC, future being ???) > > * data bindings that are not part of the specification > > (currently JSON, future being ???) > > * services for use by applications > > (database access, DAS implementations, directory access, ...) > > * these would be released separately and could be deployed > > to a host environment by a user > > > > Host integrations that provide installable distributions: > > * provide implementations of the core's SPIs that allow > > Tuscany to run in different environments. > > (currently J2SE, J2EE WAR and Tomcat, > >future being full J2EE, Geronimo, OSGi(Eclipse), ...) > > * provide installable distributions that include all the > > baseline compoments applicable to that environment > > * provide "extended" distributions tailored to different > > user communities that include selected optional services > > > > Sample and demo applications that: > > * show key concepts from the SCA programming model > > (currently helloworld) > > * show how to build a large scale application > > (currently bigbank) > > * show how to use Tuscany in different environments > > > > Testing > > * compliance test for the specification (when available) > > * pre-release tests for Tuscany > > * ALL modules above should test their own functionality > > (at both the unit and integration levels) as part of their > > own build. No manual setup should be required. > > > > > > Given that, I would suggest the following changes to the project layout: > > > > sca/ > > # "core" system > > sca/system/common > > sca/system/model > > sca/system/core > > > > # "baseline" services and extensions > > sca/baseline/service/monitor > > sca/baseline/service/security > > sca/baseline/service/transaction > > sca/baseline/service/work > > sca/baseline/container/java > > sca/baseline/transport/axis2 > > sca/baseline/data/sdo > > sca/baseline/policy/security > > > > # "optional" services and extensions > > sca/extension/container/rhino > > sca/extension/transport/jsonrpc > > sca/extension/data/json > > sca/extension/service/jndi > > sca/extension/service/jdbc > > > > # host environment integration > > sca/host/tomcat/runtime# integration code > > sca/host/tomcat/testing# integration testing > > sca/host/tomcat/win32 # packaging for release > > sca/host/j2se/runtime # etc... > > > > # samples and testing modules that are not part of a developer build > > sca/samples/helloworld/j2se > > sca/samples/helloworld/war > > sca/samples/bigbank > > sca/testing/compliance > > > > Thoughts? > > -- > > Jeremy > > > > Mime > Unnamed multipart/alternative (inline, None, 0 bytes) > Unnamed text/plain (inline, Quoted Printable, 5928 bytes) > View raw message > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Project structure
Assuming u are talking about the same set that Jeremy posted...+1 from me. sca/ # "core" system sca/system/common sca/system/model sca/system/core # "baseline" services and extensions sca/baseline/service/monitor sca/baseline/service/security sca/baseline/service/transaction sca/baseline/service/work sca/baseline/container/java sca/baseline/transport/axis2 sca/baseline/data/sdo sca/baseline/policy/security On 3/21/06, Jim Marino <[EMAIL PROTECTED]> wrote: > kitchen sink ~ contrib; refrigerator ~ core + baseline (maybe, > although the baseline may not be necessary) > > On Mar 20, 2006, at 8:48 PM, Davanum Srinivas wrote: > > > "kitchen sink to build and run the refrigerator" > > > > So, in your opinion, what's the kitchen sink? Please be extermely > > specific. Please do keep in mind that there needs to be a downloadable > > version on the apache web site / mirrors which people can download and > > run out-of-the-box. > > > > thanks, > > dims > > > > On 3/20/06, James F Marino <[EMAIL PROTECTED]> wrote: > > > >> I like the general proposal Jeremy made. I believe we need to make a > >> distinction between things included in the core and baseline vs. > >> contributions. Things in the distribution may go beyond the spec such > >> as monitoring or some thing the community deems to have "wide" > >> applicability to Tuscany users. I would add one extra package in core > >> which is to separate out all of the public APIs related to extension > >> into a separate project. Celtix has done this and this relates to a > >> point below. > >> > >> In terms of build and process, my preference is to decide on an > >> approach upfront that may be modified based on experience. Here's > >> what I propose: > >> > >> 1. We focus on "clarifying" a public extension API. I don't > >> believe we > >> are going to be in a position to solidify this for some time, but we > >> need to get to a more stable state than we are now since having an > >> extension API is critical to growing the community. People writing > >> contributions should use this API but expect change and the > >> possibility of having to re-work their code. People working on core > >> that introduce breaking changes will help contributors of these > >> extensions make it "functionally whole". So, once we have the API > >> in a > >> "clarified" state, the build should work for extensions but people > >> should not be upset if the API changes and while their extension may > >> build, it may not function properly. In this case, the person > >> responsible for introducing the change as the obligation to help get > >> the extension working with others who are maintaining it. > >> > >> 2. Contributors of these new projects should be prepared to maintain > >> them given changes in the core that are likely to arise. Hopefully > >> this is a community process but people submitting new extension types > >> should be prepared to maintain them. I believe this is part of the > >> responsibility of being a committer but wanted to state it > >> explicitly. > >> > >> 3. I would like to see a process where contributions first go into a > >> sandbox and are worked on for some time prior to being put in > >> extensions. It would be good to have a discussion (not a vote) before > >> that move is made (i.e. to extensions). I think this is reasonably > >> "lightweight" and offers a way to get people to contribute with no > >> bar > >> (the sandbox). > >> > >> 4. I think the project structure should reflect this. For example, I > >> shouldn't need to download the kitchen sink to build and run the > >> refrigerator ;-) More practically, having a project structure that > >> represents distribution structures helps promote proper project > >> hygiene and avoid nasty dependency issues. > >> > >> Thoughts? > >> > >> - > >> Whats not completely clear from this is the 'rules', specifically > >> when must > >> the 'optional' stuff be built? If code isn't being built in the > >> regular > >> build that everyone runs it quickly goes stale. Look at our old Axis1 > >> binding, been out of the regular build a couple of weeks and > >> already it > >> fails to build. > >> > &g
Re: A release for JavaOne?
Jim, Axis2+Sandesha has already been thru WS-Addressing Interop and WS-RM Interop using both SOAP 1.1 and SOAP 1.2 (specifically with Indigo/WCF). thanks, dims On 3/22/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Jim, > > > 4. Additional bindings to Axis through integration with Celtix, > > particularly ws and JMS > > - Basic integration (p1) > > - Ability to retarget (p2) > > - Dan, would Celtix get us Indigo interop? > > Good question regarding the Indigo stuff. We do have Indigo interop on > the roadmap, but I don't know the complete timetable or what that really > means (since I know nothing about Indigo). > > That said, post milestone 5 of Celtix (next week), we have someone that > will be doing some interop testing using Celtix with Indigo to test the > WS-RM, WS-A and SOAP (1.1 only for now) interoperability. Obviously, > until the results of those tests come in, I don't know how far away we > are. > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > -- Davanum Srinivas : http://wso2.com/blogs/
Re: A release for JavaOne?
Raymond, others, Please feel free to poke around Axis2's JMS stuff [1] (experimental) that was tested using ActiveMQ thanks, dims [1] http://marc.theaimsgroup.com/?l=axis-dev&m=113392334526832&w=2 On 3/23/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > I meant JMS transport backed by ActiveMQ at the beginning. > > I also realized that it makes sense to have an async binding framework which > supports pluggable implementation backed by different async providers. The > framework should capture the common things and leave the protocol-specific > work (for example, how to schedule a task) to the concrete providers (if > it's JMS, using the JMS API to send the invocation message to request > queue). > > Another question would be: > > Do we want to differentitate the Threading-based async and Messaging-based > async? > > Thanks, > Raymond > > - Original Message - > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: > Sent: Thursday, March 23, 2006 12:49 PM > Subject: Re: A release for JavaOne? > > > > Do you mean an ActiveMQ transport or a JMS transport backed by ActiveMQ > > (realizing that there is more to ActiveMQ than just JMS)? > > > > Some async stuff I think can be handled by a simple work manager (in the > > general sense, not the JSR-237 sense although that could be an > > implementation) - does that fit? > > > > -- > > Jeremy > > > > Jim Marino wrote: > >> I was thinking ActiveMQ may be the transport mechanism. There's a lot > >> more to the programming model that would be part of Tuscany. > >> > >> Jim > >> > >> > >> On Mar 23, 2006, at 12:38 PM, Raymond Feng wrote: > >> > >>> Is ActiveMQ binding also candidate to support async PM? It seems that > >>> Celtix's JMS transport is based on Active MQ. > >>> > >>> Thanks, > >>> Raymond > >>> > >>> - Original Message - From: "Jean-Sebastien Delfino" > >>> <[EMAIL PROTECTED]> > >>> To: > >>> Sent: Thursday, March 23, 2006 12:22 PM > >>> Subject: Re: A release for JavaOne? > >>> > >>> > >>> > >>>> [snip] > >>>> > >>>>> > >>>>> > >>>>>> Other than that I think it would be good to find ways to > >>>>>> show how Tuscany plans to be more than just another platform for Java > >>>>>> web > >>>>>> services. > >>>>>> > >>>>>> > >>>>> Yes, I agree with that. We may have different reasons why we agree. My > >>>>> reasoning is based on SCA, which is intended to be more than "another > >>>>> platform for Java web services". Tuscany should be this primarily > >>>>> because of SCA. > >>>>> > >>>>> I think the best way to demonstrate this is through extensibility > >>>>> inline with SCA around impl types and bindings. Practically, I would > >>>>> suggest this be a JMS binding since JMS is something a lot of Java > >>>>> people use, particularly in comparison with others, and is the next > >>>>> binding type targeted by the spec. This shows SOA != web services. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>> Jim, I agree. It would be very good to demonstrate a subset of the SCA > >>>> async programming model running on top of a JMS binding. I think it > >>>> would make a lot sense to do this with the Celtix binding that Dan is > >>>> starting to work on. Again there's not a lot of time before May and as > >>>> I think you already said on this thread we'll probably be able to only > >>>> implement a subset of the async PM (maybe just one one-way invocations > >>>> without callbacks for example), but running the async PM on top of the > >>>> Celtix binding would help show the power of SCA, and would be a good > >>>> way to flesh out any issues and get concrete input into the spec as we > >>>> start implementing this. > >>>> --Jean-Sebastien > >>>> > >>> > >>> > >> > > > > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: A release for JavaOne? - mention on website?
If possible (IMHO) Please use the wiki for such temporary things, If you want to add pointers to articles and ppt's (static things) that is ok from the web site. That's my personal view and you are welcome to ignore it :) thanks, dims On 3/28/06, rick rineholt <[EMAIL PROTECTED]> wrote: > > I know some of you are planning to present at this and > possibly some other > important conferences would putting some details (i.e. > where, who, date, > synopsis ) on our Tuscany apache web site maybe under > news be 1) inappropriate > 2) worthy of mentioning ? > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Java2WSDL Tool Development
more than I wanted :) > > - All XSD types are generated in a single namespace, even if you start > > with Java classes from different packages. > > - Java2WSDL + WSDL2Java do not round-trip at all. If you start from > > Java, generate WSDL, then generate Java again, you get very different > > results. Going from WSDL to Java and back to WSDL produces invalid XSD > > complex types with names containing $ signs. > > - I also ran into a confusing situation with method signatures. For > > example from a getQuote(String symbol, String currency) method, > > Java2WSDL generates a getQuote WSDL operation taking a single > > getQuoteRequest element, containing child elements for symbol and > > currency. Now if you give that WSDL operation to WSDL2Java again, you'll > > end up with a new getQuote(GetQuoteRequest getQuote) method, very > > different from the original getQuote method. I'll let you guess what you > > get if you then give the generated Java interface to Java2WSDL again :) > > > > I suggest we work with the Axis2 team and open JIRAs for everything we > > find rather than trying to work around these issues by tweaking the > > generated WSDL object model. I'll create JIRAs for the problems I found > > today. > > > > > Ofcourse, I am also aware of and will work on the fact that the java > > > annotations in the component implementation should also be leveraged > > > from, when generating the WSDL. > > > > > Yes, we'll need to support Java 5 annotations at some point. I am not > > sure we need that right away, we can probably default the namespaces, > > WSDL and XSD names from the Java names for now and add annotations > > later. What do people in the group think? > > > > > Thanks > > > - Krish > > -- > > Jean-Sebastien > > > > > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Java2WSDL Tool Development
Please upload a "svn diff" against Axis2 SVN after u open the JIRA bug. thanks, dims On 4/6/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > +1 to "I guess the best would be to refactor the Axis2 implementation > and contribute it back to Axis2" > > Jira is the best way to get eyeballs on your problem :) > > -- dims > > On 4/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi Everybody, > >Here is an attempt on the wrapper. I have created Java2WSDLGenerator > > interface and impl that wraps up the Axis2 implementation. This basically > > crunches the functionality of the Java2WSDLCodeGen, Java2WSDLBuilder and the > > Java2WSDL implementations of Axis under it. I have copied / refactored the > > Axis2 code into this single class that will act as a facade. From this > > point onwards, lower down the call trace stack, I have constrained myself > > to using Axis2 implementation as is. From here on I feel that any fix > > should go into Axis2 codebase itself. > > > > As far as this wrapper implementation is concerned I have put in another > > class called TuscanyJava2WSDL. This class will work with this > > Java2WSDLGenerator of ours, access the WSDL model and fix the model wherever > > required. As a started I have removed the redundant namespaces that used to > > get generated with the ns0, ns1 and ns2 prefixes. My find is, that these > > get generated only during the serialization of the Schema and is not > > originally a part of the Schema that is generated by the SchemaGenerator > > class... it seems to be the doing of SchemaSerializer in the ws.commons > > package. I have also fixed the "elementFormDefault" attributes. We could > > use this class a 'model fixer' at the present moment to go forward with > > Tuscany. In due course, as the Axis2 code is fixed we could cut out the > > fixes implemented in this class. > > > > Coming to the design of this wrapper I am not too comfortable with the > > design. For example I would prefer that the Java2WOMBuilder is the class > > called to generate the WSDL model after the validation of input arguments. > > I would prefer that Java2WOMBuilder uses the SchemaGenerator internally. I > > could not inherit the Java2WOMBuilder to do this myself because of the way > > its constructor and instance variables have been implemented. > > > > I guess the best would be to refactor the Axis2 implementation and > > contribute it back to Axis2. But then I am clueless about getting a break > > to do this... an earlier mail that I sent to the dev-team there regard the > > generation of the namespace has not evoked any reponse. > > > > So what is the community's take on this... should we go ahead and populate > > this wrapper with the fixes that we would need to go ahead with our release > > plans or should we wait to fix up Axis2 implementation and then use it. > > > > Here is the jar of classes that make up the wrapper... I have downloaded > > the Axis2 Source release as the binary release does not contain Java2WSDL. > > Please let me know your opinions on this... thanks. > > > > - Krish > > > > On 4/5/06, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > > > Venkata Krishnan wrote: > > > > Hi > > > > > > > > I have been looking into the Java2WSDL tool implementation in Axis. > > > > The generated WSDL for the Helloworld service seems to be comparable > > > > with what is there in the samples. There are some differences > > > > between the two though. Also when the targetnamespace is not input > > > > (i.e. user specified) the resultant wsdl is erroneous. This is also > > > > reported by others on the Axis2 Dev. Mailing Lists. I have attached > > > > the two wsdls just in case any of you want to take a look. > > > > (helloworld.wsdl is the one in the Tuscany Samples and > > > > HelloWorldServiceComponentImpl.wsdl is the AXIS2 > > generated WSDL). > > > There are some bugs in the WSDL generated by Axis2: > > > - Duplicate namespace prefix declarations for > > > http://www.w3.org/2001/XMLSchema in the generated XSD > > > - Incorrect elementFormDefault, attributeFormDefault and targetNamespace > > > attributes on the schema element. IMO they shouldn't have any namespace > > > prefix, my XSD validator flags them as errors, and I spent half an hour > > > in the XSD spec and couldn't find evidence that these attributes can > > > have a prefix... If any XSD expert i
Re: Java2WSDL Tool Development - AXIOM jars
Please run "maven create-lib" from the root directory it will download the latest dependency jars to target/lib thanks, dims On 4/15/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi... > I downloaded Axis2 source from SVN and looked up the Java2WSDL > implementation. Looks like some issues are being addressed as it appears > from the code. I am yet to resolve a dependcy related to the package " > org.apache.axiom.om" to be able to run and see the outputs. Can somebody > help me on how I can get the jar for this... from where? Thanks. > > - Krish > > > On 4/13/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > HI... > > I am going to post a patch up the JIRA for Tuscany Java2WSDL. While I > > was doing some variations of testing I figured out the following: - > > - I moved over the code to try running the class from command prompt. I > > unpacked the Axis2 binary release 0.95 and extracted the jar files and set > > them up to the class path. Now when I run the Java2WSDL tool... some of the > > stuff that were not ok previously were now gone... for example the > > duplication of namespaces in the Schema element and prefixes for > > elementFormDefault and attributFormDefault were all gone. The other > > inconsistencies remained though. > > - In eclipse I was trying out everything from within the sca-tools module > > that I had downloaded form the Tuscany SVN. I had linked the Axis2 > > 0.95source code to this module. Could it be that there has been a mix up of > > Axis 0.94 in this module? Could it be the result of different rt.jarfiles > > being used - remember I earlier posted that all this mess up with the > > namespaces was the doing of a transformer in rt.jar. > > > > Anyways... to be on the safer side I have tested this patch under > > sca-tools as well as outside it and it works for both. > > > > > > > > > > > > On 4/10/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > > > Hi > > > I looked up further into the code to find the reason for the namespaces > > > generated in the schema element. Looks like it is the work of a > > > Transformer > > > that is used by the XMLSchemaSerializer. The XMLSchemaSerialzer is a part > > > of the apache.ws.commons.XMLSchema project. However the tranformer > > > seems to be in rt.jar. I suppose we could instantiate another > > > tranformer in the XMLSchemaSerializer assuming that we will be allowed to > > > fix the code there. But then if we want to fix the transformer how do we > > > get access to the source of > > > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl which is > > > the tranformer used? > > > > > > - Krish > > > > > > > > > > > > On 4/6/06, Davanum Srinivas <[EMAIL PROTECTED] > wrote: > > > > > > > > Please upload a "svn diff" against Axis2 SVN after u open the JIRA > > > > bug. > > > > > > > > thanks, > > > > dims > > > > > > > > On 4/6/06, Davanum Srinivas < [EMAIL PROTECTED]> wrote: > > > > > +1 to "I guess the best would be to refactor the Axis2 > > > > implementation > > > > > and contribute it back to Axis2" > > > > > > > > > > Jira is the best way to get eyeballs on your problem :) > > > > > > > > > > -- dims > > > > > > > > > > On 4/6/06, Venkata Krishnan < [EMAIL PROTECTED]> wrote: > > > > > > Hi Everybody, > > > > > >Here is an attempt on the wrapper. I have created > > > > Java2WSDLGenerator > > > > > > interface and impl that wraps up the Axis2 implementation. This > > > > basically > > > > > > crunches the functionality of the Java2WSDLCodeGen, > > > > Java2WSDLBuilder and the > > > > > > Java2WSDL implementations of Axis under it. I have copied / > > > > refactored the > > > > > > Axis2 code into this single class that will act as a facade. From > > > > this > > > > > > point onwards, lower down the call trace stack, I have constrained > > > > myself > > > > > > to using Axis2 implementation as is. From here on I feel that any > > > > fix > > > > > > should go into Axis2 codebase itself. > > > > > > > > > > > > As far as this wrapper implementati
Re: Moving the Celtix binding to the bindings/ directory, was: including celtix in refactor work and checkstyle
Jean-Sebastien, Just checked with Cliff. CDDL jars are ok both for inclusion in our SVN and as part of a distribution. So +1 from me. -- dims On 4/26/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Jim Marino wrote: > > Just a friendly reminder to those working on the core or model to > > please include celtix in their refactorings. I accidentally forgot to > > check in my refactors (sandbox is separate) and run the checkstyle > > tests from celtix/binding.celtix resulting in Dan having a broken demo > > :-( Also, someone else modifying the loader forgot to include the > > project in their refactors (I fixed it)... > > > > Dan also proposed we adopt checkstyle as part of the build process. I > > would like to due this using lazy consensus with the caveat that the > > cut-over be done after the Java One release to avoid disruption and > > give people a chance to adjust code gradually. The checkstyle > > configuration is fairly rigorous and we will need to divide up the > > work to do so by project. > > > > Jim > > > > Sorry for contributing to the break as well... when I did my latest > refactoring I didn't have the Celtix binding included in my workspace > either. What do people think about moving the Celtix binding to the > main code stream under bindings/? It's getting in a good shape now, and > this way we'll all include it in our refactoring, testing, it'll be > loaded in our IDEs etc. > > Any thoughts? > > -- > Jean-Sebastien > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Moving the Celtix binding to the bindings/ directory, was: including celtix in refactor work and checkstyle
oops! i meant EPL On 4/26/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Jean-Sebastien, > > Just checked with Cliff. CDDL jars are ok both for inclusion in our > SVN and as part of a distribution. So +1 from me. > > -- dims > > On 4/26/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Jim Marino wrote: > > > Just a friendly reminder to those working on the core or model to > > > please include celtix in their refactorings. I accidentally forgot to > > > check in my refactors (sandbox is separate) and run the checkstyle > > > tests from celtix/binding.celtix resulting in Dan having a broken demo > > > :-( Also, someone else modifying the loader forgot to include the > > > project in their refactors (I fixed it)... > > > > > > Dan also proposed we adopt checkstyle as part of the build process. I > > > would like to due this using lazy consensus with the caveat that the > > > cut-over be done after the Java One release to avoid disruption and > > > give people a chance to adjust code gradually. The checkstyle > > > configuration is fairly rigorous and we will need to divide up the > > > work to do so by project. > > > > > > Jim > > > > > > > Sorry for contributing to the break as well... when I did my latest > > refactoring I didn't have the Celtix binding included in my workspace > > either. What do people think about moving the Celtix binding to the > > main code stream under bindings/? It's getting in a good shape now, and > > this way we'll all include it in our refactoring, testing, it'll be > > loaded in our IDEs etc. > > > > Any thoughts? > > > > -- > > Jean-Sebastien > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > -- Davanum Srinivas : http://wso2.com/blogs/
Re: wsdl4j....
switched Axis2 to latest wsdl4j. will let u all know if something breaks and we've to switch back :) thanks, dims On 4/29/06, ant elder <[EMAIL PROTECTED]> wrote: It makes me a bit nervous that as Axis2 is not using the latest version doing this may break something in our Axis2 binding. Maybe Dims can tell us or we could ask about it over on axis-dev. Do you need to do this now to fix something or could it wait a bit? ...ant On 4/29/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > Would anyone object if I submitted a patch to change all usage of > axis-wsdl4j to use the actual wsdl4j. Basically, change: > > > axis > axis-wsdl4j > 1.2 > > > to > > wsdl4j > wsdl4j > 1.5.2 > > > 1.5.2 is MUCH newer and contains a bunch of bug fixes we would like to > have. > > Obviously, I would test as much as I can before submitting such a patch. > > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Karma for Dan
+1 from me. On 4/30/06, ant elder <[EMAIL PROTECTED]> wrote: +1, welcome aboard Dan ...ant On 4/29/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > I think that Dan has done a lot of good work with the Celtix > integration and has shown a good understanding of the project. > > A very definite +1 from me. > -- > Jeremy > > On 4/29/06, Jim Marino <[EMAIL PROTECTED]> wrote: > > I'd like to propose was make Dan a commiter since he's done a lot > > including: > > > > - Creating a binding that supports web services and will support JMS > > over the next couple of days > > - Fixed a host of compiler warnings in a number of projects > > - Has served as an excellent "bridge" to the Celtix community > > - Has demonstrated that he shares a philosophy towards design and > > coding that is consistent with the Tuscany group > > > > Also, more practically, there is outstanding work to move the Celtix > > binding to main and he has a fairly large commit coming. I for one > > would like to have Dan do it directly :-) > > > > So, could we vote on this proposal? > > > > +1 (obviously) from me. > > > > Jim > > > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [RESULT]Re: Karma for Dan
Dan, What would you like your Apache id to be. Please send me some alternate choices (in order or priority). thanks, dims On 5/2/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: I just want to say a quick thanks to everyone for the vote of confidence. Thanks! Dan On Tuesday 02 May 2006 19:12, Jim Marino wrote: > Result of the vote for Dan Kulp as committer on Apache Tuscany: > > +1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt > > No -1s > > Dan welcome to the Apache Tuscany community! We'll start the process > of getting you karma. > > Jim > > On Apr 29, 2006, at 10:28 AM, Jim Marino wrote: > > I'd like to propose was make Dan a commiter since he's done a lot > > including: > > > > - Creating a binding that supports web services and will support > > JMS over the next couple of days > > - Fixed a host of compiler warnings in a number of projects > > - Has served as an excellent "bridge" to the Celtix community > > - Has demonstrated that he shares a philosophy towards design and > > coding that is consistent with the Tuscany group > > > > Also, more practically, there is outstanding work to move the > > Celtix binding to main and he has a fairly large commit coming. I > > for one would like to have Dan do it directly :-) > > > > So, could we vote on this proposal? > > > > +1 (obviously) from me. > > > > Jim -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] Publish Tuscany M1 release
+1 from me. On 5/19/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: +1 from me. Paul Fremantle wrote: > +1 from me. > > Paul > > On 5/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> +1 >> -- >> Jeremy >> >> On 5/18/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> > Hi! >> > >> > I created source and binary distributions of the latest Tuscany >> > Milestone 1 release candidate level (SVN revision r407596) and placed >> > them in my home directory: >> > >> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.tar.gz >> >> > >> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.zip >> >> > >> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.tar.gz >> >> > >> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.zip >> >> > >> > I also tagged this level of code as >> > >> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060518. >> > >> > Solid progress has been made to produce this Milestone release, and I >> > think it is in a good shape. The list of JIRA issues resolved and >> closed >> > in this Milestone 1 release is here: >> > >> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12311030&fixfor=12311061&version=12311030&version=12311061&status=5&status=6&sorter/field=priority&sorter/order=DESC >> >> > >> > Instructions on setting up your environment to use Tuscany and getting >> > started with the Tuscany samples are in the README.txt and >> > GettingStarted.htm files contained in the distributions. These >> files can >> > also be downloaded from here: >> > >> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060518/java/README.txt >> >> > >> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060518/java/GettingStarted.htm >> >> > >> > I tested the binary and source distributions in the following >> environments: >> > Redhat Enterprise Linux 4 - Java JDK 5.0 update 06 - Maven 2.0.4 - >> > Apache Ant 1.6.5 >> > Windows XP SP2 - Java JDK 5.0 update 06 - Maven 2.0.4 - Apache Ant >> 1.6.5 >> > >> > Please vote to publish the Milestone 1 release distributions. Please >> > take some time to download the distributions, review them and test >> them >> > in your environment before voting. >> > >> > The vote is open for the next 72 hours, please vote by Sunday May 21, >> > 4pm PDT. At least three +1 votes are required, and only the votes from >> > Tuscany committers are binding. If the majority of all votes is >> > positive, I will send a summary of that vote to the Incubator's >> general >> > list to formally request the Incubator PMC to approve the Tuscany >> > Milestone 1 release. For your reference the Incubator release policy >> > guidelines are available at >> > >> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases. >> > >> > -- >> > Jean-Sebastien >> > >> > >> > - >> > 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] >> >> > > -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ATTN: Release Managers] 3 binding +1's for a Release from PMC folks
Dear Release Managers, [Sorry for the cross post!] Please don't make a release unless there are 3 binding votes from pmc members. We need it for legal purposes. There is one more quirk about what we actually vote on. HTTPD pmc votes on a svn tag and then the release managers cut binaries corresponding to that tag. We tend to vote on a feature list and then release managers make it happen.Again this is also for legal purposes to make sure that there is proper oversight on what gets into a release. I am still finding out how other projects do it. Your suggestions are welcome! Please post only to [EMAIL PROTECTED] for discussion to ensure maximum participation. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report for June 2006
Dear WS Folks, It's time for our quarterly report to the board. It's our duty as committers and pmc members to provide an accurate and detailed description of our activities to the board. So please take a few minutes and add information on projects that you are involved in. http://wiki.apache.org/ws/ReportForJune2006 Thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany blog
Whatever you guys do. make sure to add your blog to the ws planet aggregator so that it shows up here: http://ws.apache.org/blog/ All you need to do is add an entry in the config.ini: https://svn.apache.org/repos/asf/webservices/admin/planet/ thanks, dims On 6/8/06, ant elder <[EMAIL PROTECTED]> wrote: How about setting up a blog for the Tuscany project? We could use it to publicize interesting events for all the different Tuscany sub projects - new releases, use of Tuscany by another another project/company, upcoming conference talks or slides from presentations, new spec release etc. Other projects do this, for example the Dojo project has one at: http://blog.dojotoolkit.org/ I think I could sometimes find interesting things to comment on from the Java SCA perspective, but to be successful there would need to be more frequent posts, so buy in from others involved in Tuscany to make sure there are regular topical posts - would others be willing to participate? If so, the next question is how to do this. There's various free blog sites, http://www.jroller.com/, although thats specifically Java so may not fit our multi-language nature so http://www.bloglines.com/ maybe better, I know some other Apache WS people use that. Any other suggestions or which blog host to use? Then there's how to administer the blog userid and password, i guess the obvious thing is to share that with every Tuscany committer so all the committers can post when ever they want, although there are other Tuscany users and contributors who may want to post so should we consider distributing the uid/pswd more widely? ...ant -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany blog
Hmm... how about "apache-tuscany" (or variant) since that is the formal name of the project? -- dims On 6/12/06, kelvin goodson <[EMAIL PROTECTED]> wrote: Good point, I'll +1 that too ;-) On 6/12/06, ant elder <[EMAIL PROTECTED]> wrote: > > +1 from me for tuscanysoa. > >...ant > > On 6/12/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > Are you sure about "tuscanysca"? Wouldn't "tuscanysoa" be more > inclusive? > > > > Geoff. > > > > On 12/06/06, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > OK, so after a minor off-line chat with ant I think the nice URL from > > > blogger makes me think +1 for blogger over airset. If everyone else > is > > > happy the last thing we need to do is express preferences over the URL > > for > > > the blog. As ant mentioned, its in the form of > > > > > > http://.blogspot.com/ > > > > > > so long as whatever-you-choose is not already in use of course. BTW > > > "tuscany" is not available. We have a placeholder on "tuscanysca", > but > > > can > > > change this. Any comments? In the absence of any strong feelings > being > > > expressed in the near term we'll go with "tuscanysca". Once this is > > > decided > > > we can send out invitations to join blogger so that you can post. > > > > > > Kelvin. > > > > > > > > > > > > -- Best Regards Kelvin Goodson -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany blog
should be ok. -- dims On 6/12/06, ant elder <[EMAIL PROTECTED]> wrote: Would we be allowed that while we're incubating? If so I'd be +1 for that above all others. But incubating-apache-tuscany seemed like a bit of a mouthful. ...ant On 6/12/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > Hmm... how about "apache-tuscany" (or variant) since that is the > formal name of the project? > > -- dims > > On 6/12/06, kelvin goodson <[EMAIL PROTECTED]> wrote: > > Good point, I'll +1 that too ;-) > > > > On 6/12/06, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > +1 from me for tuscanysoa. > > > > > >...ant > > > > > > On 6/12/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > > > > > Are you sure about "tuscanysca"? Wouldn't "tuscanysoa" be more > > > inclusive? > > > > > > > > Geoff. > > > > > > > > On 12/06/06, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > > > > > OK, so after a minor off-line chat with ant I think the nice URL > from > > > > > blogger makes me think +1 for blogger over airset. If everyone > else > > > is > > > > > happy the last thing we need to do is express preferences over the > URL > > > > for > > > > > the blog. As ant mentioned, its in the form of > > > > > > > > > > http://.blogspot.com/ > > > > > > > > > > so long as whatever-you-choose is not already in use of > course. BTW > > > > > "tuscany" is not available. We have a placeholder on > "tuscanysca", > > > but > > > > > can > > > > > change this. Any comments? In the absence of any strong feelings > > > being > > > > > expressed in the near term we'll go with "tuscanysca". Once this > is > > > > > decided > > > > > we can send out invitations to join blogger so that you can post. > > > > > > > > > > Kelvin. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best Regards > > Kelvin Goodson > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private/PPMC list
Not yet folks! -- dims On 6/20/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Jeremy Boynes wrote: > Any progress on this? > > Jeremy Boynes wrote: > >> I have seen in a couple of offlist email discussions about prospective >> committers but I am concerned that not all committers may be on them. >> IIRC Ant had suggested we create a private or PPMC list for all >> committers and I think that would be a good idea. >> >> Dims, Sam, Geir, could someone with apmail access set this up for us >> please, or point me to where I should make such a request. >> >> Thanks >> -- >> 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] > > > Has the list been created? -- Jean-Sebastien --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany blog
Hmm...let me check my scripts. thanks, dims On 7/4/06, ant elder <[EMAIL PROTECTED]> wrote: Hi Dims, I updated the planet aggregator config.ini for this quite a while ago now but its still not showing on http://ws.apache.org/blog/. Is there something else i need to do or bounce? ...ant On 6/8/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > Whatever you guys do. make sure to add your blog to the ws planet > aggregator so that it shows up here:ng > > http://ws.apache.org/blog/ > > All you need to do is add an entry in the config.ini: > https://svn.apache.org/repos/asf/webservices/admin/planet/ > > thanks, > dims > > On 6/8/06, ant elder <[EMAIL PROTECTED]> wrote: > > How about setting up a blog for the Tuscany project? We could use it to > > publicize interesting events for all the different Tuscany sub projects > - > > new releases, use of Tuscany by another another project/company, > upcoming > > conference talks or slides from presentations, new spec release etc. > > > > Other projects do this, for example the Dojo project has one at: > > http://blog.dojotoolkit.org/ > > > > I think I could sometimes find interesting things to comment on from the > > Java SCA perspective, but to be successful there would need to be more > > frequent posts, so buy in from others involved in Tuscany to make sure > there > > are regular topical posts - would others be willing to participate? > > > > If so, the next question is how to do this. There's various free blog > sites, > > http://www.jroller.com/, although thats specifically Java so may not fit > our > > multi-language nature so http://www.bloglines.com/ maybe better, I know > some > > other Apache WS people use that. Any other suggestions or which blog > host to > > use? Then there's how to administer the blog userid and password, i > guess > > the obvious thing is to share that with every Tuscany committer so all > the > > committers can post when ever they want, although there are other > Tuscany > > users and contributors who may want to post so should we consider > > distributing the uid/pswd more widely? > > > >...ant > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://people.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Icon
missing a bottle of wine? :) On 7/6/06, kelvin goodson <[EMAIL PROTECTED]> wrote: I'm like this, http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate1.jpg but I think it might be too colourful and I like the idea of bringing out the "sca" in Tuscany as shown in http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_h.jpg I also like http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tuscanylogo_candidate2.jpgbut I think that may be because I'd like to buy a lawnmower from them :-) On 7/6/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > My favourite so far is one of Ed's: > > http://wiki.apache.org/ws-data/attachments/Tuscany(2f)LogoCandidates/attachments/tusc_mod9.jpg > > > > On 7/6/06, haleh mahbod <[EMAIL PROTECTED]> wrote: > > > > What Ed posted in black and brown looks good. Maybe we can get rid of > some > > of the trees and make it simpler. I'll take a stab at it. > > > > > > On 7/5/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote: > > > > > > Cheers! > > > > > > -Original Message- > > > From: Pete Robbins [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, July 05, 2006 5:45 PM > > > To: tuscany-dev@ws.apache.org > > > Subject: Re: Tuscany Icon > > > > > > On 05/07/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote: > > > > > > > > I really liked the wine stain on the white background. That was > pretty > > > > clever, simple, evocative, etc. > > > > > > > > Plus it'd look really cool on a white tee shirt, and it makes > branding > > > > of cocktail napkin-based design documents really easy. > > > > > > > > :-) > > > > > > > > > I always thought that a single cypress tree with no writing was the > > > best... > > > but now I really like the wine stain. I can supply custom stained > shirts > > > ;-) > > > > > > -- > > > Pete > > > The contents of this e-mail are intended for the named addressee only. > > It > > > contains information that may be confidential. Unless you are the > named > > > addressee or an authorized designee, you may not copy or use it, or > > disclose > > > it to anyone else. If you received it in error please notify us > > immediately > > > and then destroy it. > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > Cheers, > > Andrew Borley > > -- Best Regards Kelvin Goodson -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Test generator
David, Axis2's WSDL2Java has an option to generate a junit test case. We could make sure that it works now and enhance that as appropriate. -- dims On 8/1/06, David Wheeler <[EMAIL PROTECTED]> wrote: Venkata: I was planning on at least using the WSDL2Java M1 tool to generate the java interface, but I'm not sure of the value beyond that. Ant: To generate the dummy data, The code in 419 definitly looks like it can be of alot of use. Thanks. -David On 8/1/06, ant elder < [EMAIL PROTECTED]> wrote: > > Hi David, yes this sounds like something that could be useful. How do you > plan on generating the dummy data? There's already some code for this that > Venkat has done for creating empty XML instances from a WSDL, see > TUSCANY-419, hopefully you'll be able to reuse and enhance that code. > >...ant > > On 7/31/06, David Wheeler <[EMAIL PROTECTED]> wrote: > > > > Hi, I've been working, with Raymond's help, on a system to generate a > test > > based around a given wsdl. The system would generate not just classes, > but > > dummy data to be sent using SCA axis bindings. Checking that the data > was > > successfully bounced from client to server and back. > > > > Does this sound like a good idea? > > Thoughts? > > > > -David Wheeler. > > > > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axiom and classloaders, was: svn commit: r429905
Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: > If we can find another way without applying our private changes to > Axis I'm perfectly fine by that. Have any detailed suggestion off > hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axiom and classloaders, was: svn commit: r429905
Checked in the fix from Jeremy. Please pick up the nighty later today. thanks, dims On 8/9/06, Rick <[EMAIL PROTECTED]> wrote: We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: > Are u folks using latest Axis2 SVN? > > -- dims > > On 8/9/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> On Aug 8, 2006, at 8:38 PM, cr22rc wrote: >> >> > If we can find another way without applying our private changes to >> > Axis I'm perfectly fine by that. Have any detailed suggestion off >> > hand? >> >> Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can >> you confirm that where you were getting the problem? If so, I would >> suggest we take this to the Axiom list. >> >> -- >> 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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account request for new Tuscany committer: Kelvin Goodson
Nope. does not slow anything down :) On 8/9/06, kelvin goodson <[EMAIL PROTECTED]> wrote: Hi, just to check in case this is slowing the process up, it appears that ant had adhered to the prescribed format in his note; did the fact that you posted a link to the format suggest that there was something he hadn't done right? Regards, Kelvin. On 07/08/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > Hi Ant, > > Its better to cc this email to the new committer as well. The format for > this email can be found here > (http://www.apache.org/dev/pmc.html#newcommitter) > > -- Chinthaka > > ant elder wrote: > > Tuscany has voted in Kelvin as a committer, could an account be created > > for him please. > > > > Preferred userid: kelvin > > Full name: Kelvin James Goodson > > Forwarding email: [EMAIL PROTECTED] [EMAIL PROTECTED]> > > > > Requested Karma for: ws ws-tuscany > > > > ICLA has been submitted and now appears on > > http://people.apache.org/~jim/committers.html > > <http://people.apache.org/%7Ejim/committers.html> > > > > Vote result 9 +1 votes and no -1s: > > > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] > > < > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] > > > > > > Thanks! > > > >...ant > > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axiom and classloaders, was: svn commit: r429905
My best guess is end of this month... -- dims On 8/9/06, Rick <[EMAIL PROTECTED]> wrote: Per jumping to SNAPSHOTS of Axis 2.0 builds: Dims, any thoughts where you think Axis 2.0 is in the life cycle of the next release? Are things fairly stable ? I seen some talk on the mailing list about release 1.1 but I didn't get a good feel for any specific target date. Jeremy Boynes wrote: > Thanks Dims. > > I saw the fixes (r427662) for classloader issues with Spring as well - > Rick, I think perhaps we should be using a SNAPSHOT of axis for this > as well. > > -- > Jeremy > > On Aug 9, 2006, at 7:07 AM, Davanum Srinivas wrote: > >> Checked in the fix from Jeremy. Please pick up the nighty later today. >> >> thanks, >> dims >> >> On 8/9/06, Rick <[EMAIL PROTECTED]> wrote: >>> We are building with Axis 2.0 version 1.0 release. >>> >>> Davanum Srinivas wrote: >>> > Are u folks using latest Axis2 SVN? >>> > >>> > -- dims >>> > >>> > On 8/9/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >>> >> On Aug 8, 2006, at 8:38 PM, cr22rc wrote: >>> >> >>> >> > If we can find another way without applying our private changes to >>> >> > Axis I'm perfectly fine by that. Have any detailed suggestion off >>> >> > hand? >>> >> >>> >> Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can >>> >> you confirm that where you were getting the problem? If so, I would >>> >> suggest we take this to the Axiom list. >>> >> > > ----- > 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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/[EMAIL PROTECTED] -- dims On 8/11/06, ant elder <[EMAIL PROTECTED]> wrote: While we talking about moving to more recent releases of things, there's a Woodstox 3.0 out now, should we look at upgrading to that as well? Probably not too hard a change if some budding contributor wants to check out if its an easy upgrade and submit a patch when Woodstox hits a maven repos. Or should we stick with 2.9.3 for now while we know it works fine? ..ant -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
You got me :) -- dims On 8/11/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: > 3.0.0 works only on 1.5 and above :( > > http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ > [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
