AW: Where dose JSP works in JSF request lifecycle?
So, how do you make sure that the right dynamic data gets loaded so that the page displays the right stuff? That's where Shale comes in handy. If your backing bean implements the ViewController interface, then prerender() will get called just before the JSP page is invoked. This is the perfect place to grab any data you need from your database to display the requested page. You can do this without Shale, but there's somewhat more pain involved. So how would you do it in plain JSF without the ViewController? In the contructor? Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Shale vs. Action framework Statistics
Ted, thanks for the answer, you gave me really some good sources to look at. Even though it's a bit unfortunate that the statistics are not split between Struts Action and Struts Shale. Especially for the downdload area it would be interesting to see the devleopment of the two. Is it possible to change that? Bernhard -Ursprüngliche Nachricht- Von: Ted Husted [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 4. März 2006 17:08 An: Struts Users Mailing List Betreff: Re: Shale vs. Action framework Statistics On 3/4/06, Bernhard Slominski [EMAIL PROTECTED] wrote: are there any download statistics availabe for Shale + the action framework? Could give a rough estimated about the popularity of both framworks. The download statistics for the Apache Struts website are here: * http://people.apache.org/~vgritsenko/stats/projects/struts But it doesn't distinguish between Struts Action and Struts Shale. Another good way to judge the popularity of a product is by the articles and extensions other people publish about it. For more on that score visit * Planet Struts - http://www.PlanetStruts.org/ * Struts Central - http://www.StrutsCentral.net/ According to the OnJava 2005 reader survey, the Struts Action framework was holding steady at a 60% share (among readers who responded). * http://www.planetstruts.org/roller/page/news?entry=struts_stil l_the_one_says Of course, the best reason to select a product is because it meets *your* needs. Every framework out there was created because someone felt their specific needs were not being addressed. The best advice is to try a portion of your application (a spike) in a couple of likely choices, and then decide for yourself. Besides Shale and Action, other likely candiates might be Tapestry, Spring MVC, and Wicket, along with WebWork (Action2). If the choice is between Action and Shale, then first decide if you want to use JSF. For more see, * http://struts.apache.org/kickstart.html#choice -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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]
Shale vs. Action framework Statistics
Hi, are there any download statistics availabe for Shale + the action framework? Could give a rough estimated about the popularity of both framworks. Thanks Bernhard Slominski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: Disabling Back Button in IE
This problem is as old as the web browsers are, at the beginning browsers and http were just there to display static pages, not for building applications with it, so the back button was not a problem. But you get serious problems with that when building applications. But as Frank and Josh pointed, now matter what you do there is always a posibility that you go back to the last page. So my recommendation is also that you do a check on the server side, so e.g. when you press the sumbmit order, delete the shopping cart in the session, when the back button is prssed you realize the session shoping cart is empty and issue a message Your shooping cart is gone. A pain, but no real way around it! Bernhard -Ursprüngliche Nachricht- Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 22. Februar 2006 17:43 An: Struts Users Mailing List Cc: user@struts.apache.org Betreff: Re: AW: Disabling Back Button in IE Doesn't stop me from clicking my mouse wheel, which is mapped to Back :) Betreff: Re: Disabling Back Button in IE Can't (and shouldn't) be done. The closest you're likely to get it open your app in a popup window with no menu, though the user can still hit backspace. A better idea is to fix the (assumed) re-post issues in your application. -Josh Hi Anyone can tell how to disable the Back button in IE through our Code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [Shale] API Stability vs. V1.0
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig Of course right now it's not possible to tell which release it is or when this is. Not really at this point ... but feedback on that topic, as well as general usage comments, is welcome. At what feature set would users consider it complete enough to use? Would you want to wait for one or more particular features to reach evolving stability rankings first? Craig Well in my opinion the features in the current alpha version are good enough to justify a first general availability release. The good thing about Shale is that many of the features can be used stand-alone, so I think many users may just use one or the other feature, which is missing in JSF 1.1/1.2 but which makes development much easier. So from this perspective it makes sense to make Shale - as it is from the features included - the first general availibility release. Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] API Stability vs. V1.0
Hi all, I am a bit confused about the versioning and the API stability. So the current Version of Shale is 1.0.1 (according to the API documentation), so a 1.0 version. However the API stability (http://struts.apache.org/struts-shale/api-stability.html) tell a different story, from the 32 packages only 7 packages are evolving that means backwards compatibility is maintained. So from the API stability it looks more like a 0.5 release status. So my question: In which version can the status evolving for all packages be expected? Or will there be always some packages in the developing status? I understand that according to the Struts FAQ there will be no release schedules (http://struts.apache.org/helping.html#release), I read it, understood it and accepted it, however if someone's got a rough estimate I'd be happy to hear about it. Thanks Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [Shale] API Stability vs. V1.0
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Shale follows the same version branding policy that the rest of Struts does (along with Tomcat and some other projects). An x.y.z release is first issued with no quality metric, and is then voted on as being of alpha, beta, or general availability quality. The 1.0.0 release was voted to be alpha quality (in spite of the fact that many portions are more stable than that would imply) as a whole. Ok, thanks! So are the following statements right then? There will be a 1.0.x version which is voted for general availability quality. But in this general availability quality 1.0.x release there might be a few developing APIs as well. Of course right now it's not possible to tell which release it is or when this is. Benrhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Forcing URL Rewriting over Cookies in an existing application .
-Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 18:10 What do you mean by do it the other way around ? Well I mean that you ONLY use cookies for the session management and not URL Rewriting, you might want to do that for security reason, because when using URL Rewriting the Session ID is in the address line and the cache, so a pssoble security risk. I think this should be contollable in a standard way and not container-specific. Bernhard -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 11:34 AM To: 'Struts Users Mailing List' Subject: AW: Forcing URL Rewriting over Cookies in an existing application. Thank you! But it's not possible to do it the other way round in Tomcat right ? Also I think this should belong in the web.xml and shouldn't be container-specific, what do you think? Bernhard -Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 17:28 An: Struts Users Mailing List Betreff: RE: Forcing URL Rewriting over Cookies in an existing application. The same thing (disable cookies but enable url rewriting) should work on Tomcat 4.X and 5.X. See the cookies attribute in the below url(s): http://tomcat.apache.org/tomcat-4.0-doc/config/context.html http://tomcat.apache.org/tomcat-5.0-doc/config/context.html http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Regards, David -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 11:20 AM To: 'Struts Users Mailing List' Subject: AW: Forcing URL Rewriting over Cookies in an existing application. OT, but I'm interested, is this available im Tomcat too? Thanks Bernhard -Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 17:08 An: Struts Users Mailing List Betreff: RE: Forcing URL Rewriting over Cookies in an existing application. http://access1.sun.com/techarticles/sessions.iws.html Regards, David -Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 10:53 AM To: user@struts.apache.org Subject: Forcing URL Rewriting over Cookies in an existing application. Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that uses Cookies for session handling and has been so for around 3/4 years. I have a requirement where I want to force URL Rewriting even if the browser supports cookies. Please help! Jay Broadband interface (RIA) + mail box saftey = http://Struts_User_List.roomity.com *Your* clubs, no sign up to read, ad supported; try broadband internet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Forcing URL Rewriting over Cookies in an existing application .
OT, but I'm interested, is this available im Tomcat too? Thanks Bernhard -Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 17:08 An: Struts Users Mailing List Betreff: RE: Forcing URL Rewriting over Cookies in an existing application. http://access1.sun.com/techarticles/sessions.iws.html Regards, David -Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 10:53 AM To: user@struts.apache.org Subject: Forcing URL Rewriting over Cookies in an existing application. Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that uses Cookies for session handling and has been so for around 3/4 years. I have a requirement where I want to force URL Rewriting even if the browser supports cookies. Please help! Jay Broadband interface (RIA) + mail box saftey = http://Struts_User_List.roomity.com *Your* clubs, no sign up to read, ad supported; try broadband internet. - 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]
AW: Forcing URL Rewriting over Cookies in an existing application .
Thank you! But it's not possible to do it the other way round in Tomcat right ? Also I think this should belong in the web.xml and shouldn't be container-specific, what do you think? Bernhard -Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 17:28 An: Struts Users Mailing List Betreff: RE: Forcing URL Rewriting over Cookies in an existing application. The same thing (disable cookies but enable url rewriting) should work on Tomcat 4.X and 5.X. See the cookies attribute in the below url(s): http://tomcat.apache.org/tomcat-4.0-doc/config/context.html http://tomcat.apache.org/tomcat-5.0-doc/config/context.html http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Regards, David -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 11:20 AM To: 'Struts Users Mailing List' Subject: AW: Forcing URL Rewriting over Cookies in an existing application. OT, but I'm interested, is this available im Tomcat too? Thanks Bernhard -Ursprüngliche Nachricht- Von: David G. Friedman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Januar 2006 17:08 An: Struts Users Mailing List Betreff: RE: Forcing URL Rewriting over Cookies in an existing application. http://access1.sun.com/techarticles/sessions.iws.html Regards, David -Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 10:53 AM To: user@struts.apache.org Subject: Forcing URL Rewriting over Cookies in an existing application. Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that uses Cookies for session handling and has been so for around 3/4 years. I have a requirement where I want to force URL Rewriting even if the browser supports cookies. Please help! Jay Broadband interface (RIA) + mail box saftey = http://Struts_User_List.roomity.com *Your* clubs, no sign up to read, ad supported; try broadband internet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: How does Shale affect my Struts development
Hi Jim, don't make the following mistake: I use Struts but I want to move on, so I have to use Shale! Shale is build ON TOP of JSF, so to understand the benefit of Shale you have to know JSF. So the first question to ask yourself: Do I want to move to JSF or is Struts just fine for me? When you decided to move to JSF or to at least take a closer look at it then after being familiar with JSF you can look at Shale and see if that's the right technology for you. I guess in your case you seem to be fine with Struts, so just stay with it! Bernhard -Ursprüngliche Nachricht- Von: Jim Reynolds [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 29. Dezember 2005 15:10 An: user@struts.apache.org Betreff: How does Shale affect my Struts development First off, a little background. I have started using the 'Struts' framework about 1 year ago. I have created three apps, and all is moving along pretty well with the Struts and model 2 approach. I am just starting to use more design patterns for my business logic, etc. Anyway, as you may be aware I frequent this list, and try to keep up with what is going on with the Struts project. I am noticing a lot of 'Shale' discussion, and I have just finished reading the link here http://struts.apache.org/struts-shale/ and franky, I am not sure what Shale brings to the table that is not already included with Struts? I guess, the reason for this post is, I was hoping possibly there are people out there who understand this Struts/Shale and could tell me how to get started, and what the gain is. Whether the best approach is to build a simple Struts app and convert it, or what steps I need to take in order to be prepared and keep my skill set where it needs to be. Regards - 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]
AW: validation error messages in JSF
You can use the Shale validation featrue. This supports client-side validation via javascript, it's also possible to switch off the server-side validation. Look at: http://struts.apache.org/struts-shale/features-commons-validator.html Cheers Bernhard -Ursprüngliche Nachricht- Von: JEEVANATHAM P. /BPCRP/INFOTECH/VASHI [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 21. Dezember 2005 13:00 An: 'Struts Users Mailing List' Betreff: validation error messages in JSF Hi all, We can do validation in JSF not by java script, on that time the error message will appear on the screen. For us, we don't need like that message in screen. We need to show as java script alert box. Is there any way to do this? Regards, JEEVANANTHAM PARAMASAMY, Software Engineer, 3i - INFOTECH Limited, Alwarpet, Chennai - 600018. Phone: 044 24678000 extn:418 Cell no: 09840933967 -- Greetings! ICICI Infotech is now 3i Infotech. The e-mail addresses of the company's employees have been changed to existing name@3i-infotech.com. You are requested to take note of this new e-mail ID and make use of the same in future This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and associated companies, (collectively 3i Infotech), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [ANNOUNCEMENT] Apache Struts offers Shale for JSF
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig I'd be happy to answer any specific questions on points that are in the slides. I realized that all features are documented except for the Remoting one http://struts.apache.org/struts-shale/features-remoting.html As this combines the hottest topics around (JSF, AJAX) it would be nice to have a few words about it. Thanks Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [OT] Re: Is JSF ready?
-Ursprüngliche Nachricht- Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] On Wed, December 14, 2005 9:37 am, Bill Schneider said: On the other hand, JSF does make doing some simple things hard. I think this is actually an excellent point, and I was thinking of it the other day and forgot to make it myself... This is a really good thread with a lot of valuable input: My opinion goes into this direction: Some stuff in JSF is really not so nice, one thing is also performance long lists take much longer than plain JSP. But you're still able to pick the goodies for yourself (form validation, state saving) and use plain JSP for the rest (bookmarking, long lists). JSF 1.2 works fine with JSP/JSTL, so now a soft migration becomes much easier. Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Strategy for javascript validation with i18n
If you want to try something new you can use AJAX in that way that your validation is done on the server but you still can have (more or less) instant javascript feedback without resubmitting the form. So you only have a thin javascript interface but your validation code is in Java on the server. Bernhard -Ursprüngliche Nachricht- Von: Kalra, Ashwani [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 25. November 2005 13:03 An: user@struts.apache.org Betreff: Strategy for javascript validation with i18n Hi all, In my multilingual project, I want to use my own custom Javascript validation instead of one provided by strusts 1.1 I have to do this because its not working in many cases with weblogic workshop, specially the indexed fields. My main concern is How can I provide a simple java script API which should take care 1. Getting the message from resource bundle 2. Substituting the message parameters 3. Doing different validation for different countries for the same field. For eg dd/mm/ for UK, but mm/dd/ for US 1 and 2 can be done with I18n tag, but 3rd is looking to be difficult as I want to use the common javascript method. Any have similar experience, please share with me. __ Thanks Ashwani Kalra This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [OT] JSF Interface Design - Is it Truly Limited?
Have a look at the clay component from shale, as this supports this type of development process more fully as you could then use the generated HTML from the graphic artists directly, just add some ids much like Tapestry does. Did you take a look at Facelets? It's something like Tapestry for JSF. Allows you to work with plain HTML tags. Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [Help] how to erase jsessionid in URL
I saw this question in the Tomcat mailing list every once in a while. The control of the session tracking machanism can't be controlled right now by the configuration. The spec should be changed to allow the user (in this case the deployer) to control the mechanism of session tracking. If I don't forget it I add it to the JSP 2.1 issue tracker. Until then I think the only possibility is really to change the Tomcat sources. Bernhard -Ursprüngliche Nachricht- Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. November 2005 08:49 An: Struts Users Mailing List Cc: Struts Users Mailing List Betreff: Re: [Help] how to erase jsessionid in URL On Tue, November 8, 2005 1:37 am, Pham Anh Tuan said: PS: if I want to change whether or not jsessionid is used, I must config container ? Do you have any document which instruct me how to reconfig container :(, if you had, plz show me, uh :) ... thank you :) I'm assuming it's possible, it would seem bizarre if it wasn't. In either case though, it's going to be container-specific, so you'd either have to ask on the appropriate list, or look through the docs. I use Tomcat and Websphere on a regular basis myself, and I don't know how to do it off the top of my head on either. Frank - 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]
AW: Shale timeline
Thanks, Ted that's really good! I quote that when someone asks me. I forward that to my boss too :-) Bernhard -Ursprüngliche Nachricht- Von: Ted Husted [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. November 2005 12:08 An: Struts Users Mailing List Betreff: Re: Shale timeline On 11/4/05, Rahul Akolkar [EMAIL PROTECTED] wrote: There is a very good write-up somewhere on the Apache site about how releases work, can't find it now, sorry. * http://struts.apache.org/helping.html#release -T. - 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]
AW: [shale] Advantages of Shale over JSF alone
I read the features the details there but being new to JSF too they just kind of blend in with JSF features. Shawn D. Garner I think before looking at Shale closer start to work with JSF standalone, you will only see the benfeits of Shale if you know (the shortcomings) of JSF. E.g. for understanding the dialogs in Shale and judge if it's useful for you have to understand the page navigation in JSF. If you feel confident and have some experience in JSF go back to Shale. Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Shale timeline
-Ursprüngliche Nachricht- Von: Rahul Akolkar [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 4. November 2005 17:55 As far as I'm concerned, the feature work I wanted to see for a 1.0.0release is complete In a nutshell, there are no dates (the process is driven by volunteers having enough time to finish up the tasks leading to a release). Also, I do not speak for the Struts Shale team, this is a broader comment. -Rahul Rahul, thanks for the answer. I see this point and it's propably better not to specify any dates, than conitiously postponing. It was just a (nice) try, because that's what people always asking first, but I think I can give them some useful information with the answers from you and Craig. Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale timeline
Hi, does anyone know when the first release 1.0 of struts shale is expected? Are there any other milestone dates like alpha, beta versions? Thanks Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Shale timeline
Hi Craig, thanks a lot for the answer, that's really helpful! Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. November 2005 17:57 As far as I'm concerned, the feature work I wanted to see for a 1.0.0release is complete You don't want to come up with a specific date, do you? Well I guess everyone understands this because we all were missing promisied target dates in our development life I guess :-) But on the other hand that's what the people want to know, WHEN can I have it? (I have to make a presentation about shale) This information is summarized in the Package Overview page for the core library: http://people.apache.org/~craigmcc/shale-core-javadocs/overview-summary.html That provides really useful information! Thanks again Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
