Re: [s2] Let's get out Struts 2.1.1
and ..?
Don Brown-2 wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15891265.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I'd definitely be interested in using a JQuery plugin for struts if it came out (has one already?). I've found the library to be very useful. The documentation is pretty good, though a little out of date wrt. some of the plugins (the UI ones notably, but they're getting a lot of dev work right now). Actually, my understanding is the lead JQuery developer is now being paid to work on the library full-time, and that he's putting a lot time into the UI plugins. Those would be useful to have available as struts tags. Also, I think JQuery fills a role that GWT likely would not wrt. integration with server-side web app frameworks, but maybe I'm wrong. -- Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
--- David Durham, Jr. [EMAIL PROTECTED] wrote: I'd definitely be interested in using a JQuery plugin for struts if it came out (has one already?). Not really; I had just barely started to convert the existing 2.1 plugin to jQuery then decided it really wouldn't help me very much. You're welcome to join the project [1] and help out; my time is pretty limited at the moment but I hope to get some of the basics working for the simple use-cases. I probably won't contribute much beyond the basics, because only the most basic stuff is useful as a tag for me. Dave [1] http://code.google.com/p/s2jquery/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I'm glad I am not the only what thinking this. I think dojo should be thrown out completely. Its a ridiculous that my normal 30KB web page request jumps to 500KB+ request as soon as I use the shead - ajax tag. I find jquery much smaller and easier to work with. Matt Musachy Barroso wrote: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. -- View this message in context: http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15652556.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Adam Peller wrote: Dojo 1.0 is all about performance and stability, and the follow-on Dojo 1.x releases continue in that direction with no radical changes to the core or Dijit architecture. Dojo base is now very tiny (25K, on par with other toolkits) and the performance of the new parser in the core is order of magnitudes better than the old one. I think you'll find the APIs are easier to use and programmatic instantiation more intuitive. Widgets are more easily customized and themable via CSS, there's a convenient xpath query mechanism that is actually among the fastest of the toolkits (see http://mootools.net/slickspeed/) On top Looking at the trend, not the final results. jquery seems faster via css selectors/class which seems to fit with its typical programming model. mootools faster via parent/child dom(are these via xpath?) relations. -- View this message in context: http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15652778.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XAP Support (WAS: Re: [s2] Let's get out Struts 2.1.1)
2008/2/22, Martin Cooper [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 8:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: What about the XAP framework then: http://incubator.apache.org/xap/ At least that team have already scratched their head :-) Well, understand that XAP is still in the incubator and is frankly a long way from graduating. Also, I would not look to XAP to solve any there might be significant changes between versions problem, given that they are in the process of creating their 0.5.0 release right now, and therefore well behind Dojo on the API stability curve. Don't get me wrong, I don't want anyone from changin from Dojo to XAP. I only wanted to let Struts developers know about this opportunity and, maybe, create a (sandboxed) plugin for XAP. Nothing more. We've had Dojo support in S2 for quite some time now, and Dojo has since significantly stabilised and improved. It's not at all clear to me that jumping horses would be a good thing, given that we already have a bunch of people using the Dojo-based code, and given that switching to a new code base will reset us to square one when it comes to ironing out the issues that we will inevitably discover in whatever framework we might switch to. +1, but with XAP support I meant an experiment. Sorry for the misunderstanding. Antonio
Re: Re ajax result discrepancy (was Re: [s2] Let's get out Struts 2.1.1)
Hi guys, I'm just a Struts 2 (heavy) user, but I think I can contribute with that. Sometime ago I wrote a Struts Interceptor and a Sitemesh Decorator Mapper that can apply a different (sometimes empty) decorator when you have an ajax request: mapper class=com.fabianofranz.toolkit.sitemesh.decorator.HttpHeaderDecoratorMapper /mapper I use it to graceful degradation - on links, the website loads pages using ajax and in that case sitemesh applies an empty decorator, but if the user disable javascript, it stay working as normal links, with the same actions, and sitemesh applies the full page design decorator. You can see it working (click the paging links): http://literar.org/users If you want, I can share this code - it's quite simple. Best regards, Fabiano Franz http://fabianofranz.com Jeromy Evans - Blue Sky Minds wrote: Blake Byrnes wrote: I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest Nice idea. I'd been differentiating by extension (xhtml for ajax) which has been getting out-of-hand. -- View this message in context: http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15633394.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XAP Support (WAS: Re: [s2] Let's get out Struts 2.1.1)
Try ExtJS and u will find it amazing. jmitchell wrote: I think everyone should take a long serious look at ExtJS. I'm using it on my current gig right now (very large s2 app) and except for a few small quirks, it is helping us cover far more ground than we could without it or with a different framework. Trust me, you can't appreciate it until you try it. http://extjs.com/ On Thu, Feb 21, 2008 at 11:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/21, Musachy Barroso [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. What about the XAP framework then: http://incubator.apache.org/xap/ At least that team have already scratched their head :-) Antonio -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/XAP-Support-%28WAS%3A-Re%3A--s2--Let%27s-get-out-Struts-2.1.1%29-tp15615274p15633905.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
opposed to half way through the 2.1 lifecycle. I'd also like to see a change to actrionError and actionMessage handling which removes the need for the store interceptor for redirects, but I know that's something that's in the very early stages of thought. That would be great. This should probably be available out of the box. P.S. Personally I'm not a fan of x.5 versions, they kind of indicate that it's a almost a big jump, but not quite, but possibly. I think 2.1 reflects the fact that the API is largely unchanged with only some small sections that need to be addressed during a migration (such as dojo being split out). Actually, many of the configuration APIs in XWork have changed and Struts 2 configuration completely changed, breaking all existing applications that use interceptors by id (just to name a few major changes). So, from a compatibility perspective, 2.1 is a very major release. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Is there a list of gotchas for a 2.0 to 2.1 migration? Al. - Original Message - From: Brian Pontarelli [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Thursday, February 21, 2008 3:23 PM Subject: Re: [s2] Let's get out Struts 2.1.1 opposed to half way through the 2.1 lifecycle. I'd also like to see a change to actrionError and actionMessage handling which removes the need for the store interceptor for redirects, but I know that's something that's in the very early stages of thought. That would be great. This should probably be available out of the box. P.S. Personally I'm not a fan of x.5 versions, they kind of indicate that it's a almost a big jump, but not quite, but possibly. I think 2.1 reflects the fact that the API is largely unchanged with only some small sections that need to be addressed during a migration (such as dojo being split out). Actually, many of the configuration APIs in XWork have changed and Struts 2 configuration completely changed, breaking all existing applications that use interceptors by id (just to name a few major changes). So, from a compatibility perspective, 2.1 is a very major release. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Making the tags work with the latest version of dojo would take a lot of work (pretty much scratch all the hacks we have put together so far to make it work). What is really frustrating is that after spending time getting everything to work on one version, all hell breaks loose on the next minor release. The dojo plugin is a lot better in 2.1 that it was on 2.0.x, but by the time that 2.1 goes GA dojo will be on version 97 or so :). I would say we get the plugin out of the code base and set it up in googlecode and give access to anyone that wants to maintain it. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. //have you seen how many emails we get with question about dojo vs struts itself? musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
--- Al Sutton [EMAIL PROTECTED] wrote: Is there a list of gotchas for a 2.0 to 2.1 migration? One was started at http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
The Microsoft YUI? :D I had forgot that. /cry. Good thing that it has a BSD license. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XAP Support (WAS: Re: [s2] Let's get out Struts 2.1.1)
2008/2/21, Musachy Barroso [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. What about the XAP framework then: http://incubator.apache.org/xap/ At least that team have already scratched their head :-) Antonio
Re: [s2] Let's get out Struts 2.1.1
--- Musachy Barroso [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Yikes. The issue with the Dojo plugin (and any other, like my somewhat-waylaid jQuery plugin) is that I end up writing all the JavaScript anyway, and the tags don't help me very much in all but the *most* basic use-cases. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. The Microsoft YUI? :D Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Dave Newton wrote: --- Musachy Barroso [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Also my conclusion when the ajax code was ported from ww2 to s2. And I was really happy when you took over maintaining the code ;-) Yikes. The issue with the Dojo plugin (and any other, like my somewhat-waylaid jQuery plugin) is that I end up writing all the JavaScript anyway, and the tags don't help me very much in all but the *most* basic use-cases. The other conclusion I came to, about the same time as above. To take jQuery (which I've being working with a bit lately), even if you have a s2 plug-in/theme, there may need to be continuous updates or additions depending on the different plug-ins being used with the jQuery core. Also, with jQuery again, in some cases you will also need to take into account whether the page being returned is part of an ajax request itself. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. The Microsoft YUI? :D Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I may get boos on this, but I've thought about creating a hand-rolled AJAX plugin. I like the available JS frameworks like Prototype/Dojo/JQuery, but it does seem like there are a lot of gotchas with any one of them. Having written some XHR processing in vanilla javascript, sometimes I wonder how hard it would be to maintain a tag library specifically developed to integrate with Struts2... The benefit would be in maintenance, since it would be more closely tied to the development of Struts2 (and possibly performance, though a lot of work was done in the dojo-plugin), but the disadvantage would be that a lot of JS code would need developed up front. Another thought I've had on the topic is to separate the concerns within the AJAX components, you have a set of widgets (tabbedpanel, divs, autocompleter) and a set of components related to processing (JSON, XHR, etc). It would be great to make these two things separated to the point that the YUI widgets could be dropped in and combined with the Prototype processing so that the YUI tabbedpanel could be populated by JQuery calls... The goal would be to give a somewhat savvy AJAX developer the freedom to pull in the widgets they like combined with the JS code style they prefer. -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest 2) An Interceptor and interface for dealing with Ajax requests that allows you to specify a different result. The method is called beforeResult allowing you to change it if necessary. 3) A way to ask for views: sharing actions creates extreme complexity if you have multiple pages that have different results under different contexts (ie, a get on a resource may return a specific html fragment if it is requested from a list view, which is different from what should happen if it's requested from a regular get view on the resource). To deal with this, i basically let the view specify the returning view of the data from the ajax request by just adding a request param = RespondWith=user/row-view, and then translate that into the appropriate jsp and return on server side. This currently operates in a few different places (ie, a base action, a generic jquery script, and interceptors/interfaces). I'd be happy to share the code, but I think what this starts to get at is the same thing that has come up a few times on this list - what exactly is struts trying to become? I also have code to allow auto-retrieval of JPA entities on an action using an interceptor. The question for me is where should struts stop and some sort of integrating framework start? I do think it would be nice to have a REST, JPA, Struts, Ajaxy app framework that is ready to go with Sitemesh, etc and lets you just start building out actions and take advantage of all this stuff, but I don't know where it should live. It starts to sound like Appfuse specifically geared to Struts at some point too. Anyone have any thoughts? Blake On Thu, Feb 21, 2008 at 12:15 PM, Ian Roughley [EMAIL PROTECTED] wrote: Dave Newton wrote: --- Musachy Barroso [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Also my conclusion when the ajax code was ported from ww2 to s2. And I was really happy when you took over maintaining the code ;-) Yikes. The issue with the Dojo plugin (and any other, like my somewhat-waylaid jQuery plugin) is that I end up writing all the JavaScript anyway, and the tags don't help me very much in all but the *most* basic use-cases. The other conclusion I came to, about the same time as above. To take jQuery (which I've being working with a bit lately), even if you have a s2 plug-in/theme, there may need to be continuous updates or additions depending on the different plug-ins being used with the jQuery core. Also, with jQuery again, in some cases you will also need to take into account whether the page being returned is part of an ajax request itself. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. The Microsoft YUI? :D Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I, for one, would love to see two classes of struts/ajax tags in S2.1; Class 1 - Core support tags that all ajax plugins support which would allow developers to swap backends. Class 2 - Plugin specific tags, for covering those ajax framework specific functions which are just too cool to leave out. I'd suggest that Class 1 comes from all the tags which were in S2.0 core and moved out to the plugin in S2.1, this would give S2.0 users a smoother migration path knowing that they can chop and change ajax plugins to find one they like without the risk of wasting time on a plugin that doesn't deliver what they need. Al. - Original Message - From: Wes Wannemacher [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Thursday, February 21, 2008 5:36 PM Subject: Re: [s2] Let's get out Struts 2.1.1 I may get boos on this, but I've thought about creating a hand-rolled AJAX plugin. I like the available JS frameworks like Prototype/Dojo/JQuery, but it does seem like there are a lot of gotchas with any one of them. Having written some XHR processing in vanilla javascript, sometimes I wonder how hard it would be to maintain a tag library specifically developed to integrate with Struts2... The benefit would be in maintenance, since it would be more closely tied to the development of Struts2 (and possibly performance, though a lot of work was done in the dojo-plugin), but the disadvantage would be that a lot of JS code would need developed up front. Another thought I've had on the topic is to separate the concerns within the AJAX components, you have a set of widgets (tabbedpanel, divs, autocompleter) and a set of components related to processing (JSON, XHR, etc). It would be great to make these two things separated to the point that the YUI widgets could be dropped in and combined with the Prototype processing so that the YUI tabbedpanel could be populated by JQuery calls... The goal would be to give a somewhat savvy AJAX developer the freedom to pull in the widgets they like combined with the JS code style they prefer. -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I'd suggest that Class 1 comes from all the tags which were in S2.0 core and moved out to the plugin in S2.1, this would give S2.0 users a smoother migration path knowing that they can chop and change ajax plugins to find one they like without the risk of wasting time on a plugin that doesn't deliver what they need. The problem with this approach is that sometimes the widgets are way tot different between frameworks. musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Musachy Barroso wrote: I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Musachy, have you looked at Dojo lately? I can understand your frustration, especially given that you're on what's now a pretty old release of Dojo. Please take a good hard look at Dojo 1.0 (or 1.1beta) before you make any rash decisions. I'd very much like to see your codebase upgraded to get your users the best experience. I hope you try out Dojo 1.0 and take your questions / issues to us at the dojotoolkit.org forums. ...What is really frustrating is that after spending time getting everything to work on one version, all hell breaks loose on the next minor release. The 0.4-0.9 rewrite was not a typical minor release. The shift in version numbers was intended to indicate that. And that was still relatively early in the development of Dojo -- note the smaller decimal. Dojo has matured significantly since then, based on this rewrite and one time, ok, massive API shift. We know this has a lot of impact on people like you and we don't take that lightly or have any plans to do it again. The dojo plugin is a lot better in 2.1 that it was on 2.0.x, but by the time that 2.1 goes GA dojo will be on version 97 or so :) Since then, Dojo has been quite stable and has been sticking to a deprecation cycle of one major release, which we expect to be at least a year, and that's just for minor API changes. Our roadmap has no Dojo 97.0. Dojo 1.0 is all about performance and stability, and the follow-on Dojo 1.x releases continue in that direction with no radical changes to the core or Dijit architecture. Dojo base is now very tiny (25K, on par with other toolkits) and the performance of the new parser in the core is order of magnitudes better than the old one. I think you'll find the APIs are easier to use and programmatic instantiation more intuitive. Widgets are more easily customized and themable via CSS, there's a convenient xpath query mechanism that is actually among the fastest of the toolkits (see http://mootools.net/slickspeed/) On top of that, I'll remind you that Dojo is totally open source with extremely friendly licenses that should be fully compatible with yours. //have you seen how many emails we get with question about dojo vs struts itself? We should find a way of directing those users to dojotoolkit.org for support. Getting them off the very old release should solve the majority of their issues. Regards, Adam Peller Dojo committer -- View this message in context: http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15618307.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Just some additional thoughts on this front... It seems like most frameworks are heading in very similar directions now. They are all getting lighter, faster, and better at selecting and manipulating elements. I'm in favor or having some AJAX functionality baked, but I have never found it very difficult to write custom handling when necessary. I use JQuery for everything and writing a date picker, validation, AJAX form submits, etc was fairly easy. -bp Adam Peller wrote: Musachy Barroso wrote: I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Musachy, have you looked at Dojo lately? I can understand your frustration, especially given that you're on what's now a pretty old release of Dojo. Please take a good hard look at Dojo 1.0 (or 1.1beta) before you make any rash decisions. I'd very much like to see your codebase upgraded to get your users the best experience. I hope you try out Dojo 1.0 and take your questions / issues to us at the dojotoolkit.org forums. ...What is really frustrating is that after spending time getting everything to work on one version, all hell breaks loose on the next minor release. The 0.4-0.9 rewrite was not a typical minor release. The shift in version numbers was intended to indicate that. And that was still relatively early in the development of Dojo -- note the smaller decimal. Dojo has matured significantly since then, based on this rewrite and one time, ok, massive API shift. We know this has a lot of impact on people like you and we don't take that lightly or have any plans to do it again. The dojo plugin is a lot better in 2.1 that it was on 2.0.x, but by the time that 2.1 goes GA dojo will be on version 97 or so :) Since then, Dojo has been quite stable and has been sticking to a deprecation cycle of one major release, which we expect to be at least a year, and that's just for minor API changes. Our roadmap has no Dojo 97.0. Dojo 1.0 is all about performance and stability, and the follow-on Dojo 1.x releases continue in that direction with no radical changes to the core or Dijit architecture. Dojo base is now very tiny (25K, on par with other toolkits) and the performance of the new parser in the core is order of magnitudes better than the old one. I think you'll find the APIs are easier to use and programmatic instantiation more intuitive. Widgets are more easily customized and themable via CSS, there's a convenient xpath query mechanism that is actually among the fastest of the toolkits (see http://mootools.net/slickspeed/) On top of that, I'll remind you that Dojo is totally open source with extremely friendly licenses that should be fully compatible with yours. //have you seen how many emails we get with question about dojo vs struts itself? We should find a way of directing those users to dojotoolkit.org for support. Getting them off the very old release should solve the majority of their issues. Regards, Adam Peller Dojo committer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Dave Newton wrote: --- Al Sutton [EMAIL PROTECTED] wrote: Is there a list of gotchas for a 2.0 to 2.1 migration? One was started at http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html There are more that should be added to this page. I'll try to get those in there when I have some time. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Brian Pontarelli wrote: Dave Newton wrote: --- Al Sutton [EMAIL PROTECTED] wrote: Is there a list of gotchas for a 2.0 to 2.1 migration? One was started at http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html There are more that should be added to this page. I'll try to get those in there when I have some time. The key backwards compatibility points also belong here as its the first place anyone will look: http://struts.apache.org/2.x/docs/version-notes-211.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Ian Roughley wrote: Dave Newton wrote: --- Musachy Barroso [EMAIL PROTECTED] wrote: Yikes. The issue with the Dojo plugin (and any other, like my somewhat-waylaid jQuery plugin) is that I end up writing all the JavaScript anyway, and the tags don't help me very much in all but the *most* basic use-cases. The other conclusion I came to, about the same time as above. To take jQuery (which I've being working with a bit lately), even if you have a s2 plug-in/theme, there may need to be continuous updates or additions depending on the different plug-ins being used with the jQuery core. Also, with jQuery again, in some cases you will also need to take into account whether the page being returned is part of an ajax request itself. I came to the same conclusion with YUI. It's not at all suited to creating custom tags. YUI uses plain degradable html and the YUI community encourages good javascript practices (rather than inline scripts). Dojo was an good fit as it parses the markup for widgets, whereas creating tags for YUI has been counter-productive for anything except the simplest cases. I also suspect that rather than creating new Dojo tags, Struts 2 users that want Dojo 1.0+ should follow the recommended practices of the Dojo community. Using Struts tags has resulted in users that don't understand the underlying mechanism and generally don't know how to ask the Dojo community the right questions. I'm in favour of easing integration, such as catering for Dojo SMP/RPC, but otherwise I don't think the effort justifies the result. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. I have created tags for the explicit purpose of migrating an existing application from the Dojo 0.40 plugin to YUI for the div, submit, tabbedpanel, anchor etc. At the most, I think these tags are useful for beginners that want to use tags with some default javascript behaviour before dipping their feet into writing client-side code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XAP Support (WAS: Re: [s2] Let's get out Struts 2.1.1)
I think everyone should take a long serious look at ExtJS. I'm using it on my current gig right now (very large s2 app) and except for a few small quirks, it is helping us cover far more ground than we could without it or with a different framework. Trust me, you can't appreciate it until you try it. http://extjs.com/ On Thu, Feb 21, 2008 at 11:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/21, Musachy Barroso [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. What about the XAP framework then: http://incubator.apache.org/xap/ At least that team have already scratched their head :-) Antonio -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XAP Support (WAS: Re: [s2] Let's get out Struts 2.1.1)
On Thu, Feb 21, 2008 at 8:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/21, Musachy Barroso [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton [EMAIL PROTECTED] wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. What about the XAP framework then: http://incubator.apache.org/xap/ At least that team have already scratched their head :-) Well, understand that XAP is still in the incubator and is frankly a long way from graduating. Also, I would not look to XAP to solve any there might be significant changes between versions problem, given that they are in the process of creating their 0.5.0 release right now, and therefore well behind Dojo on the API stability curve. We've had Dojo support in S2 for quite some time now, and Dojo has since significantly stabilised and improved. It's not at all clear to me that jumping horses would be a good thing, given that we already have a bunch of people using the Dojo-based code, and given that switching to a new code base will reset us to square one when it comes to ironing out the issues that we will inevitably discover in whatever framework we might switch to. -- Martin Cooper Antonio
Re ajax result discrepancy (was Re: [s2] Let's get out Struts 2.1.1)
Blake Byrnes wrote: I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest Nice idea. I'd been differentiating by extension (xhtml for ajax) which has been getting out-of-hand. 2) An Interceptor and interface for dealing with Ajax requests that allows you to specify a different result. The method is called beforeResult allowing you to change it if necessary. 3) A way to ask for views: sharing actions creates extreme complexity if you have multiple pages that have different results under different contexts (ie, a get on a resource may return a specific html fragment if it is requested from a list view, which is different from what should happen if it's requested from a regular get view on the resource). The REST plugin deals with similar issues through the RestActionMapper, RestActionInvocation and ContentTypeHandler. The first two for invoking the appropriate method and selecting a view and the latter for handling other result types for the same action (xml, json etc). I think the REST plugin takes an excellent approach to this problem but you may be able to apply some lessons learnt to them as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re ajax result discrepancy (was Re: [s2] Let's get out Struts 2.1.1)
Hey Jeremy, Thanks for writing back. I was kind of starting to wonder if I wasn't supposed to be posting to this list :). I really like portions of the REST plugin, but I wanted to be able to leverage a lot of the interface and class level patterns in Struts (ie, 1 class 1 action), so I ended up rewriting it to support class level actions grouped by package (instead of method level). My packages now have a GetAction, ListAction, CreateAction, RemoveAction, and New Action. Once I did that, I got a lot of freedom back to use the implementing patterns to do specific things that should always happen in a list action or a remove action. I also built it to support nested namespaces (similar to codebehind, but allowing nested resource ids and params as well), and to allow an annotation called AutoPopulate to allow JPA retrieval of objects between the Param id interceptor sandwich. I ended up with actions that hardly ever need configuration of any sort (inherited way to zero config). The REST plugin does handle json and xml responses, but I was finding that it didn't really work so well with hibernate objects. I also was mainly concerned with html fragments for Ajax requests and returning those. You can do this in the REST plugin programatically using the HTTPHeaders result, but I wanted something that guessed what I wanted by default, and let me override only when I needed to. Essentially, I wanted 1 method per action, default, inherited results, and the ability to override programatically. So my overall goal was to have really simple actions that could be reused by different content types and by ajax/regular html without much extra configuration or redundant request parameters. As far as I could tell in the REST plugin, the http methods against a resource are delegated to methods, but there wasn't a distinguished ajax handling of results by method. I've sort of rearranged that plugin to what I needed. I'm not even sure how to share back what I've got other than just posting them to a JIRA ticket or a sandbox and letting people take a look. Let me know how/if you are interested and I can put them up somewhere. (Maybe this should just go into another big plugin... my mini-framework also supports auto-back on post and a bunch of other things...). Blake On Fri, Feb 22, 2008 at 12:18 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Blake Byrnes wrote: I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest Nice idea. I'd been differentiating by extension (xhtml for ajax) which has been getting out-of-hand. 2) An Interceptor and interface for dealing with Ajax requests that allows you to specify a different result. The method is called beforeResult allowing you to change it if necessary. 3) A way to ask for views: sharing actions creates extreme complexity if you have multiple pages that have different results under different contexts (ie, a get on a resource may return a specific html fragment if it is requested from a list view, which is different from what should happen if it's requested from a regular get view on the resource). The REST plugin deals with similar issues through the RestActionMapper, RestActionInvocation and ContentTypeHandler. The first two for invoking the appropriate method and selecting a view and the latter for handling other result types for the same action (xml, json etc). I think the REST plugin takes an excellent approach to this problem but you may be able to apply some lessons learnt to them as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re ajax result discrepancy (was Re: [s2] Let's get out Struts 2.1.1)
Sounds good. If you can, I think you should share it. Host it at googlecode, add it to the plugin registry and announce it on the users list. There's plenty of S2 plugins hosted at googlecode, some that have many downloads. If its popular and useful it'll soon be noticed. That's how SmartURLs has migrated into the Convention plugin. The trouble with conventions, like one method per action vs multiple methods per action, is that everyone has a different valid opinion. The developer of the REST plugin chose to follow the conventions of ruby-on-rails because its proven there. Your approach sounds good too and I've also encountered the same issues regarding common behaviour for methods (eg. for example, implement an Index interface and delegate when appropriate). Brian P has also started an application stack including S2, conventions and JPA on googlecode that's probably worth a look at : http://code.google.com/p/vertigo-java/ I feel anything that increases the productivity of java developers is a good thing, as is sharing what's been learnt. Blake Byrnes wrote: Hey Jeremy, Thanks for writing back. I was kind of starting to wonder if I wasn't supposed to be posting to this list :). I really like portions of the REST plugin, but I wanted to be able to leverage a lot of the interface and class level patterns in Struts (ie, 1 class 1 action), so I ended up rewriting it to support class level actions grouped by package (instead of method level). My packages now have a GetAction, ListAction, CreateAction, RemoveAction, and New Action. Once I did that, I got a lot of freedom back to use the implementing patterns to do specific things that should always happen in a list action or a remove action. I also built it to support nested namespaces (similar to codebehind, but allowing nested resource ids and params as well), and to allow an annotation called AutoPopulate to allow JPA retrieval of objects between the Param id interceptor sandwich. I ended up with actions that hardly ever need configuration of any sort (inherited way to zero config). The REST plugin does handle json and xml responses, but I was finding that it didn't really work so well with hibernate objects. I also was mainly concerned with html fragments for Ajax requests and returning those. You can do this in the REST plugin programatically using the HTTPHeaders result, but I wanted something that guessed what I wanted by default, and let me override only when I needed to. Essentially, I wanted 1 method per action, default, inherited results, and the ability to override programatically. So my overall goal was to have really simple actions that could be reused by different content types and by ajax/regular html without much extra configuration or redundant request parameters. As far as I could tell in the REST plugin, the http methods against a resource are delegated to methods, but there wasn't a distinguished ajax handling of results by method. I've sort of rearranged that plugin to what I needed. I'm not even sure how to share back what I've got other than just posting them to a JIRA ticket or a sandbox and letting people take a look. Let me know how/if you are interested and I can put them up somewhere. (Maybe this should just go into another big plugin... my mini-framework also supports auto-back on post and a bunch of other things...). Blake On Fri, Feb 22, 2008 at 12:18 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Blake Byrnes wrote: I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest Nice idea. I'd been differentiating by extension (xhtml for ajax) which has been getting out-of-hand. 2) An Interceptor and interface for dealing with Ajax requests that allows you to specify a different result. The method is called beforeResult allowing you to change it if necessary. 3) A way to ask for views: sharing actions creates extreme complexity if you have multiple pages that have different results under different contexts (ie, a get on a resource may return a specific html fragment if it is requested from a list view, which is different from what should happen if it's requested from a regular get view on the resource). The REST plugin deals with similar issues through the RestActionMapper, RestActionInvocation and ContentTypeHandler. The first two for invoking the appropriate method and selecting a view and the latter for handling other result types for the same action (xml, json etc). I think the REST plugin takes an excellent approach to this problem but you may be able to apply some lessons learnt to them as well.
Re: Re ajax result discrepancy (was Re: [s2] Let's get out Struts 2.1.1)
Yeah, true enough. Although the 2 things I never loved with rails were resolving multiple action methods with all the different validations and before_ hooks, etc that you only wanted to run for one or two of the methods, and 2) empty active record models. But that's a different discussion :) I'll check out Vertigo and see if I can throw together some sort of hosted code. The problem with throwing plugins out there is I know I don't go near the ones that don't look active, so it's hard for me to expect someone else to. On Fri, Feb 22, 2008 at 1:17 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Sounds good. If you can, I think you should share it. Host it at googlecode, add it to the plugin registry and announce it on the users list. There's plenty of S2 plugins hosted at googlecode, some that have many downloads. If its popular and useful it'll soon be noticed. That's how SmartURLs has migrated into the Convention plugin. The trouble with conventions, like one method per action vs multiple methods per action, is that everyone has a different valid opinion. The developer of the REST plugin chose to follow the conventions of ruby-on-rails because its proven there. Your approach sounds good too and I've also encountered the same issues regarding common behaviour for methods (eg. for example, implement an Index interface and delegate when appropriate). Brian P has also started an application stack including S2, conventions and JPA on googlecode that's probably worth a look at : http://code.google.com/p/vertigo-java/ I feel anything that increases the productivity of java developers is a good thing, as is sharing what's been learnt. Blake Byrnes wrote: Hey Jeremy, Thanks for writing back. I was kind of starting to wonder if I wasn't supposed to be posting to this list :). I really like portions of the REST plugin, but I wanted to be able to leverage a lot of the interface and class level patterns in Struts (ie, 1 class 1 action), so I ended up rewriting it to support class level actions grouped by package (instead of method level). My packages now have a GetAction, ListAction, CreateAction, RemoveAction, and New Action. Once I did that, I got a lot of freedom back to use the implementing patterns to do specific things that should always happen in a list action or a remove action. I also built it to support nested namespaces (similar to codebehind, but allowing nested resource ids and params as well), and to allow an annotation called AutoPopulate to allow JPA retrieval of objects between the Param id interceptor sandwich. I ended up with actions that hardly ever need configuration of any sort (inherited way to zero config). The REST plugin does handle json and xml responses, but I was finding that it didn't really work so well with hibernate objects. I also was mainly concerned with html fragments for Ajax requests and returning those. You can do this in the REST plugin programatically using the HTTPHeaders result, but I wanted something that guessed what I wanted by default, and let me override only when I needed to. Essentially, I wanted 1 method per action, default, inherited results, and the ability to override programatically. So my overall goal was to have really simple actions that could be reused by different content types and by ajax/regular html without much extra configuration or redundant request parameters. As far as I could tell in the REST plugin, the http methods against a resource are delegated to methods, but there wasn't a distinguished ajax handling of results by method. I've sort of rearranged that plugin to what I needed. I'm not even sure how to share back what I've got other than just posting them to a JIRA ticket or a sandbox and letting people take a look. Let me know how/if you are interested and I can put them up somewhere. (Maybe this should just go into another big plugin... my mini-framework also supports auto-back on post and a bunch of other things...). Blake On Fri, Feb 22, 2008 at 12:18 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Blake Byrnes wrote: I dealt with the ajax result discrepency (ie, if you make an ajax request, you generally want a different result, but probably want to share the same action) by writing a few things: 1) A sitemesh filter that ignores requests with the content header X-Requested-With=XMLHttpRequest Nice idea. I'd been differentiating by extension (xhtml for ajax) which has been getting out-of-hand. 2) An Interceptor and interface for dealing with Ajax requests that allows you to specify a different result. The method is called beforeResult allowing you to change it if necessary. 3) A way to ask for views: sharing actions creates extreme complexity if you have multiple pages that have different results under different contexts (ie, a get on a
Re: [s2] Let's get out Struts 2.1.1
The API has yet to be solidified and there are a few things that I'd still like to discuss and possibly change in that regard. My main goal is to ensure backwards compatibility in the convention plugin API. Furthermore, I think we should all start thinking about when the true stable release of XWork and Struts2 will be. I think it makes sense to target the next release and jump up to 2.5 or some number to indicate stable APIs. This would include a number of API clean-ups, OGNL replacement and a few other things that will severely break plugins and applications. After that release, API changes should be compatible so that plugins and applications can be upgraded without requiring re-compiling. Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. -bp Piero Sartini wrote: I think you should release the convention plugin at all costs - but this is just a vote from an user. piero Am Montag, 18. Februar 2008 18:16:52 schrieb Brian Pontarelli: Don Brown wrote: I've cleared all but a couple issues out of Struts 2.1.1, so I think we are ready for a release. The only kinda blocking issue is the portlet tests failing, but that seems to have something to do with the setup, not our portlet code, so we could even punt that one. Any objections to rolling a release(*) in the next day or so? Shall we queue up the convention plugin addition and deprecation of the smarturls and code-behind plugins for next release than? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
2008/2/20, Brian Pontarelli [EMAIL PROTECTED]: The API has yet to be solidified... About future and current development. Releasing a distribution does not mean that it must be complete: we will vote its quality and, from your discussion, I presume that it will be alpha. But, at least, developers can start playing with it. Just my 2 eurocents. Antonio
Re: [s2] Let's get out Struts 2.1.1
Don, on the subject of XWork releases, I should have made this a blocker, but this bug needs to be closed and I have a fix ready, just don't have commit access. The patch is also in the bug if you want to take care of it: http://jira.opensymphony.com/browse/XW-599 -bp Don Brown wrote: Oh, I know how to release Struts; I was referring to the XWork release. IIRC, this will be the first release with the Maven 2 build, so we'll see how it goes... Don On 2/20/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Feb 19, 2008 6:01 AM, Don Brown [EMAIL PROTECTED] wrote: Are there any special instructions or is it a simple 'mvn release:prepare release:perform'? Antonio linked to this earlier: http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
+1! Fabiano Franz http://fabianofranz.com http://literar.org Piero Sartini-3 wrote: I think you should release the convention plugin at all costs - but this is just a vote from an user. piero -- View this message in context: http://www.nabble.com/-s2--Let%27s-get-out-Struts-2.1.1-tp15519065p15598056.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Am Mittwoch, 20. Februar 2008 17:16:51 schrieb Brian Pontarelli: The API has yet to be solidified and there are a few things that I'd still like to discuss and possibly change in that regard. My main goal is to ensure backwards compatibility in the convention plugin API. My thinking is like this: upgrading from [today's convention-plugin] to [final convention-plugin] will be much easier than upgrading from [codebehind] to the [final convention-plugin]. If convention-plugin is not bundled with the next release, people will stick to the codebehind plugin. Last time I checked there was no smarturls for 2.1.x as well - so there is really not much choice. (compiling from the sandbox is no option for most users) Furthermore, I think we should all start thinking about when the true stable release of XWork and Struts2 will be. Isn't a GA release meant to be a true stable release? I think to know what you want to say, but I am still somewhat confused about why releases in s2 are working the way they do. I think it makes sense to target the next release and jump up to 2.5 or some number to indicate stable APIs. This would include a number of API clean-ups, OGNL replacement and a few other things that will severely break plugins and applications. After that release, API changes should be compatible so that plugins and applications can be upgraded without requiring re-compiling. I am quite sure there will rise another list with new issues that should be resolved before a true release in some time... In my oppinion, API stability is nothing that comes with reaching some feature set or project milestone. This would imply stopping innovation at that point. For me, API stability needs to be some kind of project goal or philosophy - which needs to be enforced by defining commonly accepted rules. But my impression is that this is no (important) goal for s2, and I can hardly imagine that it will be one day just because it gets to a point where _today's_ most wanted features are implemented. But maybe this is worth a new thread... Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. Is it possible to release a 2.1.1 plugin after the core? In this case I do not feel like it is that important to make it part of the s2.1.1 release :) Until now I thought that the next possible release for the convention plugin would be 2.1.2 (or whatever build makes it). Piero disclaimer: I am just a happy convention-plugin user who tries to learn more about s2 development. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
If convention-plugin is not bundled with the next release, people will stick to the codebehind plugin. Last time I checked there was no smarturls for 2.1.x as well - so there is really not much choice. (compiling from the sandbox is no option for most users) You are probably correct. However, unless everyone agrees to promote convention plugin out of the sandbox and solidify it in the next few days or so, it will have to be a separate release outside of the bundle. Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. Is it possible to release a 2.1.1 plugin after the core? In this case I do not feel like it is that important to make it part of the s2.1.1 release :) Until now I thought that the next possible release for the convention plugin would be 2.1.2 (or whatever build makes it). Not really if you want it in the bundle. Otherwise, it would be an external download until 2.1.2 or some version like that. I'm up for anything Thoughts? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Here's the thing - I'm going to create the 2.1.1 test build on Sunday, hopefully followed by test builds every couple weeks or so. Whatever you can get into the code by those dates will be included in the subsequent release. Honestly, I don't expect 2.1.1 to be GA, but am aiming for a Beta vote. I would like to see a GA release sometime around the 2.1.4 timeframe, though. Don On 2/21/08, Brian Pontarelli [EMAIL PROTECTED] wrote: If convention-plugin is not bundled with the next release, people will stick to the codebehind plugin. Last time I checked there was no smarturls for 2.1.x as well - so there is really not much choice. (compiling from the sandbox is no option for most users) You are probably correct. However, unless everyone agrees to promote convention plugin out of the sandbox and solidify it in the next few days or so, it will have to be a separate release outside of the bundle. Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. Is it possible to release a 2.1.1 plugin after the core? In this case I do not feel like it is that important to make it part of the s2.1.1 release :) Until now I thought that the next possible release for the convention plugin would be 2.1.2 (or whatever build makes it). Not really if you want it in the bundle. Otherwise, it would be an external download until 2.1.2 or some version like that. I'm up for anything Thoughts? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, because I can see this may cause some headaches which would be best done at the start of the 2.1 GA releases as opposed to half way through the 2.1 lifecycle. I'd also like to see a change to actrionError and actionMessage handling which removes the need for the store interceptor for redirects, but I know that's something that's in the very early stages of thought. I think there is value in releasing a new stable 2.1 snapshot to give developers on s2 projects something to play with so they can see where the 2.1 branch is going, but I don't think that the next release will go GA given the current state of the svn trunk head. Al. P.S. Personally I'm not a fan of x.5 versions, they kind of indicate that it's a almost a big jump, but not quite, but possibly. I think 2.1 reflects the fact that the API is largely unchanged with only some small sections that need to be addressed during a migration (such as dojo being split out). - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Wednesday, February 20, 2008 10:54 PM Subject: Re: [s2] Let's get out Struts 2.1.1 Here's the thing - I'm going to create the 2.1.1 test build on Sunday, hopefully followed by test builds every couple weeks or so. Whatever you can get into the code by those dates will be included in the subsequent release. Honestly, I don't expect 2.1.1 to be GA, but am aiming for a Beta vote. I would like to see a GA release sometime around the 2.1.4 timeframe, though. Don On 2/21/08, Brian Pontarelli [EMAIL PROTECTED] wrote: If convention-plugin is not bundled with the next release, people will stick to the codebehind plugin. Last time I checked there was no smarturls for 2.1.x as well - so there is really not much choice. (compiling from the sandbox is no option for most users) You are probably correct. However, unless everyone agrees to promote convention plugin out of the sandbox and solidify it in the next few days or so, it will have to be a separate release outside of the bundle. Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. Is it possible to release a 2.1.1 plugin after the core? In this case I do not feel like it is that important to make it part of the s2.1.1 release :) Until now I thought that the next possible release for the convention plugin would be 2.1.2 (or whatever build makes it). Not really if you want it in the bundle. Otherwise, it would be an external download until 2.1.2 or some version like that. I'm up for anything Thoughts? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Are there any special instructions or is it a simple 'mvn
release:prepare release:perform'?
Don
On 2/18/08, Rainer Hermanns [EMAIL PROTECTED] wrote:
Don,
great work, thanks for your help...
I'm really busy during the week so that I can not release before
friday evening (GMT+2), 23rd. If this will still meet you timeline I can
do the release otherwise either you or Pat could roll the release.
If you need any help, I'm available via IM.
cheers,
Rainer
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Rainer Hermanns
aixcept
Mariahilfstrasse 9
52062 Aachen - Germany
w: http://aixcept.de/
t: +49-241-4012247
m: +49-170-3432912
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
On Feb 19, 2008 6:01 AM, Don Brown [EMAIL PROTECTED] wrote: Are there any special instructions or is it a simple 'mvn release:prepare release:perform'? Antonio linked to this earlier: http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I think you should release the convention plugin at all costs - but this is just a vote from an user. piero Am Montag, 18. Februar 2008 18:16:52 schrieb Brian Pontarelli: Don Brown wrote: I've cleared all but a couple issues out of Struts 2.1.1, so I think we are ready for a release. The only kinda blocking issue is the portlet tests failing, but that seems to have something to do with the setup, not our portlet code, so we could even punt that one. Any objections to rolling a release(*) in the next day or so? Shall we queue up the convention plugin addition and deprecation of the smarturls and code-behind plugins for next release than? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Oh, I know how to release Struts; I was referring to the XWork release. IIRC, this will be the first release with the Maven 2 build, so we'll see how it goes... Don On 2/20/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Feb 19, 2008 6:01 AM, Don Brown [EMAIL PROTECTED] wrote: Are there any special instructions or is it a simple 'mvn release:prepare release:perform'? Antonio linked to this earlier: http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Don Brown wrote: I've cleared all but a couple issues out of Struts 2.1.1, so I think we are ready for a release. The only kinda blocking issue is the portlet tests failing, but that seems to have something to do with the setup, not our portlet code, so we could even punt that one. Any objections to rolling a release(*) in the next day or so? Shall we queue up the convention plugin addition and deprecation of the smarturls and code-behind plugins for next release than? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [s2] Let's get out Struts 2.1.1
Please do:) Don Brown wrote: I've cleared all but a couple issues out of Struts 2.1.1, so I think we are ready for a release. The only kinda blocking issue is the portlet tests failing, but that seems to have something to do with the setup, not our portlet code, so we could even punt that one. Any objections to rolling a release(*) in the next day or so? Shall we queue up the convention plugin addition and deprecation of the smarturls and code-behind plugins for next release than? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _
Re: [s2] Let's get out Struts 2.1.1
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
There was a complaint
(https://issues.apache.org/struts/browse/WW-2101) that some classes in
the portlet integration was removed without notice in a previous
release. Should probably get that into the release notes this time, or
add the classes back as no-op classes with a deprecation notice.
Nils-H
On Feb 17, 2008 12:16 PM, Don Brown [EMAIL PROTECTED] wrote:
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Don,
great work, thanks for your help...
I'm really busy during the week so that I can not release before
friday evening (GMT+2), 23rd. If this will still meet you timeline I can
do the release otherwise either you or Pat could roll the release.
If you need any help, I'm available via IM.
cheers,
Rainer
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Rainer Hermanns
aixcept
Mariahilfstrasse 9
52062 Aachen - Germany
w: http://aixcept.de/
t: +49-241-4012247
m: +49-170-3432912
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I can help out with this one too .. any time this week. Let me know
what you need.
Thanks
On Feb 17, 2008 11:11 AM, Rainer Hermanns [EMAIL PROTECTED] wrote:
Don,
great work, thanks for your help...
I'm really busy during the week so that I can not release before
friday evening (GMT+2), 23rd. If this will still meet you timeline I can
do the release otherwise either you or Pat could roll the release.
If you need any help, I'm available via IM.
cheers,
Rainer
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Rainer Hermanns
aixcept
Mariahilfstrasse 9
52062 Aachen - Germany
w: http://aixcept.de/
t: +49-241-4012247
m: +49-170-3432912
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
James Mitchell
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Let's get out Struts 2.1.1
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I still want to fix WW-2441, it's minor and I doubt anyone would even
notice it, but still, it makes us look bad if the interactive demo is
broken. I'm gonna fix it right now, so it shouldn't be a problem.
-Wes
On Sun, 2008-02-17 at 01:19 +1100, Don Brown wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I haven't logged this yet, but is anyone else noticing that package level
properties files are not being found right now? My whole project stopped
finding anything that was not in my global resources file. I haven't gotten
a chance to dig around in JIRA or in the app yet.
On Sat, Feb 16, 2008 at 9:29 AM, Wes Wannemacher [EMAIL PROTECTED] wrote:
I still want to fix WW-2441, it's minor and I doubt anyone would even
notice it, but still, it makes us look bad if the interactive demo is
broken. I'm gonna fix it right now, so it shouldn't be a problem.
-Wes
On Sun, 2008-02-17 at 01:19 +1100, Don Brown wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
2008/2/16, Don Brown [EMAIL PROTECTED]: Any objections to rolling a release(*) in the next day or so? To release, see the new *easier* instructions to roll out a release: http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution Obviously I am open to all questions about the Maven release and RAT plugins. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
On Feb 16, 2008 7:19 AM, Don Brown [EMAIL PROTECTED] wrote: I've cleared all but a couple issues out of Struts 2.1.1, so I think we are ready for a release. The only kinda blocking issue is the portlet tests failing, but that seems to have something to do with the setup, not our portlet code, so we could even punt that one. Any objections to rolling a release(*) in the next day or so? Good timing, I just started getting back into this last night. :) We'll need to release struts-annotations 1.0.3 to get rid of the snapshot dependency in struts2-core. And we need to remove (or comment out) all of the repositories in the struts2-parent pom. Otherwise anyone who depends on s2 will get all those repositories added to their build. They shouldn't be necessary this close to a release, everything we depend on should be in central. I'll try commenting them out and building. Thanks for the instructions on using the Maven release plugin, Antonio! (Don, it's the same thing you used to stage the archetypes at ApacheCon.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Nevermind on this one. Classpath issue. Guess I should have looked first
:)
On Sat, Feb 16, 2008 at 9:57 AM, Blake Byrnes [EMAIL PROTECTED] wrote:
I haven't logged this yet, but is anyone else noticing that package level
properties files are not being found right now? My whole project stopped
finding anything that was not in my global resources file. I haven't gotten
a chance to dig around in JIRA or in the app yet.
On Sat, Feb 16, 2008 at 9:29 AM, Wes Wannemacher [EMAIL PROTECTED] wrote:
I still want to fix WW-2441, it's minor and I doubt anyone would even
notice it, but still, it makes us look bad if the interactive demo is
broken. I'm gonna fix it right now, so it shouldn't be a problem.
-Wes
On Sun, 2008-02-17 at 01:19 +1100, Don Brown wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
I would like to fix the failing portlet test. I hope to get some time
tonight or tomorrow to look more into it.
Nils-H
On Feb 16, 2008 3:19 PM, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
On Feb 16, 2008 8:32 AM, Wendy Smoak [EMAIL PROTECTED] wrote: And we need to remove (or comment out) all of the repositories in the struts2-parent pom. Otherwise anyone who depends on s2 will get all those repositories added to their build. They shouldn't be necessary this close to a release, everything we depend on should be in central. I'll try commenting them out and building. OK, it builds without those repositories assuming you have built struts-annotations and xwork locally. Struts 2 core and the Dojo plugin [1] have the specific snapshot dependency on struts-annotations, which needs to be changed to 1.0.3. [1] (I misspoke a moment ago and said it was Portlet) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
It's probably a good idea to try the build after moving or removing your .m2 dir to fully ensure a clean set of publicly available dependencies. I'll do this right now to make sure...stay tuned. On Feb 16, 2008 11:59 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Feb 16, 2008 8:32 AM, Wendy Smoak [EMAIL PROTECTED] wrote: And we need to remove (or comment out) all of the repositories in the struts2-parent pom. Otherwise anyone who depends on s2 will get all those repositories added to their build. They shouldn't be necessary this close to a release, everything we depend on should be in central. I'll try commenting them out and building. OK, it builds without those repositories assuming you have built struts-annotations and xwork locally. Struts 2 core and the Dojo plugin [1] have the specific snapshot dependency on struts-annotations, which needs to be changed to 1.0.3. [1] (I misspoke a moment ago and said it was Portlet) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
On Feb 16, 2008 10:19 AM, James Mitchell [EMAIL PROTECTED] wrote: It's probably a good idea to try the build after moving or removing your .m2 dir to fully ensure a clean set of publicly available dependencies. I'll do this right now to make sure...stay tuned. That's what I did, except that I prefer to leave ~/.m2/repository alone and use -Dmaven.repo.local=/path/to/temp/repo As mentioned, I had to build struts-annotations and xwork locally, but other than that, everything was available *without* the repos we currently have listed in the struts2-parent pom. So I think they can be removed/commented out now. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Right, I don't trust Maven enough to rely solely on the maven.repo.local switch, but that's another discussion ;) I am getting a build failure right now. Is anyone else seeing this? Failed tests: testAnnotatedMethodFailure(com.opensymphony.xwork2.validator.ValidatorAnnotationTest) setUp(com.opensymphony.xwork2.validator.StringValidatorTest) setUp(com.opensymphony.xwork2.validator.LongRangeValidatorTest) testPackageInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testBadInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testDefaultPackage(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testBasicPackages(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testGlobalResultInheritenceTest(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderGlobalResultInheritenceTest) testInvalidFileThrowsException(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInvalidFileTest) testNeedsReload(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderTest) testInheritence(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderTest) testModelFieldErrorsAddedWithoutFieldPrefix(com.opensymphony.xwork2.validator.VisitorFieldValidatorModelTest) testModelFieldErrorsAddedWithoutFieldPrefixForInterface(com.opensymphony.xwork2.validator.VisitorFieldValidatorModelTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testResultTypes(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testResultInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testParseValidators(com.opensymphony.xwork2.validator.DefaultValidatorFactoryTest) testInterceptorsLoadedFromSpringApplicationContext(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsSpringTest) testMultipleConfigProviders(com.opensymphony.xwork2.config.ConfigurationTest) testInheritedResultTypesParams(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultTypesTest) testPlainResultTypesParams(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultTypesTest) testMultiLevelInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderMultilevelTest) tearDown(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptorTest) testIncludesAndExcludesMethodWithExcludeWildcard(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptorTest) setUp(com.opensymphony.xwork2.validator.IntRangeValidatorTest) setUp(com.opensymphony.xwork2.validator.DoubleRangeValidatorTest) testInvalidActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderActionsTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderActionsTest) setUp(com.opensymphony.xwork2.LocaleAwareTest) setUp(com.opensymphony.xwork2.TestNGXWorkTestCaseTest$RunTest) testFindNamedResource(com.opensymphony.xwork2.util.ResolverUtilTest) testSimpleTest(com.opensymphony.xwork2.TestNGXWorkTestCaseTest) testPrefixMethodInvocation1(com.opensymphony.xwork2.interceptor.ValidationInterceptorPrefixMethodInvocationTest) testPrefixMethodInvocation2(com.opensymphony.xwork2.interceptor.ValidationInterceptorPrefixMethodInvocationTest) setUp(com.opensymphony.xwork2.validator.ExpressionValidatorTest) testContextIsOverriddenByContextParamInValidationXML(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testBeanMessagesUseBeanResourceBundle(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testArrayValidation(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testCollectionValidation(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testContextIsPropagated(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testModelDrivenValidation(com.opensymphony.xwork2.validator.ModelDrivenValidationTest) testInterceptorParamOverriding(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testInterceptorInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testBasicInterceptors(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testWildCardInclude(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderWildCardIncludeTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderExceptionMappingsTest) setUp(com.opensymphony.xwork2.validator.AnnotationActionValidatorManagerTest) setUp(com.opensymphony.xwork2.interceptor.ParametersInterceptorTest) testValidateDoXXXThowsException(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor2Test) testValidateXXXThrowsException(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor2Test)
Re: [s2] Let's get out Struts 2.1.1
Actually, wait a sec. I keep forgetting that i can't 'clean install' with xwork in the profiles mvn clean install -Pxwork,all -- fails Each one runs fine separately. So nevermind. On Feb 16, 2008 2:19 PM, James Mitchell [EMAIL PROTECTED] wrote: Right, I don't trust Maven enough to rely solely on the maven.repo.local switch, but that's another discussion ;) I am getting a build failure right now. Is anyone else seeing this? Failed tests: testAnnotatedMethodFailure(com.opensymphony.xwork2.validator.ValidatorAnnotationTest) setUp(com.opensymphony.xwork2.validator.StringValidatorTest) setUp(com.opensymphony.xwork2.validator.LongRangeValidatorTest) testPackageInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testBadInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testDefaultPackage(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testBasicPackages(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderPackagesTest) testGlobalResultInheritenceTest(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderGlobalResultInheritenceTest) testInvalidFileThrowsException(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInvalidFileTest) testNeedsReload(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderTest) testInheritence(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderTest) testModelFieldErrorsAddedWithoutFieldPrefix(com.opensymphony.xwork2.validator.VisitorFieldValidatorModelTest) testModelFieldErrorsAddedWithoutFieldPrefixForInterface(com.opensymphony.xwork2.validator.VisitorFieldValidatorModelTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testResultTypes(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testResultInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultsTest) testParseValidators(com.opensymphony.xwork2.validator.DefaultValidatorFactoryTest) testInterceptorsLoadedFromSpringApplicationContext(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsSpringTest) testMultipleConfigProviders(com.opensymphony.xwork2.config.ConfigurationTest) testInheritedResultTypesParams(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultTypesTest) testPlainResultTypesParams(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderResultTypesTest) testMultiLevelInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderMultilevelTest) tearDown(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptorTest) testIncludesAndExcludesMethodWithExcludeWildcard(com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptorTest) setUp(com.opensymphony.xwork2.validator.IntRangeValidatorTest) setUp(com.opensymphony.xwork2.validator.DoubleRangeValidatorTest) testInvalidActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderActionsTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderActionsTest) setUp(com.opensymphony.xwork2.LocaleAwareTest) setUp(com.opensymphony.xwork2.TestNGXWorkTestCaseTest$RunTest) testFindNamedResource(com.opensymphony.xwork2.util.ResolverUtilTest) testSimpleTest(com.opensymphony.xwork2.TestNGXWorkTestCaseTest) testPrefixMethodInvocation1(com.opensymphony.xwork2.interceptor.ValidationInterceptorPrefixMethodInvocationTest) testPrefixMethodInvocation2(com.opensymphony.xwork2.interceptor.ValidationInterceptorPrefixMethodInvocationTest) setUp(com.opensymphony.xwork2.validator.ExpressionValidatorTest) testContextIsOverriddenByContextParamInValidationXML(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testBeanMessagesUseBeanResourceBundle(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testArrayValidation(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testCollectionValidation(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testContextIsPropagated(com.opensymphony.xwork2.validator.VisitorFieldValidatorTest) testModelDrivenValidation(com.opensymphony.xwork2.validator.ModelDrivenValidationTest) testInterceptorParamOverriding(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testInterceptorInheritance(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testBasicInterceptors(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderInterceptorsTest) testWildCardInclude(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderWildCardIncludeTest) testActions(com.opensymphony.xwork2.config.providers.XmlConfigurationProviderExceptionMappingsTest)
