Re: [POLL] Drop strutsel package from 1.4?
I started this poll because it is, to Wendy's point, double work to maintain the tag libraries. For every change, I have to update two source files -- either two Java or two TLD. Because people have noticed in the past when the two libraries are not in sync, I was looking for a way to "move forward" but not kill anyone in the water. Just looking for a good answer Would a better compromise be to move them into a dormant subproject (like apps)? I'd also like to do this with the "faces" module too, since Craig was the only committer and dropped support years ago. I am more than willing to continue releasing them as such, but do want to relegate them to second-class projects. Paul On Fri, Jun 6, 2008 at 11:20 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 8:31 AM, Niall Pemberton > <[EMAIL PROTECTED]> wrote: > > > I guess I'm just wondering what harm does it do leaving it in the > > release and the benefit is that it allows people with legacy apps > > dependant on it to upgrade with no pain. > > It seems to require double work to maintain both taglibs. As long as > someone is willing to do that work, it can stay... > > Honestly, how many apps do you think will upgrade to 1.4? I bet most > of them are still back on 1.1/1.2, and aren't going anywhere. :) > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [POLL] Drop strutsel package from 1.4?
If other committers haven't chimed in (or want to chime in again :-) ) please do. I think I will be making these changes eventually: * Move "el" project to "dormant" subfolder * Move "faces" project to "dormant" subfolder * Add a profile that builds them specifically * Up to the future whether the profile is included in the release build. Paul On Fri, Jun 6, 2008 at 12:25 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: > I started this poll because it is, to Wendy's point, double work to > maintain the tag libraries. For every change, I have to update two source > files -- either two Java or two TLD. Because people have noticed in the past > when the two libraries are not in sync, I was looking for a way to "move > forward" but not kill anyone in the water. Just looking for a good > answer > > Would a better compromise be to move them into a dormant subproject (like > apps)? I'd also like to do this with the "faces" module too, since Craig was > the only committer and dropped support years ago. I am more than willing to > continue releasing them as such, but do want to relegate them to > second-class projects. > > Paul > > > > On Fri, Jun 6, 2008 at 11:20 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > >> On Fri, Jun 6, 2008 at 8:31 AM, Niall Pemberton >> <[EMAIL PROTECTED]> wrote: >> >> > I guess I'm just wondering what harm does it do leaving it in the >> > release and the benefit is that it allows people with legacy apps >> > dependant on it to upgrade with no pain. >> >> It seems to require double work to maintain both taglibs. As long as >> someone is willing to do that work, it can stay... >> >> Honestly, how many apps do you think will upgrade to 1.4? I bet most >> of them are still back on 1.1/1.2, and aren't going anywhere. :) >> >> -- >> Wendy >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
Re: [POLL] Drop strutsel package from 1.4?
Martin, If we physically move them out of the struts1 folder (archive is sibling to struts1), then they can no longer be part of the build process if desired. I wasn't expecting to cut the life-cord that far! :-) but you desire differently? Paul On Sat, Jun 7, 2008 at 11:43 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > As has already been pointed out, we already have a location for dormant > projects. It's called "archive". I am opposed (-1, if you must) on having > two locations for inactive sub-projects. > > -- > Martin Cooper > > > On Sat, Jun 7, 2008 at 9:26 PM, Paul Benedict <[EMAIL PROTECTED]> > wrote: > > > If other committers haven't chimed in (or want to chime in again :-) ) > > please do. I think I will be making these changes eventually: > > > > * Move "el" project to "dormant" subfolder > > * Move "faces" project to "dormant" subfolder > > * Add a profile that builds them specifically > > * Up to the future whether the profile is included in the release build. > > > > Paul > > > > On Fri, Jun 6, 2008 at 12:25 PM, Paul Benedict <[EMAIL PROTECTED]> > > wrote: > > > > > I started this poll because it is, to Wendy's point, double work to > > > maintain the tag libraries. For every change, I have to update two > source > > > files -- either two Java or two TLD. Because people have noticed in the > > past > > > when the two libraries are not in sync, I was looking for a way to > "move > > > forward" but not kill anyone in the water. Just looking for a good > > > answer > > > > > > Would a better compromise be to move them into a dormant subproject > (like > > > apps)? I'd also like to do this with the "faces" module too, since > Craig > > was > > > the only committer and dropped support years ago. I am more than > willing > > to > > > continue releasing them as such, but do want to relegate them to > > > second-class projects. > > > > > > Paul > > > > > > > > > > > > On Fri, Jun 6, 2008 at 11:20 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > > >> On Fri, Jun 6, 2008 at 8:31 AM, Niall Pemberton > > >> <[EMAIL PROTECTED]> wrote: > > >> > > >> > I guess I'm just wondering what harm does it do leaving it in the > > >> > release and the benefit is that it allows people with legacy apps > > >> > dependant on it to upgrade with no pain. > > >> > > >> It seems to require double work to maintain both taglibs. As long as > > >> someone is willing to do that work, it can stay... > > >> > > >> Honestly, how many apps do you think will upgrade to 1.4? I bet most > > >> of them are still back on 1.1/1.2, and aren't going anywhere. :) > > >> > > >> -- > > >> Wendy > > >> > > >> - > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > >
Re: [POLL] Drop strutsel package from 1.4?
Martin, would you find it acceptable to leave them where they are and just relegate them to an optional build profile? That probably makes most sense; if we still want them buildable (I think we do), then they really aren't "inactive". Paul On Sun, Jun 8, 2008 at 12:01 AM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Sat, Jun 7, 2008 at 9:53 PM, Paul Benedict <[EMAIL PROTECTED]> > wrote: > > > Martin, > > > > If we physically move them out of the struts1 folder (archive is sibling > to > > struts1), then they can no longer be part of the build process if > desired. > > I > > wasn't expecting to cut the life-cord that far! :-) but you desire > > differently? > > > As far as I'm concerned, it can stay where it is or it can move to archive. > I don't have a strong opinion one way or the other. What I object to is > multiple flavours of "inactive" within a single project. > > -- > Martin Cooper > > > > Paul > > > > On Sat, Jun 7, 2008 at 11:43 PM, Martin Cooper <[EMAIL PROTECTED]> > wrote: > > > > > As has already been pointed out, we already have a location for dormant > > > projects. It's called "archive". I am opposed (-1, if you must) on > having > > > two locations for inactive sub-projects. > > > > > > -- > > > Martin Cooper > > > > > > > > > On Sat, Jun 7, 2008 at 9:26 PM, Paul Benedict <[EMAIL PROTECTED]> > > > wrote: > > > > > > > If other committers haven't chimed in (or want to chime in again :-) > ) > > > > please do. I think I will be making these changes eventually: > > > > > > > > * Move "el" project to "dormant" subfolder > > > > * Move "faces" project to "dormant" subfolder > > > > * Add a profile that builds them specifically > > > > * Up to the future whether the profile is included in the release > > build. > > > > > > > > Paul > > > > > > > > On Fri, Jun 6, 2008 at 12:25 PM, Paul Benedict <[EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > I started this poll because it is, to Wendy's point, double work to > > > > > maintain the tag libraries. For every change, I have to update two > > > source > > > > > files -- either two Java or two TLD. Because people have noticed in > > the > > > > past > > > > > when the two libraries are not in sync, I was looking for a way to > > > "move > > > > > forward" but not kill anyone in the water. Just looking for a good > > > > > answer > > > > > > > > > > Would a better compromise be to move them into a dormant subproject > > > (like > > > > > apps)? I'd also like to do this with the "faces" module too, since > > > Craig > > > > was > > > > > the only committer and dropped support years ago. I am more than > > > willing > > > > to > > > > > continue releasing them as such, but do want to relegate them to > > > > > second-class projects. > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > On Fri, Jun 6, 2008 at 11:20 AM, Wendy Smoak <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > >> On Fri, Jun 6, 2008 at 8:31 AM, Niall Pemberton > > > > >> <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >> > I guess I'm just wondering what harm does it do leaving it in > the > > > > >> > release and the benefit is that it allows people with legacy > apps > > > > >> > dependant on it to upgrade with no pain. > > > > >> > > > > >> It seems to require double work to maintain both taglibs. As long > > as > > > > >> someone is willing to do that work, it can stay... > > > > >> > > > > >> Honestly, how many apps do you think will upgrade to 1.4? I bet > > most > > > > >> of them are still back on 1.1/1.2, and aren't going anywhere. :) > > > > >> > > > > >> -- > > > > >> Wendy > > > > >> > > > > >> > > - > > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > >> > > > > >> > > > > > > > > > > > > > > >
CodeBehind and index action?
Does the CodeBehind plugin allow me to specify a default action for a directory? So that way I can just do /dir instead of /dir/index.action? I want the directory to load up /index.jsp which is backed by /index.action Paul
Re: CodeBehind and index action?
Anyway to accomplish this in 2.0? Have you ever did it? Just looking for a quick answer, even if that includes adding action mappings to the config. Paul On Sat, Jul 12, 2008 at 8:13 AM, Don Brown <[EMAIL PROTECTED]> wrote: > No, I don't believe it does. Conventions plugin does, I believe. > > Don > > On Sat, Jul 12, 2008 at 11:03 PM, Paul Benedict <[EMAIL PROTECTED]> > wrote: > > Does the CodeBehind plugin allow me to specify a default action for a > > directory? So that way I can just do /dir instead of /dir/index.action? I > > want the directory to load up /index.jsp which is backed by /index.action > > > > Paul > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Struts 2.0.11.2: Missing Announcement?
I combed the archives but could not find any announcement. I know Rene said he would send one after the vote, but I don't think he did. Can someone else check up on this? Paul
Re: Struts 2.0.11.2: Missing Announcement?
Rene, thanks for the info! I was just following up out of curiosity. The response is exactly what I needed, and I agree an announcement should go out to clarify the state of things. We should probably update the home page (too) with similar info since it seems important to know that about the last release. Paul On Sat, Jul 12, 2008 at 3:24 PM, Rene Gielen <[EMAIL PROTECTED]> wrote: > Paul, > > as responses to the vote thread there are some further informations and > discussions regarding the announcement [1]. Since we found out that > 2.0.11.2 breaks WebSphere 6 compatibility due to a missing patch in > XWork 2.0.5, the plan was to release a fixed XWork 2.0.6 with that patch > and go on with an announcement that references XW 2.0.6 as additional > needed resource for WS users, while 2.0.11.2 in general fixes the > security issue. For integration in a stable struts release, the plan is > to push out a 2.0.12 with some more awaited patches applied. > > State now is that Rainer was in big time troubles with his day job and > is now on a one week vacancy, so that we will not get out a XW 2.0.6 > release until next week. Also there seem to be further issues with > XW-641, which makes it even more complicated. > > The announcement is sleeping in my draft mail folder for over a week > now, and since we will not get out XW 2.0.6 as soon as we thought, we > might want to push the announcement now including a clarification about > the actual (unresolved) state for WebSphere users, and I would do so in > a few hours if nobody disagrees. > > I'm sorry for the troubles, I hope we manage to get this fixed asap. > > - Rene > > [1] > > http://www.nabble.com/-VOTE--Struts-2.0.11.2-Quality-%28fast-track%29-tp18063952p18335180.html > > Paul Benedict schrieb: > > I combed the archives but could not find any announcement. I know Rene > said > > he would send one after the vote, but I don't think he did. Can someone > else > > check up on this? > > > > Paul > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Convention plugin: why not deployed to repo with 2.1.2?
Does anyone know why the convention plugin is not deployed to the repo for 2.1.2? PS: I wish the plugins had a namespace like the Maven plugins (i.e., org.apache.maven.plugins -> org.apache.struts.plugins) Paul
Re: Convention plugin: why not deployed to repo with 2.1.2?
I wasn't aware it was a sandbox plugin when I wrote the email. I later found that out through SVN exploring, but I was mislead by the online documentation. I wish the S2 wiki noted it was a sandbox plugin. Paul On Sat, Jul 19, 2008 at 11:51 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On Sat, Jul 19, 2008 at 9:35 PM, Musachy Barroso <[EMAIL PROTECTED]> > wrote: > > > Do we deploy things from the sandbox to the repo? > > That was my thought... isn't this a sandbox plugin? > > > http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-convention-plugin/ > > I would not expect to see it in the central repo until it gets voted > out of the sandbox and included in an official release. > > That said, Struts1 used to include sandboxed things in the > distribution in (iirc) a 'contrib' directory. The Maven repo doesn't > really have a way to designate that, though. > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[PROPOSAL] S2: Subclassing plugins
When I want to extend a plugin, I unfortunately have to unpack the libraries and include them into my own web application. I use Maven's Dependency plugin for this. :-) It is the only way I know of getting a hold of the binaries without forcing them into plugin status. I see two ways out of this: 1) Refactor each plugin to be the code and a plugin jar wrapper. 2) S2 needs a way of saying which plugin NOT to load. Obviously the plugin jar is going to be in WEB-INF/lib. That's good enough to extend, if I have a way to stop it from registering. I wholly prefer #2. Other options welcomed. Paul
Re: [PROPOSAL] S2: Subclassing plugins
Since plugins are a collection of classes and they are available to me on the class path, I should be able to subclass any of them -- and replace them. Imagine I like the functionality of one and want to add a bit more? Why can't plugins have protected methods that I customize? I don't want to redo all its work, but I do want to "replace" classes with my subclass. Paul On Sun, Jul 20, 2008 at 8:33 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > I don't see plugins as something that you extend, but more like > something that you customize. If there is something that you need to > modify on a plugin, then that should probably be an extension point in > the plugin. Take for example the case of Codebehind and REST, with > some small modifications Codebehind was modified so it could be > "customized" by REST without having to extend it. I know this doesn't > cover all the possible use cases. > > musachy > > On Sun, Jul 20, 2008 at 8:45 PM, Paul Benedict <[EMAIL PROTECTED]> > wrote: > > When I want to extend a plugin, I unfortunately have to unpack the > libraries > > and include them into my own web application. I use Maven's Dependency > > plugin for this. :-) It is the only way I know of getting a hold of the > > binaries without forcing them into plugin status. > > > > I see two ways out of this: > > 1) Refactor each plugin to be the code and a plugin jar wrapper. > > 2) S2 needs a way of saying which plugin NOT to load. Obviously the > plugin > > jar is going to be in WEB-INF/lib. That's good enough to extend, if I > have a > > way to stop it from registering. > > > > I wholly prefer #2. Other options welcomed. > > > > Paul > > > > > > -- > "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: [PROPOSAL] S2: Subclassing plugins
It comes down to the embedding of the struts.xml in the plugins. Certain values get set which cannot be unset. For instance, if one plugin sets the UnknownActionHandler, no one else can override it. (I don't want the conversation to focus on UAH improvements but it is one good example). I imagine there are other properties which developers woulds like to replace too. What can we make Struts do to make this easier? Paul On Mon, Jul 21, 2008 at 7:47 AM, Ian Roughley <[EMAIL PROTECTED]> wrote: > I'm a little surprised that you can't do this now. Is the problem because > of the order of loading the plugins during bootstrapping or the way the > authors write the plugins, or something else? > > /Ian > > > Paul Benedict wrote: > >> Since plugins are a collection of classes and they are available to me on >> the class path, I should be able to subclass any of them -- and replace >> them. >> >> Imagine I like the functionality of one and want to add a bit more? Why >> can't plugins have protected methods that I customize? I don't want to >> redo >> all its work, but I do want to "replace" classes with my subclass. >> >> Paul >> >> On Sun, Jul 20, 2008 at 8:33 PM, Musachy Barroso <[EMAIL PROTECTED]> >> wrote: >> >> >> >>> I don't see plugins as something that you extend, but more like >>> something that you customize. If there is something that you need to >>> modify on a plugin, then that should probably be an extension point in >>> the plugin. Take for example the case of Codebehind and REST, with >>> some small modifications Codebehind was modified so it could be >>> "customized" by REST without having to extend it. I know this doesn't >>> cover all the possible use cases. >>> >>> musachy >>> >>> On Sun, Jul 20, 2008 at 8:45 PM, Paul Benedict <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>>> When I want to extend a plugin, I unfortunately have to unpack the >>>> >>>> >>> libraries >>> >>> >>>> and include them into my own web application. I use Maven's Dependency >>>> plugin for this. :-) It is the only way I know of getting a hold of the >>>> binaries without forcing them into plugin status. >>>> >>>> I see two ways out of this: >>>> 1) Refactor each plugin to be the code and a plugin jar wrapper. >>>> 2) S2 needs a way of saying which plugin NOT to load. Obviously the >>>> >>>> >>> plugin >>> >>> >>>> jar is going to be in WEB-INF/lib. That's good enough to extend, if I >>>> >>>> >>> have a >>> >>> >>>> way to stop it from registering. >>>> >>>> I wholly prefer #2. Other options welcomed. >>>> >>>> Paul >>>> >>>> >>>> >>> >>> -- >>> "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] >>> >>> >>> >>> >> >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Isn't Dojo the defacto ajax standard on the web? I know there is no such "certification" :-) but why deprecate something so popular? If anything, I would spin off the project into Codehaus and let the world continue writing it. Paul On Tue, Jul 22, 2008 at 10:18 AM, Dave Newton <[EMAIL PROTECTED]> wrote: > --- On Tue, 7/22/08, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > I think Dave also had a JQuery plugin somewhere, isn't that right? > > I can neither confirm nor deny the existence of said project. > > I started to convert the Dojo tags to jQuery and stopped again pretty > quickly; I only had with a single target. > > I started w/ the Dojo tag code, as I had wanted to make them as compatible > as practical w/ the Dojo tags. My project then did everything via raw jQuery > anyway, so they got put on hold. > > To answer somebody else's question, I gathered JavaScript in a couple of > different ways across projects, including keeping it in a ThreadLocal String > then spitting it out with a tag or appending it via an interceptor (not sure > that was HTML-compliant though). > > I agree that having things like and an Ajax submit would be pretty > nice--make the easy stuff drop-dead simple. Anything beyond that I'm less > sure, and tying S2 itself to a particular client-side framework always > worried me a bit. > > Dave > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Deprecate or remove Dojo plugin
What does anyone think about donating the dojo plugin to codehaus? I think it's a better idea than letting the code go stale. You could even try donating to the dojotoolkit project. Paul On Tue, Jul 22, 2008 at 6:18 PM, Ted Husted <[EMAIL PROTECTED]> wrote: > +1 for Musachy's suggestion, and I'm also at a point where I could > help with the implementation. > > As to Ajax-enabling some of the tags, there are several tag-based Ajax > libraries out there that we could look at embedding or emulating. In > this case, we wouldn't be adopting a general-purpose Ajax library, but > special-purpose scripts designed to be used with tags. > > * Ajax Tags - http://ajaxtags.sourceforge.net > * Prize Tags - http://jenkov.com/prizetags/index.html > * JSON-taglib - http://json-taglib.sourceforge.net/ > * AjaxParts Taglib - http://javawebparts.sourceforge.net/ > > Has anyone had good or bad experiences with tag-based libraries like these? > > -Ted. > > > On Mon, Jul 21, 2008 at 11:33 PM, Musachy Barroso <[EMAIL PROTECTED]> > wrote: > > I am not sure about that approach. On one hand it is very "strutsish", > > in that is supports many ways of doing the same thing, and provides > > ways to extend what is provided, on the other hand, I think we should > > learn from other frameworks and just don't give users that many > > options, for they can be confusing, and frustrating when there is not > > enough documentation. > > > > Looking at ajax, and the ajax tags I think we have 2 kind of users: > > the power users, they won't use the ajax tag at all, unless they are > > doing something extremely simple. the beginners: they will use the > > ajax tags out of the box. When the beginners need to do something that > > is not provided by the tags out of the box, they start hacking away, > > and end up dumping the tags. So our target is the beginners, and they > > don't want customization, they just want to drop a few tags on their > > jsps and get it working. Based on that, I think we should either: > > don't provide any ajax tags at all, or just provide a very limited set > > of tags (like what Jeromy listed) with very little functionality to > > cover simple use cases, and use a reliable and simple framework for > > the implementation. > > > > Disregarding what path we take, I think it is fairly obvious that the > > Dojo plugin will end up unmaintained, that's why we should users know > > that we do not plan on upgrading from 0.4.3. > > > > musachy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Dojo 0.4.3 is old :-) I didn't know that. No one wants to move it to 1.x or wherever they are now? Paul On Tue, Jul 22, 2008 at 10:29 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > As you could probably guess, I've had a lot of success with AjaxParts > Taglib ;) I've also had a lot of success with Dojo, ExtJS, ActiveWidgets, > dHTMLx and my personal favorite, DWR (I've found that DWR, plus > best-of-breed widgets is all the "framework" I need, which is why I haven't > posted here much lately, I haven't touched Struts in over a year myself). > (As to Dojo's popularity... well, it's definitely not a "de facto" > anything, that's for sure. May be some day, but not yet. Like Ted, I find > that as much as Dojo gets talked about, I don't hear from as many people > using it as the "press", so to speak, would suggest. It certainly *is* > popular, no question about that, but it seems like other libraries, most > notably jQuery, have kind of eclipsed it as the "place to be" in terms of > client-side libraries.) > > Not to toot my own horn or anything... but, what the heck :) ... speaking > as someone who pioneered the whole "AJAX via taglib" approach (if it wasn't > first, it was definitely *one of* the first, but for those that maybe > haven't been around Struts as long as others, AjaxParts Taglib, or APT, was > originally an enhanced version of the S1 HTML taglib that I created in early > 2005)... I have a strong opinion that it's a good approach for many users. > > Having a simple taglib-based approach to do some of the more common AJAX-y > things, maybe some widgets here and there too, means that Java developers > can leverage their existing skills without having to take the plunge into > heavy client-side development, which I can say from the experience of > mentoring some junior-level teams can be a very difficult hill to climb, > regardless of what whiz-bang library you choose to use to try and make it > easier. The very nature of Javascript, for many Java developers, is a > difficult leap to make. > > If the question is should the plugin be deprecated *without a replacement > ready day one*, my opinion is that's a bad idea. Whether the current plugin > is the right answer or not, I think it's better than nothing. Especially > for those developers who aren't ready to make the leap to heavy client-side > coding as many of us have done, a taglib-based approach is a godsend. I > know this because while APT may not have the largest user community around, > we have a very happy community, based on the feedback we get. Clearly the > tag-based approach is something many developers very much want and like, and > it's something that I think is a pretty attractive feature of S2. Losing > it, even temporarily, would hurt I think, if in no other way than > perception. > > Even if there's no one ready, willing and able to do the work to address > the shortcomings of the plugin, I don't think that's a reason to deprecate > it. It may be fair to update some documentation to say something along the > lines of "use at your own risk", whatever text reflects the true state of > it, but beyond that I think it would be a step backwards for Struts, if in > no other way than perception, to lose this capability, even if only briefly. > > Frank > > P.S. - Ted, I see you're doing your TAE presentation again this year... > I'll be attending again as well (although my proposal didn't get picked up, > maybe next year), hope we can hook up at some point. Anyone else going to > be in town? > > -- > Frank W. Zammetti > Author of "Practical DWR 2 Projects" > and "Practical JavaScript, DOM Scripting and Ajax Projects" > and "Practical Ajax Projects With Java Technology" > for info: apress.com/book/search?searchterm=zammetti&act=search > Java Web Parts - javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > My "look ma, I have a blog too!" blog: zammetti.com/blog > > > > Ted Husted wrote: > >> +1 for Musachy's suggestion, and I'm also at a point where I could >> help with the implementation. >> >> As to Ajax-enabling some of the tags, there are several tag-based Ajax >> libraries out there that we could look at embedding or emulating. In >> this case, we wouldn't be adopting a general-purpose Ajax library, but >> special-purpose scripts designed to be used with tags. >> >> * Ajax Tags - http://ajaxtags.sourceforge.net >> * Prize Tags - http://jenkov.com/prizetags/index.html >> * JSON-taglib - http://json-taglib.sourceforge.net/ >> * AjaxParts Taglib - http://javawebparts.sourceforge.net/ >> >> Has anyone had good or bad experiences with tag-based libraries like >> these? >> >> -Ted. >> >> >> On Mon, Jul 21, 2008 at 11:33 PM, Musachy Barroso <[EMAIL PROTECTED]> >> wrote: >> >> >>> I am not sure about that approach. On one hand it is very "strutsish", >>> in that is supports many ways of doing the same thing, and provides >>> ways to extend what is provided, on the other hand, I think w
Re: [PROPOSAL] Deprecate or remove Dojo plugin
If this is the case, I would not recommend we create an "ajax" plugin, but call it the "ajax-yui" plugin or a "ajax-whatever" plugin so that people can use different ajax implementations. Paul On Wed, Jul 23, 2008 at 1:40 AM, Jeromy Evans < [EMAIL PROTECTED]> wrote: > Paul Benedict wrote: > >> Dojo 0.4.3 is old :-) I didn't know that. No one wants to move it to 1.x >> or >> wherever they are now? >> >> Paul >> >> > > Many have tried. In general, the effort doesn't justify the result. > ie. you put a lot of effort writing new templates and tags that > predominately wrap and constrain dojo's own markup. This result is tags for > widgets less capable than using dojo markup directly. The benefit is a user > can use instead of , but if > they use the latter they can receive all the support of the dojo user > community. > > It's difficult to justify the effort for a sub-optimal solution that's > going to generate more support questions: > eg. how to I select a tab a button press, how to i change colour of tabs, > why can't i nest tabs, why won't the back button remember the content of the > last tab, etc, etc, etc, > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Request Confluence account
I may already have an account, but I can't remember if it was created. If so, I can't remember what username I have too. Sorry for the trouble, but I'd like to request permissions to edit S2 documentation. PS: http://struts.apache.org/2.0.11.2/docs/strutsproperties.html I need to know who takes precedence. If I specify a property in XML and then a different value in the properties file, who wins? Paul
Action not found: missing error code?
I believe S2 should be invoking setErrorCode when it triggers the 404 code. Filters that are on ERROR dispatcher won't run otherwise. Any thoughts? Paul
Re: Struts 1.3.8 problem html:form
Alex, Your question is perfectly fine, but you subscribed to the wrong mailing list. The Developers mailing list is for developing the Struts framework itself. The Users mailing list are for those who use the Struts framework in development. There's a big difference :-) Just post to the write list. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven invoker plugin: how is it useful?
I work in a team that heavily writes unit and integration tests. Typically, our unit tests end in *Test and our integration tests end in *ITest (*HibernateITest, *MailITest, etc.). We put integration tests into a profile so they run only when requested. So I've been reading the Invoker documentation and it claims it is useful. Why is it useful? I don't understand what the purpose of creating separate projects for integration testing. I understand how that's useful for Maven's own integration testing (gotta test project configs), but how for the rest of Java developers? Can someone expound upon it? Is it just a preference? Is there an actual purpose? Thanks, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven invoker plugin: how is it useful?
Totally. This is my error. :-) I sent it to the wrong list thanks to the virtues of auto-complete. On Tue, Aug 5, 2008 at 9:12 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > Wouldn't you be better off asking the Maven folks, rather than the Struts > Dev community? > > -- > Martin Cooper > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
I am -1 on having Struts 2 be a JSR. Anything that gets pulled into JEE gets pulled into molasses and I wouldn't want Sun to stick their hands into this framework. With that said, I wouldn't mind a JSR that creates an JEE Action Framework that Struts 2 is an implementation of. Remember the great success Hibernate had with leading the JPA spec? How about Joda Time leading JSR-310 Date and Time API? Replicate the procedures that lead to success. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Struts 2 Starter Maven Archetype v2.0.11.2
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.12 Quality
+1 GA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop J4 support, was: Re: release process
Since Struts 2.1 does not have a GA release yet, I think it's
acceptable to drop J4 support too. However, make it as easy as
possible to build the J4 support libraries with documentation, and a
*supported* Maven profile.
Paul
On Sun, Nov 16, 2008 at 3:44 PM, Rene Gielen <[EMAIL PROTECTED]> wrote:
> +1 for dropping in 2.1, along with keeping it in 2.0.X
>
> Rainer Hermanns schrieb:
>>
>> I'd vote with +1 for dropping j4-support in Struts 2.1.X
>> but with -1 for Struts 2.0.X because of known users using
>> previous 2.0.X backported releases and that are waiting for
>> another stable GA release for their production systems.
>>
>> just my 0.02€,
>> cheers,
>> Rainer
>>
>>> Yes, my thoughts were on that direction, drop out direct support and
>>> document what needs to be done, for those that still need it.
>>>
>>> musachy
>>>
>>> On Sun, Nov 16, 2008 at 12:35 PM, Dave Newton <[EMAIL PROTECTED]>
>>> wrote:
>>>
--- On Sun, 11/16/08, Musachy Barroso wrote:
>
> I know someone already asked this but, shouldn't we drop
> the jdk4 support already?
+1, but I'll add a wiki page giving a brief overview of the retro
process
("Run this batch file, loser!")
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>> --
>>> "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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Struts 1.4: New Dispatcher package
I am happy to announce that I moved a little closer at integrating Struts 1 and 2 seamlessly. As always, my goal is to mesh them within one context without losing any S1 functionality. One issue of Struts 1.x is that dispatching is supported exclusively within the Action. Many designers note it as a flaw -- that an Action would execute the dispatching logic itself -- and I see some truth to this. A better solution is to make the Controller handle this responsibility outright. Thus, a new "dispatcher" attribute has been added to the action mapping. The Controller can now delegate to the configured Dispatcher which will in turn invoke the Action. What's neat about the Dispatcher interface is that it takes an ActionContext and returns an Object. The input can be for a servlet (ServletActionContext), a portlet, or any other kind of medium. The output can also be anything. So the classic execute() signature doesn't have to be so anymore as long as the Controller can interpret the response. Four kinds of responses are handled out of the box: * ActionForward (as before) to forward * null (as before) to handle the response directly * String, to represent a forward name * void, to represent calling the SUCCESS result I see two potentials. (1) Possibly any kind of dynamic method signature and (2) S1 mapping can delegate to S2 actions and vice-versa. There's some more javadoc to do, but please take a look in SVN in the meantime. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.9 GA ?
I hope to be cutting 1.3.10 this weekend for a vote. Paul On Wed, Nov 26, 2008 at 1:57 AM, Anthony PERRIN <[EMAIL PROTECTED]> wrote: > When Struts 1.3.9 will be release as GA ? > > Just for saying that we are using Struts 1.3.9 in production (many war with > differents architecture) since July 2007 and all works fine. > > > - > 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: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
Yes. I could put a note in JIRA about it, but 5.5.27 would not download successfully. I tried many times. I could only get 5.5.26 to work with cargo. Any tips? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
Maven couldn't download Tomcat. As I said, I tried several times with 5.5.27, and each time it aborted with a problem with the Zip file. The error message said "Unexpected end of ZLIB input stream" Paul On Sat, Nov 29, 2008 at 4:14 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 9:52 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: > >> Yes. I could put a note in JIRA about it, but 5.5.27 would not >> download successfully. I tried many times. I could only get 5.5.26 to >> work with cargo. Any tips? > > > Can you elaborate on "would not download"? Do you mean you couldn't download > Tomcat, Maven couldn't download Tomcat, Tomcat couldn't download something? > > -- > Martin Cooper > > > >> Paul >> >> - >> 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: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
No, no mirrors being used. This is straight of ibiblio. Paul On Sat, Nov 29, 2008 at 6:15 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Sat, Nov 29, 2008 at 3:27 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: > >> Maven couldn't download Tomcat. As I said, I tried several times with >> 5.5.27, and each time it aborted with a problem with the Zip file. The >> error message said "Unexpected end of ZLIB input stream" > > > I don't suppose you happen to be using a Maven proxy, do you? (That is, you > have a entry in your settings.xml file referencing a Maven proxy > server.) The reason I ask is that I literally just ran into a problem with > Archiva handing Maven a corrupted jar even though the original jar is fine. > I know it's a slim chance that you are hitting the same issue, but if you > are, and you have admin access to Archiva, then you can upload the artifact > manually to get around this. > > -- > Martin Cooper > > > >> Paul >> >> On Sat, Nov 29, 2008 at 4:14 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: >> > On Fri, Nov 28, 2008 at 9:52 PM, Paul Benedict <[EMAIL PROTECTED]> >> wrote: >> > >> >> Yes. I could put a note in JIRA about it, but 5.5.27 would not >> >> download successfully. I tried many times. I could only get 5.5.26 to >> >> work with cargo. Any tips? >> > >> > >> > Can you elaborate on "would not download"? Do you mean you couldn't >> download >> > Tomcat, Maven couldn't download Tomcat, Tomcat couldn't download >> something? >> > >> > -- >> > Martin Cooper >> > >> > >> > >> >> Paul >> >> >> >> - >> >> 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]
[VOTE] Struts 1.3.10 Quality
The Struts 1.3.10 test build is now available. Release notes: * http://struts.apache.org/1.x/userGuide/release-notes.html Distribution: * http://people.apache.org/builds/struts/1.3.10/ Maven 2 staging repository: * http://people.apache.org/builds/struts/1.3.10/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as "Beta", the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
See if it is running forever because the unzip failed. You should be able to see the JUnit output even when it is running forever in the target/surefire-reports directory. I did get the same problem you had once, but just once. Paul On Sun, Nov 30, 2008 at 2:20 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Sat, Nov 29, 2008 at 10:55 PM, Paul Benedict <[EMAIL PROTECTED]>wrote: > >> No, no mirrors being used. This is straight of ibiblio. > > > Hmm. It's not Maven doing the download, it's our code (Tomcat5xTestSetup) > downloading it directly. I tried downloading from the same URL manually, and > both 5.5.26 and 5.5.27 have working zip files, so I don't know why 5.5.27 > would not work for you. I tried running the tests myself, but they never > actually get far enough for me to find out. (I get "Running > org.apache.struts.apps.AppsTest", and then it just sits there forever.) > > -- > Martin Cooper > > > >> Paul >> >> On Sat, Nov 29, 2008 at 6:15 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: >> > On Sat, Nov 29, 2008 at 3:27 PM, Paul Benedict <[EMAIL PROTECTED]> >> wrote: >> > >> >> Maven couldn't download Tomcat. As I said, I tried several times with >> >> 5.5.27, and each time it aborted with a problem with the Zip file. The >> >> error message said "Unexpected end of ZLIB input stream" >> > >> > >> > I don't suppose you happen to be using a Maven proxy, do you? (That is, >> you >> > have a entry in your settings.xml file referencing a Maven >> proxy >> > server.) The reason I ask is that I literally just ran into a problem >> with >> > Archiva handing Maven a corrupted jar even though the original jar is >> fine. >> > I know it's a slim chance that you are hitting the same issue, but if you >> > are, and you have admin access to Archiva, then you can upload the >> artifact >> > manually to get around this. >> > >> > -- >> > Martin Cooper >> > >> > >> > >> >> Paul >> >> >> >> On Sat, Nov 29, 2008 at 4:14 PM, Martin Cooper <[EMAIL PROTECTED]> >> wrote: >> >> > On Fri, Nov 28, 2008 at 9:52 PM, Paul Benedict <[EMAIL PROTECTED]> >> >> wrote: >> >> > >> >> >> Yes. I could put a note in JIRA about it, but 5.5.27 would not >> >> >> download successfully. I tried many times. I could only get 5.5.26 to >> >> >> work with cargo. Any tips? >> >> > >> >> > >> >> > Can you elaborate on "would not download"? Do you mean you couldn't >> >> download >> >> > Tomcat, Maven couldn't download Tomcat, Tomcat couldn't download >> >> something? >> >> > >> >> > -- >> >> > Martin Cooper >> >> > >> >> > >> >> > >> >> >> Paul >> >> >> >> >> >> - >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
It looks like you are trying 1.4. Did you mean to test that, or 1.3.10? On Sun, Nov 30, 2008 at 4:26 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Sun, Nov 30, 2008 at 1:31 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: > >> See if it is running forever because the unzip failed. You should be >> able to see the JUnit output even when it is running forever in the >> target/surefire-reports directory. I did get the same problem you had >> once, but just once. > > > OK, I've made some progress. Some things I've found out: > > 1) The repeated failures to unzip that you saw are because the old download > is not cleaned up. If the download is interrupted, the partial file is left > around as if it was the complete download, and subsequent passes through > that download code skip the download and try to unzip the incomplete file. > It seems that you have to go and clean out the cargo install directory > manually to get past this. Once I did this, I got past the download issue > with *both* 5.5.26 and 5.5.27. FYI, on my machine, the cargo installs > directory that needs to be cleaned out is: > > C:\Documents and Settings\martinc\Local Settings\Temp\cargo\installs > > 2) I believe I got into the corrupted zip file mess by interrupting (Ctrl-C) > the process while it was downloading Tomcat. For whatever reason, the > download was extremely slow the first time I tried it, and I suspect I just > gave up too soon, leaving a partial zip file, which was then the cause of > the subsequent problems. > > 3) Somewhere along the line, some Java process or another would not let go > of the surefire output files, so that I could not delete them even after I > thought I had got rid of all processes that could be accessing them. I found > some other Java process in Task Manager and had to kill that manually before > it would let go of the output files. I don't know what's up with that. > > 4) After getting past all of the above, I am seeing 9 test failures, which > is basically a 404 for each of the application entry points. I'll paste one > example below, but all 9 errors are the same except for the actual context. > > testStrutsBlank(org.apache.struts.apps.AppsTest) Time elapsed: 0.781 sec > <<< ERROR! > com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 404 Not Found > for http://localhost:8080/struts-blank-1.4.0-SNAPSHOT/ >at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:347) >at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:384) >at org.apache.struts.apps.AppsTest.testStrutsBlank(AppsTest.java:71) > > For each of these tests, there is also an INFO message, but I don't know if > this is important or not: > > INFO: Redirect requested but followRedirects is disabled > > -- > Martin Cooper > > > >> Paul >> >> On Sun, Nov 30, 2008 at 2:20 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: >> > On Sat, Nov 29, 2008 at 10:55 PM, Paul Benedict <[EMAIL PROTECTED] >> >wrote: >> > >> >> No, no mirrors being used. This is straight of ibiblio. >> > >> > >> > Hmm. It's not Maven doing the download, it's our code (Tomcat5xTestSetup) >> > downloading it directly. I tried downloading from the same URL manually, >> and >> > both 5.5.26 and 5.5.27 have working zip files, so I don't know why 5.5.27 >> > would not work for you. I tried running the tests myself, but they never >> > actually get far enough for me to find out. (I get "Running >> > org.apache.struts.apps.AppsTest", and then it just sits there forever.) >> > >> > -- >> > Martin Cooper >> > >> > >> > >> >> Paul >> >> >> >> On Sat, Nov 29, 2008 at 6:15 PM, Martin Cooper <[EMAIL PROTECTED]> >> wrote: >> >> > On Sat, Nov 29, 2008 at 3:27 PM, Paul Benedict <[EMAIL PROTECTED]> >> >> wrote: >> >> > >> >> >> Maven couldn't download Tomcat. As I said, I tried several times with >> >> >> 5.5.27, and each time it aborted with a problem with the Zip file. >> The >> >> >> error message said "Unexpected end of ZLIB input stream" >> >> > >> >> > >> >> > I don't suppose you happen to be using a Maven proxy, do you? (That >> is, >> >> you >> >> > have a entry in your settings.xml file referencing a Maven >> >> proxy >> >> > server.) The reason I ask is that I literally just ran into a problem >> >> with >
Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apa
> With respect to which tree I'm working with, I'm working with whatever > 'current' includes. If 'current' is not what we are _currently_ releasing > from, then you may be correct that I am trying 1.4. But that begs the > question of why we are perpetuating releases on the 1.3 branch when we > already have work in progress on 1.4, especially when 1.3.8 was GA. Isn't it > time to move on? > Since 1.4 is a very long work in progress, I don't think it benefits our community by withholding important bug fixes. I use both 1.4 and 1.3 on separate projects, and the soon-to-be-voted 1.3.10 contains some important fixes. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.9 GA ?
1.3.10 is up for a vote. On Fri, Nov 28, 2008 at 6:03 AM, Anthony PERRIN <[EMAIL PROTECTED]> wrote: > Excellent !!! > Considering the fact that promote 1.3.10 (or 1.3.9) as GA is very important > (obviously if 1.3.10 is ok) because 1.3.8 contains severals major bug > (https://issues.apache.org/struts/browse/STR-3015) that will lead to a > 1.3.8a version. In fact the last good version (1.3.9) is in beta > > If you want that devlopers use struts 2 it's very important to prove that > the older version of struts (and other developement in general) will be (a > little) maintain. > > I would like to congratulate for all of the struts works and all of the > Apache Software Fondation works ! > > Anthony. > > - > 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: WebSphere problems
Wes, also try WebSphere community edition which is free. On Sun, Nov 30, 2008 at 10:10 PM, Wes Wannemacher <[EMAIL PROTECTED]> wrote: > Since there seem to be problems from time to time with WebSphere, is > there a problem with me contacting IBM and asking for a copy to use for > testing? I would imagine they know of Struts and will value the > importance of their app server working with our framework. If there is a > problem with me contacting them on behalf of Apache, should I contact > them as an individual interested in supporting Struts? I have a server > where I could install it and make struts2-blank/showcase available on > teh intarwebs for integration testing on wantii.com. > > -Wes > > > - > 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: WebSphere problems
What problems are you experiencing? I work with WS everyday of my professional life -- pity me. Paul On Sun, Nov 30, 2008 at 10:22 PM, Wes Wannemacher <[EMAIL PROTECTED]> wrote: > I've used WebSphere CE, and it just uses Tomcat and Jetty under the > hood, so I'm guessing the problems won't present in CE. I can try > tomorrow if I get some time. > > -Wes > > On Sun, 2008-11-30 at 22:13 -0600, Paul Benedict wrote: >> Wes, also try WebSphere community edition which is free. >> >> On Sun, Nov 30, 2008 at 10:10 PM, Wes Wannemacher <[EMAIL PROTECTED]> wrote: >> > Since there seem to be problems from time to time with WebSphere, is >> > there a problem with me contacting IBM and asking for a copy to use for >> > testing? I would imagine they know of Struts and will value the >> > importance of their app server working with our framework. If there is a >> > problem with me contacting them on behalf of Apache, should I contact >> > them as an individual interested in supporting Struts? I have a server >> > where I could install it and make struts2-blank/showcase available on >> > teh intarwebs for integration testing on wantii.com. >> > >> > -Wes >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.3.10 Quality
[X] General Availability (GA). Ditto. On Mon, Dec 1, 2008 at 7:23 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > [X] General Availability (GA) > > Niall > > On Sun, Nov 30, 2008 at 9:26 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: >> The Struts 1.3.10 test build is now available. >> >> Release notes: >> >> * http://struts.apache.org/1.x/userGuide/release-notes.html >> >> Distribution: >> >> * http://people.apache.org/builds/struts/1.3.10/ >> >> Maven 2 staging repository: >> >> * http://people.apache.org/builds/struts/1.3.10/m2-staging-repository/ >> >> Once you have had a chance to review the test build, please respond >> with a vote on its quality: >> >> [ ] Leave at test build >> [ ] Alpha >> [ ] Beta >> [ ] General Availability (GA) >> >> Everyone who has tested the build is invited to vote. Votes by PMC >> members are considered binding. A vote passes if there are at least >> three binding +1s and more +1s than -1s. >> >> The vote will remain open for at least 72 hours, longer upon request. >> A vote can be amended at any time to upgrade or downgrade the >> quality of the release based on future experience. If an initial vote >> designates the build as "Beta", the release will be submitted for >> mirroring and announced to the user list. Once released as a public >> beta, subsequent quality votes on a build may be held on the user list. >> >> As always, the act of voting carries certain obligations. A binding >> vote not only states an opinion, but means that the voter is agreeing >> to help do the work >> >> -Paul >> >> - >> 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: WebSphere problems
Please ask IBM about getting a WAS copy. See if they would donate it to Apache so perhaps all of the foundation can use it. I bet Henri Yandell would set it up if we obtained a license. Paul On Tue, Dec 2, 2008 at 3:27 PM, Rene Gielen <[EMAIL PROTECTED]> wrote: > Yeah, WS CE is basically a relabeled Geronimo, sharing some techologies with > WS. Actually, if it runs on CE, this gives no clue whether it will run on > "real" WebSphere... > > Wes Wannemacher schrieb: >> >> I've used WebSphere CE, and it just uses Tomcat and Jetty under the >> hood, so I'm guessing the problems won't present in CE. I can try >> tomorrow if I get some time. >> -Wes >> >> On Sun, 2008-11-30 at 22:13 -0600, Paul Benedict wrote: >>> >>> Wes, also try WebSphere community edition which is free. >>> >>> On Sun, Nov 30, 2008 at 10:10 PM, Wes Wannemacher <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> Since there seem to be problems from time to time with WebSphere, is >>>> there a problem with me contacting IBM and asking for a copy to use for >>>> testing? I would imagine they know of Struts and will value the >>>> importance of their app server working with our framework. If there is a >>>> problem with me contacting them on behalf of Apache, should I contact >>>> them as an individual interested in supporting Struts? I have a server >>>> where I could install it and make struts2-blank/showcase available on >>>> teh intarwebs for integration testing on wantii.com. >>>> >>>> -Wes >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE RESULT] Struts 1.3.10 Quality
Binding votes: 4 +1 GA Niall Pemberton Paul Benedict James Holmes Nils-Helge Garli Hegvik Struts 1.3.10 has been voted GA. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cleaning up the Jira Unscheduled queue
James, remember you can batch up without sending emails. Paul On Fri, Dec 5, 2008 at 9:04 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > thanks James, Struts 2 Jira needs some serious love at the moment. > > musachy > > On Fri, Dec 5, 2008 at 9:51 AM, James Holmes <[EMAIL PROTECTED]> wrote: >> Just wanted to give a heads up that I'm going through and trying to update >> the Jire tickets in the Unscheduled queue. If I make and update to a ticket >> that you don't agree with, feel free to change. >> >> James >> > > > > -- > "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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cleaning up the Jira Unscheduled queue
If you do a search, you can then choose "Batch Update". It's a wizard flow. One of the options at the bottom of page 2 or 3 deals with sending email. If you uncheck it, you can do your work silently. Maybe good if you have hundreds of updates. Paul On Sat, Dec 6, 2008 at 4:39 PM, Dave Newton <[EMAIL PROTECTED]> wrote: > --- On Sat, 12/6/08, James Holmes wrote: >> Plus I actually like getting the emails and I think having them come >> to the dev list has prodded some folks to help clear the tickets out. > > I prefer the individual emails, FWIW. > > Dave > > > - > 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: svn commit: r724125 - /struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml
Why not make this a Maven profile? On Sun, Dec 7, 2008 at 6:25 AM, <[EMAIL PROTECTED]> wrote: > Author: rgielen > Date: Sun Dec 7 04:25:16 2008 > New Revision: 724125 > > URL: http://svn.apache.org/viewvc?rev=724125&view=rev > Log: > Disabled JDK backports for now to fix CI builds. To enable again, we need a > XWork jar backport released / distributed for Maven dependency resolution > > Modified: >struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml > > Modified: struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml > URL: > http://svn.apache.org/viewvc/struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml?rev=724125&r1=724124&r2=724125&view=diff > == > --- struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml (original) > +++ struts/struts2/branches/STRUTS_2_0_X/assembly/pom.xml Sun Dec 7 04:25:16 > 2008 > @@ -123,7 +123,9 @@ > > src/main/assembly/all.xml > src/main/assembly/lib.xml > + > src/main/assembly/apps.xml > src/main/assembly/src.xml > src/main/assembly/docs.xml > @@ -433,6 +435,7 @@ > > > > + > > > org.apache.struts > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.10 broken link
This should be fixed now. On Wed, Dec 10, 2008 at 5:56 PM, Niall Pemberton wrote: > On Wed, Dec 10, 2008 at 5:19 PM, Dave Newton wrote: >> 1) On http://struts.apache.org/1.x/ the leftnav link to "releases" is >> http://struts.apache.org/1.x/downloads.html, which is broken. >> >> 2) On http://struts.apache.org/1.3.10/index.html the leftnav link to release >> is http://struts.apache.org/1.3.10/downloads.html, which is broken. >> >> 3) The link on the struts home page to S1's GA is >> http://struts.apache.org/1.3.10/index.html... >> >> (Oooo, there's a pattern here...) >> >> It's actually not very clear where to get S1, IMO. > > The S1 site.xml has the following link which is correct: > > http://struts.apache.org/downloads.html > > The problem is maven being smart :-( and turning links relative: > > http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links > > Niall > >> Dave >> >> --- On Wed, 12/10/08, Martin Cooper wrote: >>> On Tue, Dec 9, 2008 at 11:57 PM, Anthony PERRIN < >>> anthony.per...@ac-nancy-metz.fr> wrote: >>> >>> > hello >>> > Concerning struts 1.x there is a broken link on the >>> web site : >>> > http://struts.apache.org/1.3.10/downloads.html >>> >>> >>> Where did you find that link? On what page? >>> >>> -- >>> Martin Cooper >>> >>> >>> >>> > Congratulations for ours works. >>> > >>> > >>> - >>> > To unsubscribe, e-mail: >>> dev-unsubscr...@struts.apache.org >>> > For additional commands, e-mail: >>> dev-h...@struts.apache.org >>> > >>> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Fwd: Struts 1.3.10 GA Release
Is the announcement list moderated? Can someone push through last week's announcement? -- Forwarded message -- From: Paul Benedict Date: Tue, Dec 9, 2008 at 9:54 PM Subject: Struts 1.3.10 GA Release To: annou...@apachenews.org The Apache Struts team is pleased to announce that Struts 1.3.10 has been promoted to General Availability. Struts 1.3.10 is available in a full distribution, or as separate library, source, example and documentation distributions. http://struts.apache.org/download.cgi#struts1310 The release is also available through the central Maven repository under Group ID "org.apache.struts". -- The Apache Struts group. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] java tags proposal
Can you please provide a link and a distribution for me to look at? On Sat, Dec 20, 2008 at 2:57 PM, Rainer Hermanns wrote: > +1 > cheers, > Rainer > >> yes ;) >> >> On Sat, Dec 20, 2008 at 1:46 PM, Martin Cooper wrote: >>> Is this intended to be a [VOTE] thread? >>> >>> -- >>> Martin Cooper >>> >>> >>> On Sat, Dec 20, 2008 at 10:24 AM, Musachy Barroso >>> wrote: >>> As mentioned on the other thread I's like to propose to move the java tags out of the sandbox into the core plugins bundled with the distribution, so they will be part of the 2.1 release. here is +1 musachy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org >>> >> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > -- > Rainer Hermanns > aixcept > Willibrordstraße 82 > 52134 Herzogenrath - Germany > w: http://aixcept.de/ > t: +49 - 2406 - 979 22 11 > f: +49 - 2406 - 979 22 13 > m: +49 - 170 - 343 29 12 > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.1.3 Quality - Freemarker/Sitemesh plugin issue
I say call 2.1.3 a bust and move onto making 2.1.4 GA. I had to do 3 point releases from 1.3.5 to 1.3.8 to go GA. :-) Getting new features to work right universally is a tough job. Paul On Sat, Dec 27, 2008 at 11:04 AM, Musachy Barroso wrote: > You are not using the new filters, so I guess something is went wrong > in that refactoring. I will see if I cand find the problem, but the > release cannot go out like this. > > musachy > > On Sat, Dec 27, 2008 at 11:12 AM, Al Sutton wrote: >> I'm sorry I didn't try the trunk sooner (too busy coding the site :(). >> >> The filters are; >> >> >> struts-cleanup >> >> org.apache.struts2.dispatcher.ActionContextCleanUp >> >> >> sitemesh >> >> com.opensymphony.module.sitemesh.filter.PageFilter >> >> >> struts >> >> org.apache.struts2.dispatcher.FilterDispatcher >> >> actionPackages >> com.andappstore.actions >> >> >> >> struts-cleanup >> /* >> >> >> sitemesh >> /* >> >> >> struts >> /* >> >> The sitemesh.xml is; >> >> >> >> >> >> >> > class="com.opensymphony.module.sitemesh.parser.HTMLPageParser" /> >> > class="com.opensymphony.module.sitemesh.parser.HTMLPageParser" /> >> >> >> >> > class="com.opensymphony.module.sitemesh.mapper.AgentDecoratorMapper"> >> >> >> > class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper"> >> >> >> >> >> and the decorators.xml file is; >> >> >> >> /updates/* >> >> >> /* >> >> >> >> >> >> >> >> Musachy Barroso wrote: >>> >>> this one looks bad, how do you have your filters configured? I think >>> we saw this before and had been fixed. >>> >>> musachy >>> >>> On Sat, Dec 27, 2008 at 4:50 AM, Al Sutton wrote: >>> Next problem; I'm seeing an exception being thrown in Freemarker which I believe is a knock on effect from the sitemesh plugin. When I set a breakpoint in FreemarkerTemplateEngine.renderTemplate there are several passes through where the servletcontext, request, and response objects are pulled from the stack in the TemplateRenderingContext, but then nulls start to be returned and hence the NPE is thrown. I beleive this is when parsing a decorator containing S2 tags is included because the output page contains the main data, the HTML components from the template, and then stops at the first S2 tag :( . Al. java.lang.NullPointerException at org.apache.struts2.views.freemarker.FreemarkerManager.getConfiguration(FreemarkerManager.java:159) at org.apache.struts2.components.template.FreemarkerTemplateEngine.renderTemplate(FreemarkerTemplateEngine.java:89) at org.apache.struts2.components.UIBean.mergeTemplate(UIBean.java:559) at org.apache.struts2.components.UIBean.end(UIBean.java:513) at org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:42) at org.apache.jsp.WEB_002dINF.decorators.default_jsp._jspx_meth_s_005fhidden_005f0(default_jsp.java:668) at org.apache.jsp.WEB_002dINF.decorators.default_jsp._jspService(default_jsp.java:162) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at com.opensymphony.module.sitemesh.filter.PageFilter.writeDecorator(PageFilter.java:173) at com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java:158) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.struts2.dispatcher.ActionContextCleanUp.doFilter(ActionContextClea
Struts 1.4: New Dispatcher package, part II
Team, After successfully testing the new org.apache.struts.dispatcher package (by retrofitting a current application of mine), it is in great shape for anyone else to try. Here are some highlights: 1) New ExecuteDispatcher command for ComposableRequestProcessor that delegates to a Dispatcher instance and processes the return value. 2) Choice to assign a default Dispatcher (via chain config property) for any mapping that does not use the new @dispatcher config attribute. 3) New Dispatcher interface that forms a hierarchy of dispatching strategies. 4) New MethodResolver interface that defines the know-how of selecting the correct Method handle and building its arguments. If a developer were to use the servlet subpackage, these method signatures are supported out of the box: * [void|String|ActionForward] execute() * [void|String|ActionForward] execute(ActionContext) * [void|String|ActionForward] execute(ServletActionContext) * [void|String|ActionForward] execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) Writing your own MethodResolver will allow different return types and method signatures. I bet some clever Ajax developer could take advantage of this kind of support. Anyway, based on an eye-ball guestimate, I think about 30% of my Struts code has now shrunk due to cleaner method signatures and corresponding javadoc method comments. That was one of my big goals: conciseness. PS: Is this architecture useful for Struts 2? Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.1.3 Quality - Freemarker/Sitemesh plugin issue
Musachy, Please officially cancel the previous vote... or if you have 72 hours and the vote count, let us know. Paul On Mon, Dec 29, 2008 at 9:37 PM, Wes Wannemacher wrote: > Is this a vote thread? Or are we waiting on something in particular > before we vote on 2.1.4? > > -Wes > > On Mon, 2008-12-29 at 16:05 -0500, Musachy Barroso wrote: >> Grab it while it is hot: http://people.apache.org/builds/struts/2.1.4/ >> >> musachy >> >> On Mon, Dec 29, 2008 at 11:56 AM, Al Sutton wrote: >> > I've not had a chance to run any tests yet (the nightlies directory seems >> > to >> > only hold the core jar and the AndAppStore app uses several plugins, and >> > I've not dug around on how to find access the builder server). >> > >> > If you roll a 2.1.4 I'll drop the jars into the app and happily give it >> > another spin. >> > >> > Al. >> > >> > Musachy Barroso wrote: >> >> >> >> Are we good to cut 2.1.4? >> >> >> >> musachy >> >> >> >> On Sun, Dec 28, 2008 at 1:34 PM, Nils-Helge Garli Hegvik >> >> wrote: >> >> >> >>> >> >>> You can also get the individual project artifacts from the build >> >>> server for each successful build. >> >>> >> >>> Nils-H >> >>> >> >>> On Sun, Dec 28, 2008 at 7:14 PM, Wes Wannemacher wrote: >> >>> >> >> There is something here - >> >> http://people.apache.org/builds/struts/nightlies/2.x/ >> >> I'm not sure who/how it's generated, and it is only core, so it's a >> place to start at least. >> >> If there is any docs or pointers someone can forward I'll take a look >> and try to get the nightlies going again. >> >> -Wes >> >> On Sun, 2008-12-28 at 11:58 -0500, Musachy Barroso wrote: >> >> > >> > I don't think we have those. Do we? >> > >> > musachy >> > >> > On Sun, Dec 28, 2008 at 3:44 AM, Al Sutton >> > wrote: >> > >> >> >> >> I've changed machines recently and haven't got a S2 dev environment >> >> set up. >> >> Can I get a nightly build from somewhere? >> >> >> >> Al. >> >> >> >> Musachy Barroso wrote: >> >> >> >>> >> >>> 3 hours debugging, and the fix was one line of code :). Please test >> >>> against trunk and let me know, it all seems to work for me. >> >>> >> >>> musachy >> >>> >> >>> On Sat, Dec 27, 2008 at 12:40 PM, Musachy Barroso >> >>> wrote: >> >>> >> >>> >> >> yes, that's a good idea, in fact there are some tags there, like >> "url", wich do not fail. >> >> On Sat, Dec 27, 2008 at 12:36 PM, Wes Wannemacher >> wrote: >> >> >> > >> > I'll follow suit and rescind my vote as well... Should we add a tag >> > showcase's decorator so that it pops up when we test in the future? >> > >> > -Wes >> > >> > On Sat, 2008-12-27 at 12:31 -0500, Musachy Barroso wrote: >> > >> > >> >> >> >> never mind, just adding: >> >> >> >> >> >> >> >> to the main decorator makes fail, I will downgrade my vote. >> >> musachy >> >> >> >> On Sat, Dec 27, 2008 at 12:23 PM, Musachy Barroso >> >> >> >> wrote: >> >> >> >> >> >>> >> >>> I change the filter and filter mappings to the "old" ones, and >> >>> showcase still works, do you know what I would need to change to >> >>> reproduce the problem? >> >>> >> >>> musachy >> >>> >> >>> On Sat, Dec 27, 2008 at 11:12 AM, Al Sutton >> >>> >> >>> wrote: >> >>> >> >>> >> >> I'm sorry I didn't try the trunk sooner (too busy coding the >> site >> :(). >> >> The filters are; >> >> >> struts-cleanup >> >> >> >> org.apache.struts2.dispatcher.ActionContextCleanUp >> >> >> sitemesh >> >> >> >> com.opensymphony.module.sitemesh.filter.PageFilter >> >> >> struts >> >> >> >> org.apache.struts2.dispatcher.FilterDispatcher >> >> actionPackages >> com.andappstore.actions >> >> >> >> struts-cleanup >> /* >> >> >> sitemesh >> /* >> >> >> struts >> /* >> >> The sitemesh.xml is; >> >> >> > value="/WEB-INF/decorators.xml" /> >> >> >
Re: No offense, Don & Co.
But... how is donating a product different than donating money to the Foundation? Apache advertises the names and logos of certain donors, and perhaps the software is worth enough to mention. http://www.apache.org/foundation/sponsorship.html Thoughts? Paul On Tue, Dec 30, 2008 at 8:31 PM, Musachy Barroso wrote: > For what I have read here a few times I think mentioning the company > from the website is a no-go. I am not sure if it is an Apache wide > rule(sponsors are listed in some places, but that's a different > thing), or just a struts specific thing. > > musachy > > On Tue, Dec 30, 2008 at 9:21 PM, Wes Wannemacher wrote: >> When I got my copy of IntelliJ IDEA, I also noticed that they do >> TeamCity licenses for OSS projects. I was thinking of using it on the >> machine I set aside for WebSphere, when that materializes. But, I had >> asked them about it before getting a hold of anyone at IBM and asked if >> they would do a hosted solution sort of like Bamboo. Their response was >> that they would - >> >> [quote] >> There is no problem obtaining an open-source TeamCity license for the >> Struts project, please contact Ilia if you need it. >> >> As to hosted solution: we do have several projects hosted on >> http://teamcity.jetbrains.com but it is a kind of "unofficial" >> possibility for now with no guarantees provided, etc. The option will >> only suit if your build runs on Windows or Linux, using JDK 1.4 or 1.5 >> with no special environment settings necessary. We also ask to mention >> the fact that Struts project uses TeamCity on your official web site. >> [/quote] >> >> Is this something we want to do? I don't know whether or not we can >> "advertise" JetBrains, so I haven't responded. If we don't want to do it >> this way, then we can wait and I'll get it running locally, but I >> wouldn't mind leeching their infrastructure. Nothing against Bamboo, but >> it doesn't seem to like Struts lately, and I think CI is a great thing, >> so I hate to just ignore the failed builds all the time. >> >> -Wes >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: missing volunteers
Maybe we shouldn't speak up... if you're not listed as a volunteer, perhaps you should be paid :-) Paul On Sat, Jan 3, 2009 at 4:33 PM, Martin Cooper wrote: > On Sat, Jan 3, 2009 at 2:26 PM, Musachy Barroso wrote: > >> It seems like some of us are missing from the volunteers page: >> http://struts.apache.org/volunteers.html, at least Wes, Jeromy and >> that other I. I checked svn and we are in the volunteers.xml file: >> >> >> http://svn.apache.org/viewvc/struts/site/src/site/xdoc/dev/volunteers.xml?view=markup >> >> It seems like something went wrong the last time that the site was >> updated. > > > Not sure when it was updated, but that page was correct just a couple of > days ago... > > >> Lighten up boys, maybe we are going to start getting paid ;) > > > I'd recommend not holding your breath. ;-) > > -- > Martin Cooper > > > >> >> musachy >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [Friday] Re: IBM is an island (the quest for getting a websphere license continues)
Is there any new information about getting a WebSphere instance? - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [Friday] Re: IBM is an island (the quest for getting a websphere license continues)
Martin, can you tell us who the discussion is going on with? On Tue, Feb 10, 2009 at 6:09 PM, Martin Cooper wrote: > On Sun, Feb 8, 2009 at 9:23 PM, Wes Wannemacher wrote: > >> On Sunday 08 February 2009 23:42:24 Paul Benedict wrote: >> > Is there any new information about getting a WebSphere instance? >> > >> >> I haven't heard from IBM in a week or two. I'll ping them again tomorrow >> morning. > > > There's a discussion going on right now. More news when there is news... > > -- > Martin Cooper > > > >> -- >> >> Wes Wannemacher >> Author - Struts 2 In Practice >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more >> http://www.manning.com/wannemacher >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Fwd: New repository for Maven snapshots
FYI. I wonder if we can take advantage of this. -- Forwarded message -- From: Brian E. Fox Date: Sat, Feb 21, 2009 at 7:10 PM Subject: New repository for Maven snapshots To: Maven Developers List , Maven Users List The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: OVal plugin
Don't forget Commons Validator 2 which is supposed to implement JSR-303 bean validation. PS: I think Struts 2 should have an API for pluggable validation systems. Why should one be preferred over another -- as a decision for us to make? Let the developer choose their implementation. Maybe XWork, maybe OVal, maybe Commons Validator, maybe Hibernate Bean Validation. It would be really neat to allow. Paul On Sun, Mar 29, 2009 at 8:48 PM, Musachy Barroso wrote: > That's a good point Wes. In fact I sent my first patch today and it > got applied already :). I almost have XML working and I will be adding > more tests in the next few days. When the plugin is ready we can bring > it in, and see how people like it, and how it performs in production. > > musachy > > On Sat, Mar 28, 2009 at 8:49 PM, Wes Wannemacher wrote: >> On Saturday 28 March 2009 20:42:32 Musachy Barroso wrote: >>> I wanted to get some discussion going on the possibility of using a >>> third party framework for validation, and deprecating XWork's one in >>> the future. If there is a good library, well documented and powerful, >>> which does all we need, I don't really see the point in maintaining >>> our own implementation. Thoughts? >>> >>> //look mom, I am tryin' to deprecate more code! >>> >>> musachy >>> >> >> Advantages - >> 1. Most likely less code for us to maintain >> 2. Oval implements the closest thing to a validation standard for beans in >> java that I know of >> 3. Possibly reducing the training curve of new developers adopting struts >> 4. Being abstracted to a plugin allows for future enhancement via dropping in >> other validation implementations >> >> Disadvantage - >> - We don't own Oval and will not have much say in its future. I would say >> that >> if using OGNL should have taught us anything is that if we want to use it as >> a >> dependency, we should volunteer on that side of things so that we can make >> sure it is maintained in the future (probably not a problem with Oval, but >> wouldn't hurt). >> >> Despite listing a disadvantage, I'm still +1 on this. I think users will >> likely welcome the added features of validation through Oval. >> >> -Wes >> >> >> >> -- >> >> Wes Wannemacher >> Author - Struts 2 In Practice >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more >> http://www.manning.com/wannemacher >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Is Struts 1.X an active project?
Yes, it is still an active project. It primarily gets minor bug fixes, but there is a 1.4 branch that is in development when time permits. Paul On Thu, Jun 25, 2009 at 10:28 PM, Balwinder Kumar wrote: > Dear Developers, > > Forgive my ignorance, I just wanted to know is Struts 1.X is still an active > project? > > Thanks & Regards, > Balwinder Kumar > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Just make XWork a subproject of Struts. Then everyone can be happy.
Re: Let's kill xwork (was Re: 2.1.8 release?)
If XWork can remain as an independent Maven project, that's good enough for me. I don't care if it gets built only when Struts gets built. I just hope we don't import Struts into XWork. So I am +1 with Musachy. Paul On Mon, Aug 10, 2009 at 2:30 PM, Musachy Barroso wrote: > On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper wrote: > > So, assuming the XWork-consuming developer is not using Maven (sorry, > Wendy, > > but that's still most of the world ;), are we planning on providing > separate > > download links on our web site for *pieces* of our releases, then? Or are > we > > going to tell people to download the entire Struts 2 release and then > throw > > most of it away? > > > > I don't think anyone is using XWork by itself except Wes. Wes had to > fix some stuff to make XWork work in stand alone mode, so if nobody > has complained about it before, it means very few (if any) users are > using it like this, so we should not get too worried about it. > > musachy > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Let's kill xwork (was Re: 2.1.8 release?)
To say it has no value outside of Struts, I believe, downplays its ability to be an independent framework / dependency injection container. I am not for binding it to Struts. I would vote for being it's own independent Maven module or vote for it to join Apache Commons. On Mon, Aug 10, 2009 at 7:30 PM, Musachy Barroso wrote: > On Mon, Aug 10, 2009 at 5:22 PM, Don Brown wrote: > > Well, it shouldn't be in the struts2-core jar, but it should be in the > > main Struts project as something like struts2-xwork.jar. There is > > little value trying to bring it in as a new subproject with its own > > release cycle > > That's what I meant. A subproject is a no-go for me, as it would be > the same thing that we have now. > > musachy > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Let's kill xwork (was Re: 2.1.8 release?)
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown wrote: > By forking XWork, we can a) bring core Struts 2 code into the project > where it belongs and b) still leave it available for other users in > OpenSymphony. > > If you fork XWork, it obviously won't be XWork anymore. If that's what you want to do to cut the apron strings, then I can agree to that. However, I thought you guys were saying you actually want to make Apache *OWN* XWork. That's something completely different and am against. If the code is copied into Struts as fork, the whole XWork branding should wash away and Struts should have no more reference to "xwork" anywhere. Paul
Re: Let's kill xwork (was Re: 2.1.8 release?)
I definitely agree that Struts 3 would be a good candidate to do this XWork migration. It is not an appropriate candidate for 2.1, or 2.2. However, if you like to do a 2.5 (I dislike superficial jumps in versions though), then it might be acceptable in the 2.x branch. Paul On Tue, Aug 11, 2009 at 9:37 PM, Musachy Barroso wrote: > On Tue, Aug 11, 2009 at 9:55 AM, Brian Pontarelli > wrote: > > Maybe its time to branch Struts core, drop in xwork, refactor the heck > out > > of it, and call it struts 3. Code name the release "Phoenix". :) > > >
Re: Let's kill xwork (was Re: 2.1.8 release?)
Are you sure it's not an incompatible change? I thought the discussion was the importing of XWork and getting rid of its branding. That means all of XWork's annotations and packages would be changed to org.apache.struts. I don't believe there is any desire to keep com.opensymphony when this occurs. So my thinking would be this would be an incompatible change. Did I get it wrong? On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak wrote: > On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict > wrote: > > I definitely agree that Struts 3 would be a good candidate to do this > XWork > > migration. It is not an appropriate candidate for 2.1, or 2.2. However, > if > > you like to do a 2.5 (I dislike superficial jumps in versions though), > then > > it might be acceptable in the 2.x branch. > > IMO "Struts 3" would imply a major change in Struts itself, the > possibility of backwards incompatible changes, etc. This isn't... > community aspects aside, it's just moving some code from one svn repo > to another. -Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Let's kill xwork (was Re: 2.1.8 release?)
I concur that it should be a module within Struts and thus carry the version number of the Struts release. On Thu, Aug 13, 2009 at 4:32 PM, Rene Gielen wrote: > Besides the wrong versioning (XW 2.1.5 vs. 2.1.8), that's a reasonable > plan. To clarify the possible S2.2 plan as I understand (and prefer) it, > it would be a struts2-xwork module within S2 build and release cycle, > providing an artifact on which struts2-core depends - could we get a > consensus on this? > > Dale Newfield schrieb: > > Is this an accurate summary? > > > > struts-2.1.8: still waiting on xwork-2.1.8 > > > > struts-2.2.x: assuming IP clearance process passes for xwork, fork it > > and have it still be a separate jar, but within the struts2 package. > > (Probably the only real change would be package names.) > > > > struts-3.x: merge struts2 and xwork. > > > > -Dale > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > -- > René Gielen > IT-Neering.net > Saarstrasse 100, 52062 Aachen, Germany > Tel: +49-(0)241-4010770 > Fax: +49-(0)241-4010771 > Cel: +49-(0)177-3194448 > http://twitter.com/rgielen > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Build requires JDK 1.6 now - EmbeddedJSP plugin
Isn't only the build requiring JDK 6? It's not that JDK 6 is required at run-time. If that's the case, I don't think this is a big deal. On Mon, Aug 24, 2009 at 1:07 AM, Al Sutton wrote: > My opinion is to go J6 with a J5 optional package. > > That way users can get as much as we can give them out of the box and if > they really must only use J5 they can still do so. > > We'll also have to make sure we don't use String.isEmpty :). > > Al. > > -- > > * Written an Android App? - List it at http://andappstore.com/ * > > == > Funky Android Limited is registered in England & Wales with the > company number 6741909. The registered head office is Kemp House, > 152-160 City Road, London, EC1V 2NX, UK. > > The views expressed in this email are those of the author and not > necessarily those of Funky Android Limited, it's associates, or it's > subsidiaries. > > -Original Message- > From: Wes Wannemacher [mailto:w...@wantii.com] > Sent: 24 August 2009 04:26 > To: Struts Developers List > Subject: Re: Build requires JDK 1.6 now - EmbeddedJSP plugin > > On Sunday 23 August 2009 09:48:55 pm Jeromy Evans wrote: > > Hi guys, > > > > I may have missed the announcement, but it seems Java 1.6 is now > > mandatory to perform a full build of Struts 2.1.8+ > > > > The EmbeddedJSP plugin's JSPLoader uses javax.tools.JavaCompiler that > > is "Since 1.6" only. > > > > If not deliberate, we may need a j5 profile in the build that excludes > > that module (is that even possible?) > > > > We could easily create a profile that doesn't include the embeddedjsp > plugin > (and any other new modules that may require java 6). The real question is > whether we want to continue targeting Java 5 and exclude the Java 6 stuff > by > default or vice versa? I'll go see if google can tell me about the lifespan > of > Java 5. > > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: Build requires JDK 1.6 now - EmbeddedJSP plugin
If JDK6 is required to run, then I think two things should be done: * A profile be created to build this plugin * The maven-enforcer-plugin should enforce the use of at least JDK 1.6 Paul On Mon, Aug 24, 2009 at 10:48 AM, Chris Pratt wrote: > Yes, for the EmbeddedJSP plugin, it would require Java6+, but the rest of > Struts 2 (everything we have today) would work fine with Java 5. So I > can't > really see a need for separate J5 and J6 releases. Noting that that single > plugin requires Java6 seems sufficient to me. > (*Chris*) > > On Mon, Aug 24, 2009 at 7:01 AM, Al Sutton wrote: > > > I guess that depends on whether; > > > > "The EmbeddedJSP plugin's JSPLoader uses javax.tools.JavaCompiler that is > > "Since 1.6" only" > > > > means used during the compile or used during runtime. > > > > Al. > > > > -- > > > > * Written an Android App? - List it at http://andappstore.com/ * > > > > == > > Funky Android Limited is registered in England & Wales with the > > company number 6741909. The registered head office is Kemp House, > > 152-160 City Road, London, EC1V 2NX, UK. > > > > The views expressed in this email are those of the author and not > > necessarily those of Funky Android Limited, it's associates, or it's > > subsidiaries. > > > > -Original Message- > > From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] > On > > Behalf Of Paul Benedict > > Sent: 24 August 2009 14:39 > > To: Struts Developers List > > Subject: Re: Build requires JDK 1.6 now - EmbeddedJSP plugin > > > > Isn't only the build requiring JDK 6? It's not that JDK 6 is required at > > run-time. If that's the case, I don't think this is a big deal. > > > > On Mon, Aug 24, 2009 at 1:07 AM, Al Sutton wrote: > > > > > My opinion is to go J6 with a J5 optional package. > > > > > > That way users can get as much as we can give them out of the box and > if > > > they really must only use J5 they can still do so. > > > > > > We'll also have to make sure we don't use String.isEmpty :). > > > > > > Al. > > > > > > -- > > > > > > * Written an Android App? - List it at http://andappstore.com/ * > > > > > > == > > > Funky Android Limited is registered in England & Wales with the > > > company number 6741909. The registered head office is Kemp House, > > > 152-160 City Road, London, EC1V 2NX, UK. > > > > > > The views expressed in this email are those of the author and not > > > necessarily those of Funky Android Limited, it's associates, or it's > > > subsidiaries. > > > > > > -Original Message- > > > From: Wes Wannemacher [mailto:w...@wantii.com] > > > Sent: 24 August 2009 04:26 > > > To: Struts Developers List > > > Subject: Re: Build requires JDK 1.6 now - EmbeddedJSP plugin > > > > > > On Sunday 23 August 2009 09:48:55 pm Jeromy Evans wrote: > > > > Hi guys, > > > > > > > > I may have missed the announcement, but it seems Java 1.6 is now > > > > mandatory to perform a full build of Struts 2.1.8+ > > > > > > > > The EmbeddedJSP plugin's JSPLoader uses javax.tools.JavaCompiler that > > > > is "Since 1.6" only. > > > > > > > > If not deliberate, we may need a j5 profile in the build that > excludes > > > > that module (is that even possible?) > > > > > > > > > > We could easily create a profile that doesn't include the embeddedjsp > > > plugin > > > (and any other new modules that may require java 6). The real question > is > > > whether we want to continue targeting Java 5 and exclude the Java 6 > stuff > > > by > > > default or vice versa? I'll go see if google can tell me about the > > lifespan > > > of > > > Java 5. > > > > > > -Wes > > > > > > -- > > > Wes Wannemacher > > > > > > Head Engineer, WanTii, Inc. > > > Need Training? Struts, Spring, Maven, Tomcat... > > > Ask me for a quote! > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > >
Struts build stuck in Continuum
If you look at the Struts 1.3.11 build, you'll see it's build is stuck. It is constantly reported as "in progress" but goes nowhere. I guess it's been that way since August. http://vmbuild1.apache.org/continuum/projectGroupSummary.action?projectGroupId=33 Who do I contact to get this fixed? Also, how do I log in? Paul
Re: Struts build stuck in Continuum
Well Continuum is definitely broken. I registered and it has be in a "change password" loop. I sign in, tells me I have to change passwords, and I do this dance forever. Thanks Wendy for telling me where to write. Paul On Tue, Sep 22, 2009 at 9:24 PM, Wendy Smoak wrote: > On Tue, Sep 22, 2009 at 11:07 AM, Paul Benedict > wrote: > > If you look at the Struts 1.3.11 build, you'll see it's build is stuck. > It > > is constantly reported as "in progress" but goes nowhere. I guess it's > been > > that way since August. > > > > > http://vmbuild1.apache.org/continuum/projectGroupSummary.action?projectGroupId=33 > > > > Who do I contact to get this fixed? > > There is a builds@ list where the folks who maintain the various CI > servers hang out. > > http://www.apache.org/dev/builds.html > > > Also, how do I log in? > > It's a separate userid and password. If you haven't set one up > already, click "Register" at the top, then ping the builds@ list and > ask for access to the Struts project groups. If you already have an > account, there's a password reset feature. > > (Copying Hen so he'll know it's been answered, not sure why you picked him. > :) ) > > -- > Wendy > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
Re: zip problems with 2.1.8
Sorry, I meant 1.2.8 should be removed. On Thu, Oct 1, 2009 at 12:35 PM, Paul Benedict wrote: > If the artifacts are bad, version 1.2.8.1 should be deleted from the > repository. What I've been reading on the Maven Developer's List, this > kind of issue is probably the one acceptable time to remove a version. > > Paul > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
If the artifacts are bad, version 1.2.8.1 should be deleted from the repository. What I've been reading on the Maven Developer's List, this kind of issue is probably the one acceptable time to remove a version. Paul On Thu, Oct 1, 2009 at 12:30 PM, Wes Wannemacher wrote: > So, I was trying to figure out what is going on here because there are > more problems with the zip than mentioned on the user@ list. Since I > took site-deploy out of the release plugins default goals (to keep > other artifacts from stomping the main struts.apache.org site), it had > the unintended side effect of not running the site generation for the > rest of the artifacts... This means that (among other things) the > javadocs aren't in the docs zip. > > I am going to pull down the 2.1.8 sources via the tag and create a > 2.1.8.1 build to fix the docs zip. I will configure the release plugin > on the struts2 pom file (so that I will not be making changes to > struts-master). In addition, I will fix the funky characters in > filenames by passing the appropriate parameters to wget. To do this, I > will have to branch SVN, so I want to make a 2.1 branch and then we > can make this the time to move trunk to 2.2.0 and begin working on > some of the recent ideas (incorporating xwork being the biggest). > > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
Oh, okay. I misunderstood. If only the Apache distribution packages are messed up, go ahead and replace those. I don't think that calls for a new build. I had bad MD5 files before. I was asked to fix those on a release (after the mirrors received them), and I did. Paul On Thu, Oct 1, 2009 at 12:44 PM, Musachy Barroso wrote: > that sounds good to me. If we just overwrite 2.1.8 then the mirrors > will also be updated right? This is technically speaking 2.1.8. > > musachy > > On Thu, Oct 1, 2009 at 10:30 AM, Wes Wannemacher wrote: >> So, I was trying to figure out what is going on here because there are >> more problems with the zip than mentioned on the user@ list. Since I >> took site-deploy out of the release plugins default goals (to keep >> other artifacts from stomping the main struts.apache.org site), it had >> the unintended side effect of not running the site generation for the >> rest of the artifacts... This means that (among other things) the >> javadocs aren't in the docs zip. >> >> I am going to pull down the 2.1.8 sources via the tag and create a >> 2.1.8.1 build to fix the docs zip. I will configure the release plugin >> on the struts2 pom file (so that I will not be making changes to >> struts-master). In addition, I will fix the funky characters in >> filenames by passing the appropriate parameters to wget. To do this, I >> will have to branch SVN, so I want to make a 2.1 branch and then we >> can make this the time to move trunk to 2.2.0 and begin working on >> some of the recent ideas (incorporating xwork being the biggest). >> >> >> -- >> Wes Wannemacher >> >> Head Engineer, WanTii, Inc. >> Need Training? Struts, Spring, Maven, Tomcat... >> Ask me for a quote! >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
I still advocate deleting the 2.1.8 binaries. Will that be done? Any bad distribution should get the shovel. Paul On Thu, Oct 1, 2009 at 2:05 PM, Wes Wannemacher wrote: > I've already branched and made the changes to the poms (to make the > whole thing build correctly). To me, I'd rather get it done right than > to just push out a few updated zips, especially since this includes > the struts-2.1.8-all.zip. I'll have the build pushed out to the > staging repo in a bit and I think maybe what we can do is possibly do > a fast-track vote... I know Martin likes to make sure that we have the > required amount of time, but in this instance, it's really just a few > pom updates, so I think we should just treat it like a security fix > release... > > -Wes > > On Thu, Oct 1, 2009 at 2:57 PM, Paul Benedict wrote: >> Oh, okay. I misunderstood. If only the Apache distribution packages >> are messed up, go ahead and replace those. I don't think that calls >> for a new build. >> >> I had bad MD5 files before. I was asked to fix those on a release >> (after the mirrors received them), and I did. >> >> Paul >> >> On Thu, Oct 1, 2009 at 12:44 PM, Musachy Barroso wrote: >>> that sounds good to me. If we just overwrite 2.1.8 then the mirrors >>> will also be updated right? This is technically speaking 2.1.8. >>> >>> musachy >>> >>> On Thu, Oct 1, 2009 at 10:30 AM, Wes Wannemacher wrote: >>>> So, I was trying to figure out what is going on here because there are >>>> more problems with the zip than mentioned on the user@ list. Since I >>>> took site-deploy out of the release plugins default goals (to keep >>>> other artifacts from stomping the main struts.apache.org site), it had >>>> the unintended side effect of not running the site generation for the >>>> rest of the artifacts... This means that (among other things) the >>>> javadocs aren't in the docs zip. >>>> >>>> I am going to pull down the 2.1.8 sources via the tag and create a >>>> 2.1.8.1 build to fix the docs zip. I will configure the release plugin >>>> on the struts2 pom file (so that I will not be making changes to >>>> struts-master). In addition, I will fix the funky characters in >>>> filenames by passing the appropriate parameters to wget. To do this, I >>>> will have to branch SVN, so I want to make a 2.1 branch and then we >>>> can make this the time to move trunk to 2.2.0 and begin working on >>>> some of the recent ideas (incorporating xwork being the biggest). >>>> >>>> >>>> -- >>>> Wes Wannemacher >>>> >>>> Head Engineer, WanTii, Inc. >>>> Need Training? Struts, Spring, Maven, Tomcat... >>>> Ask me for a quote! >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
Wendy, I did say in a later email I wrongly believed we were talking about Maven repos. If it is just the Apache distributions, and those have bogus files, those should be deleted. Just can the whole release. I think that's sensible. Paul On Thu, Oct 1, 2009 at 3:00 PM, Wes Wannemacher wrote: > On Thu, Oct 1, 2009 at 3:51 PM, Wendy Smoak wrote: >> On Thu, Oct 1, 2009 at 12:39 PM, Paul Benedict wrote: >>> I still advocate deleting the 2.1.8 binaries. Will that be done? Any >>> bad distribution should get the shovel. >> >> As I understand it, there's nothing wrong with the artifacts in the >> Maven repo, and no reason to delete them. >> >> This is a problem with any of the distribution zip files that contain >> documentation, correct? (Because of a question mark in a filename?) >> That is, there's nothing wrong with the code, it's a packaging issue? >> > > Wendy, you are 100% correct on issue one. > > On issue two, there are multiple problems with the packaged > documentation. Not only does the ? character cause problems with > windows users, but the documentation is incomplete because of the > change to the struts-master pom file I made a while back. Again, > neither of these issues affects the maven artifacts... > > The main reason I want to proceed by making this a new build is this - > how do I know the problems are truly resolved, unless I go through > the process? In the end, there should be no difference between > Musachy's build of the jars (for 2.1.8) and what I am doing (2.1.8.1). > The difference is that Musachy and I are working hard to streamline > the release process so that where it is not easy, it is > well-documented and robust. That way people other than myself and > Musachy will be willing to jump in and do a release periodically. > > -Wes > > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
Wendy, Your logic about repacking everything or nothing makes sense. Agreed. Lastly, unless there needs to be changes within SVN (like correcting Maven configuration to fix the build), I see no reason for a new release. Were there commits to fix something? If so, that satisfies me. Otherwise, it's totally unnecessary if the build was wonky because of a committer's command-line. Paul On Thu, Oct 1, 2009 at 4:28 PM, Wendy Smoak wrote: > "The whole release" would be both the distribution zips and the Maven > artifacts. If we're going to retract the release, we should retract > *all* of it. I'm not in favor of that since the code is fine, we just > have a packaging problem with the documentation. > > As I understand the proposed solution, we're not going to change > anything about 2.1.8, but instead do a full 2.1.8.1 (distribution zips > and Maven artifacts) to correct the problem. > > I'm okay with that, but would not rush the release vote since it needs > more testing, not less... > > -- > Wendy > > On Thu, Oct 1, 2009 at 1:18 PM, Paul Benedict wrote: >> Wendy, I did say in a later email I wrongly believed we were talking >> about Maven repos. If it is just the Apache distributions, and those >> have bogus files, those should be deleted. Just can the whole release. >> I think that's sensible. >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: zip problems with 2.1.8
Musachy, Policy is that the user list is only notified for releases. For a release to occur, it needs at least 3 +1 binding votes. Maybe one option is to introduce a graded release promotion. First, eliminate the possibility to vote GA in the first round; it becomes either Beta or the version is burned. Second, once a week or two pass by after a successful beta vote, you can then call a second vote to bump from Beta to GA. NB: MySQL does something very similar. Paul On Fri, Oct 2, 2009 at 12:00 AM, Musachy Barroso wrote: > I still don't understand why we don't let users know that there is a > build that we are testing so we get more eyes on it, before we call it > a GA. Is there any practical reason? or is it just the way it has > always been done? > > musahcy > > On Thu, Oct 1, 2009 at 8:19 PM, Wes Wannemacher wrote: >> I was sort of thinking the same thing... I know I'll check the docs >> zip in the future, but I think it's a legitimate mistake that most of >> us aren't looking in the docs zip (since we've all already read them >> all, cover to cover, right?) :) >> >> -Wes >> >> On Thu, Oct 1, 2009 at 11:15 PM, Musachy Barroso wrote: . In fact, I would ask those who voted on 2.1.8 to look at how they tested before they voted, and perhaps think about ways in which they might change their testing so that we can catch something like this before it goes out in a release again. >>> >>> Hey my windows partition is just for playing video games :) >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> >> -- >> Wes Wannemacher >> >> Head Engineer, WanTii, Inc. >> Need Training? Struts, Spring, Maven, Tomcat... >> Ask me for a quote! >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [ANN] 2.1.8.1 builds available to test
Wes,
Have you thought about staging the site yourself under your user
directory? Whenever I did 1.x releases, I didn't modify any of the
public web site until a release got pushed.
Paul
On Sat, Oct 3, 2009 at 11:55 AM, Wes Wannemacher wrote:
> Hello,
>
> I made some changes to the STRUTS_2_1_X branch to address the recent
> docs-zip and all-zip problems. The test builds will be available at
> http://people.apache.org/builds/struts/2.1.8.1 please check them out
> and make sure all the docs are intact and test the apps, etc.
>
> Notes - I agree with Martin's notion that we should first post the
> builds then vote later. But, there were some environmental changes I
> had to make. I will have to merge some pom changes to deal with the
> struts.apache.org/2.x thing. I turned 2.x into a symlink that points
> to the latest GA release and have the poms push their 'site's to the
> ${pom.version} so I don't stomp the existing 2.x site. This creates a
> problem with the copying of the cwiki export, since the GA docs will
> be overwritten. In this case we're sort of screwed if we do and
> screwed if we don't, so I'm open to suggestions on that. For this
> build, please test not only the zips/artifacts, but check the website
> to make sure that links didn't get broken and that docs point to what
> you would expect.
>
> -Wes
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: bug On struts1: MessageResources.getMessage locale , whether has the problem?
Are you trying to tell us a problem or a recommendation?
2009/8/11 3844370 <3844...@163.com>:
>
> On struts1: MessageResources.getMessage(Locale locale, String key, Object[]
> args) , don't use client's locale to format !
> for example: my webApp has a myResources_en_US.properties : test =your money
> is {0, number, currency}
> client's locale is en_US， server's locale is zh_CN
> my action :
> MessageResources resource = getResources(request, "myResources");
> //client's locale
> Locale userLocale = getLocale(request);
> //use client's locale to format value , problem is here!
> String message = resource.getMessage(userLocale, "test", new Object[]{ new
> Long(1)})
>
> the result is : your money is ￥10,000.00 ,
> problem is: I use english locale to format “ your money is {0, number,
> currency}” ，but now why is ￥？？
>
> so, I read src about getMessage(Locale locale, String key, Object[] args)，
> format = new MessageFormat(escape(formatString));
> format.setLocale(locale);
> format.format(args)
>
> for MessageFormat setLocale() , Subformats that have already been created are
> not affected，
> so, struts1 getMessage(Locale locale, String key, Object[] args), original
> idea is use client's locale to format,
> but now use server's locale, this is the problem!
>
> following is my test procedures:
> Locale localeEN = new Locale("en", "US");
>
> // simulate struts1 MessageResources.getMessage(Locale locale, String key,
> Object[] args)
> MessageFormat format1 = new MessageFormat(" your money is {0, number,
> currency}");
> //now set EN locale already later to format "your money is {0, number,
> currency}"
> format1.setLocale(localeEN);
> System.out.println(format1.format(new Object[]{ new Long(1)})); //
> your money is ￥10,000.00
>
> //correct method 1
> MessageFormat format2 = new MessageFormat(" your money is {0, number,
> currency}", localeEN);
> System.out.println(format2.format(new Object[]{ new Long(1)})); // your
> money is $10,000.00
>
> //correct method 2
> MessageFormat format3 = new MessageFormat("");
> format3.setLocale(localeEN);
> format3.applyPattern(" your money is {0, number, currency}");
> System.out.println(format3.format(new Object[]{ new Long(1)})); // your
> money is $10,000.00
>
> please write back! Thank you!
> yours, wangyanning from JiNan ShanDong Province in CHINA
>
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Struts 1 + Spring
Based on the latest javadocs, Spring 3.0 no longer includes Struts 1.x support. Because of this, I want to copy their struts package into a new struts-spring module to be distributed here at Apache. Their code is already published under the ASL -- must I go through IP clearance procedures? Or does Apache really believe ASL code is free? Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: End of Life for Struts 1.1
Joseph, Struts is run by a non-profit organization and work is done by volunteers. I do not believe Apache has any "end of life" policy. You are free to use it forever. Paul On Thu, Nov 19, 2009 at 1:46 PM, Joseph Tomassini wrote: > Can you please tell me the end-of-life date for Struts 1.1? Thanks. > > - JAT > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: End of Life for Struts 1.1
Jason, I refer you to my previous answer. With the source code freely available, you are willing to alter it and submit pack patches at will. We are already at Struts 1.3.10 and 1.4 is in the oven, and 2.0/2.1 is hot. As for 1.1, it is pretty old so I would upgrade -- at least to another 1.x -- if you want continued benefit. Paul On Mon, Nov 23, 2009 at 8:14 AM, Jason Pyeron wrote: > >> -Original Message- >> From: Paul Benedict >> Sent: Monday, November 23, 2009 9:01 >> To: Struts Developers List >> Subject: Re: End of Life for Struts 1.1 >> >> Joseph, >> >> Struts is run by a non-profit organization and work is done >> by volunteers. I do not believe Apache has any "end of life" >> policy. You are free to use it forever. > > In other words, when will feature/bug fix/security fix updates be ceased. > >> >> Paul >> >> On Thu, Nov 19, 2009 at 1:46 PM, Joseph Tomassini >> wrote: >> > Can you please tell me the end-of-life date for Struts 1.1? Thanks. > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Principal Consultant 10 West 24th Street #100 - > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > This message is copyright PD Inc, subject to license 20080407P00. > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: End of Life for Struts 1.1
And, I suppose you can also reach out to "hire" a release manager to patch, build, and release if it is absolutely necessary for your company. It never happened to me, but many companies do pay people to work on Apache projects. Paul On Mon, Nov 23, 2009 at 8:19 AM, Antonio Petrelli wrote: > 2009/11/23 Paul Benedict : >> I refer you to my previous answer. With the source code freely >> available, you are willing to alter it and submit pack patches at >> will. We are already at Struts 1.3.10 and 1.4 is in the oven, and >> 2.0/2.1 is hot. As for 1.1, it is pretty old so I would upgrade -- at >> least to another 1.x -- if you want continued benefit. > > To complete what Paul have written, a support contract never existed, > this is the point of a community-developed software. > Anyway usually at Apache we continue to support/fix the latest GA > version of a software. In the case of Struts 1, it is Struts 1.3.10. > So, you are encouraged to upgrade to Struts 1.3.10 and, if you find a > bug, file a JIRA issue and, if possible, post a patch so it will be > fixed ASAP. > In the case of Struts 1.1 (and even 1.2) your only way to get it fixed > is downloading the source code, fix it and build it yourself. > > Ciao > Antonio > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart wrote: > In my opinion, current DI support is sufficient (it can be made more > readable, but that's it ;-), I really don't get it what's the problem with > double ObjectFactory issue??? > > > Regards > -- > Lukasz > http://www.lenart.org.pl/ > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli wrote: > JSR 299 is EE while 330 is SE. > > -bp > > > On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: > >> I've been loosely following the thread. It sounds like three DI >> projects are being/will be supported: >> * XWork >> * Guice >> * JSR-299/JSR-330 >> >> Why three? I can understand the last because it's EE, but the other >> two are proprietary. >> >> Paul >> >> On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart >> wrote: >>> In my opinion, current DI support is sufficient (it can be made more >>> readable, but that's it ;-), I really don't get it what's the problem with >>> double ObjectFactory issue??? >>> >>> >>> Regards >>> -- >>> Lukasz >>> http://www.lenart.org.pl/ >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Since the XWork code is now owned by Apache (right?), you could split it into two jars (workflow and DI). Then deprecate the DI artifact unless someone here as aspirations to continue such support. Split in two, this would hopefully also address Don's concern of the code base being too big. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli wrote: > XWork is more than DI. If drives the workflow under the hoods of Struts. We > would need all of that code in addition to the DI. The idea is to drop the DI > part of XWork and replace it with Guice 2.1 (which should support JSR 330) > and just pull in the rest of it. > > -bp > > > On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: > >> Then what was the point of getting the IP for XWork? >> >> On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli >> wrote: >>> JSR 299 is EE while 330 is SE. >>> >>> -bp >>> >>> >>> On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: >>> >>>> I've been loosely following the thread. It sounds like three DI >>>> projects are being/will be supported: >>>> * XWork >>>> * Guice >>>> * JSR-299/JSR-330 >>>> >>>> Why three? I can understand the last because it's EE, but the other >>>> two are proprietary. >>>> >>>> Paul >>>> >>>> On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart >>>> wrote: >>>>> In my opinion, current DI support is sufficient (it can be made more >>>>> readable, but that's it ;-), I really don't get it what's the problem with >>>>> double ObjectFactory issue??? >>>>> >>>>> >>>>> Regards >>>>> -- >>>>> Lukasz >>>>> http://www.lenart.org.pl/ >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Don, > JSR 330 is not the magic bullet here. Agreed, but I would have to say it would be foolish not to support it. As companies perform internal tech evaluations, people will eventually realize "standard" DI injection is not supported: "Oh, our company has to learn XWork DI? What the heck is XWork?" Well, that could be seen as a negative and affect adoption. A FUTURE scenario, but one likely to occur one day. I don't care what DI container runs JSR-330, but it should be the job of Struts 2 to allow *swappable* implementations through a Bridge adapter. Will our users have the choice of Apache's Open Web Beans [1]? I hope so. Likewise, Commons Validator 2.0 will be a JSR-303 Bean Validation implementation. Same lesson to be learned here. [1] http://incubator.apache.org/openwebbeans/ Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Version number ordering
I have nothing against continuing the way *we* do it, but Maven doesn't do it this way. Taking the defaults provided by the Maven Release Plugin will create tag names like "struts-1.3.11" over "STRUTS_1_3_11". Either way we decide, it is not a major loss for the other side, but not able to accept Maven defaults is a bit disappointing. Paul On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper wrote: > On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher wrote: >> Not to split hairs, Lukasz, but this is the "released" pom - >> >> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >> >> Which looks fine. >> >> When I was checking this, it reminded me of something I have been >> meaning to ask. If you look at the tag name that Lukasz used - >> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >> can see here - >> >> https://svn.apache.org/repos/asf/struts/struts2/tags/ >> >> The tag name that Lukasz used is what the release plugin defaults >> to... Is there a reason we don't use it? I'm all about sticking to >> defaults (since it tends to make the documentation easier), so I am >> wondering if there is a reason, other than "that's the way we always >> did it" > > To my knowledge, "that's the way we always did it" is the correct > answer here, assuming the question is "upper case and underscores" > versus "lower case and dashes". As you can see here, the former has > been used since the very beginning of Struts, almost 10 years ago: > > http://svn.apache.org/repos/asf/struts/struts1/tags/ > > Bear in mind that there's an enormous amount of Struts history prior > to us adopting Maven, let alone the Maven release plugin, so this is > hardly surprising. That the Maven default is different is simply the > result of the Maven team picking the wrong default release naming > scheme. :-p > > If there's an easy way to tell the release plugin to use "upper case > and underscores" instead of "lower case and dashes", the continuity > would be nice, since there's no other good reason to change what we've > been doing for so long. If there isn't an easy way to do that, though, > and it's a nuisance to change the default for some reason, then I'm > not dead set against adopting the Maven way. > > -- > Martin Cooper > > >> -Wes >> >> On Wed, Dec 16, 2009 at 12:50 PM, Lukasz Lenart >> wrote: >>> 2009/12/16 Martin Cooper : In Lukasz's checkins just now, I see version numbers being changed to 2.1.8-SNAPSHOT. Maybe I'm misinterpreting what's going on, but that seems like going backwards. We already have a 2.1.8 and a 2.1.8.1, so it seems to me that any snapshot version we should be using now would need to be 2.1.9-SNAPSHOT, no? After all, snapshots precede the number they're attached to, in terms of version number ordering. >>> >>> I just switched to 2.1.8-SNAPSHOT because Maven release plugin is >>> complaining - after I did the release, everything is ok, please check >>> already released pom.xml >>> >>> https://svn.apache.org/repos/asf/struts/maven/trunk/struts2-archetype-blank/pom.xml >>> >>> >>> Regards >>> -- >>> Lukasz >>> http://www.lenart.org.pl/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> >> -- >> Wes Wannemacher >> >> Head Engineer, WanTii, Inc. >> Need Training? Struts, Spring, Maven, Tomcat... >> Ask me for a quote! >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Version number ordering
I am saying that if we keep the uppercase and underscore convention, we can't accept the default of Maven's tag names. The release manager just has to continue using the format we do today. That's all. Paul On Thu, Dec 17, 2009 at 5:38 PM, Martin Cooper wrote: > On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict wrote: >> I have nothing against continuing the way *we* do it, but Maven >> doesn't do it this way. Taking the defaults provided by the Maven >> Release Plugin will create tag names like "struts-1.3.11" over >> "STRUTS_1_3_11". >> >> Either way we decide, it is not a major loss for the other side, but >> not able to accept Maven defaults is a bit disappointing. > > Who / what is not able to accept them? > > -- > Martin Cooper > > >> Paul >> >> On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper wrote: >>> On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher wrote: >>>> Not to split hairs, Lukasz, but this is the "released" pom - >>>> >>>> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >>>> >>>> Which looks fine. >>>> >>>> When I was checking this, it reminded me of something I have been >>>> meaning to ask. If you look at the tag name that Lukasz used - >>>> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >>>> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >>>> can see here - >>>> >>>> https://svn.apache.org/repos/asf/struts/struts2/tags/ >>>> >>>> The tag name that Lukasz used is what the release plugin defaults >>>> to... Is there a reason we don't use it? I'm all about sticking to >>>> defaults (since it tends to make the documentation easier), so I am >>>> wondering if there is a reason, other than "that's the way we always >>>> did it" >>> >>> To my knowledge, "that's the way we always did it" is the correct >>> answer here, assuming the question is "upper case and underscores" >>> versus "lower case and dashes". As you can see here, the former has >>> been used since the very beginning of Struts, almost 10 years ago: >>> >>> http://svn.apache.org/repos/asf/struts/struts1/tags/ >>> >>> Bear in mind that there's an enormous amount of Struts history prior >>> to us adopting Maven, let alone the Maven release plugin, so this is >>> hardly surprising. That the Maven default is different is simply the >>> result of the Maven team picking the wrong default release naming >>> scheme. :-p >>> >>> If there's an easy way to tell the release plugin to use "upper case >>> and underscores" instead of "lower case and dashes", the continuity >>> would be nice, since there's no other good reason to change what we've >>> been doing for so long. If there isn't an easy way to do that, though, >>> and it's a nuisance to change the default for some reason, then I'm >>> not dead set against adopting the Maven way. >>> >>> -- >>> Martin Cooper >>> >>> >>>> -Wes >>>> >>>> On Wed, Dec 16, 2009 at 12:50 PM, Lukasz Lenart >>>> wrote: >>>>> 2009/12/16 Martin Cooper : >>>>>> In Lukasz's checkins just now, I see version numbers being changed to >>>>>> 2.1.8-SNAPSHOT. Maybe I'm misinterpreting what's going on, but that >>>>>> seems like going backwards. We already have a 2.1.8 and a 2.1.8.1, so >>>>>> it seems to me that any snapshot version we should be using now would >>>>>> need to be 2.1.9-SNAPSHOT, no? After all, snapshots precede the number >>>>>> they're attached to, in terms of version number ordering. >>>>> >>>>> I just switched to 2.1.8-SNAPSHOT because Maven release plugin is >>>>> complaining - after I did the release, everything is ok, please check >>>>> already released pom.xml >>>>> >>>>> https://svn.apache.org/repos/asf/struts/maven/trunk/struts2-archetype-blank/pom.xml >>>>> >>>>> >>>>> Regards >>>>> -- >>>>> Lukasz >>>>> http://www.lenart.org.pl/ >>>>> >>>>> --
Re: Version number ordering
Martin, Just to be clear, I am not saying that the Maven's way is the right way. There are two way to do releases: manually or batch. In manual mode, the user is prompted to name the tag. In batch mode, Maven creates the tag by its own naming standards (projectname-version). Paul On Thu, Dec 17, 2009 at 5:44 PM, Martin Cooper wrote: > On Thu, Dec 17, 2009 at 3:40 PM, Paul Benedict wrote: >> I am saying that if we keep the uppercase and underscore convention, >> we can't accept the default of Maven's tag names. The release manager >> just has to continue using the format we do today. That's all. > > I was trying to understand the disappointment you expressed. My own > disappointment, to the extent that I have any, is that we let the > Maven team define the standards that we use for our releases, but as I > said before, I'm not married to keeping the "old" way. > > -- > Martin Cooper > > >> Paul >> >> On Thu, Dec 17, 2009 at 5:38 PM, Martin Cooper wrote: >>> On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict wrote: >>>> I have nothing against continuing the way *we* do it, but Maven >>>> doesn't do it this way. Taking the defaults provided by the Maven >>>> Release Plugin will create tag names like "struts-1.3.11" over >>>> "STRUTS_1_3_11". >>>> >>>> Either way we decide, it is not a major loss for the other side, but >>>> not able to accept Maven defaults is a bit disappointing. >>> >>> Who / what is not able to accept them? >>> >>> -- >>> Martin Cooper >>> >>> >>>> Paul >>>> >>>> On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper wrote: >>>>> On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher wrote: >>>>>> Not to split hairs, Lukasz, but this is the "released" pom - >>>>>> >>>>>> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >>>>>> >>>>>> Which looks fine. >>>>>> >>>>>> When I was checking this, it reminded me of something I have been >>>>>> meaning to ask. If you look at the tag name that Lukasz used - >>>>>> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >>>>>> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >>>>>> can see here - >>>>>> >>>>>> https://svn.apache.org/repos/asf/struts/struts2/tags/ >>>>>> >>>>>> The tag name that Lukasz used is what the release plugin defaults >>>>>> to... Is there a reason we don't use it? I'm all about sticking to >>>>>> defaults (since it tends to make the documentation easier), so I am >>>>>> wondering if there is a reason, other than "that's the way we always >>>>>> did it" >>>>> >>>>> To my knowledge, "that's the way we always did it" is the correct >>>>> answer here, assuming the question is "upper case and underscores" >>>>> versus "lower case and dashes". As you can see here, the former has >>>>> been used since the very beginning of Struts, almost 10 years ago: >>>>> >>>>> http://svn.apache.org/repos/asf/struts/struts1/tags/ >>>>> >>>>> Bear in mind that there's an enormous amount of Struts history prior >>>>> to us adopting Maven, let alone the Maven release plugin, so this is >>>>> hardly surprising. That the Maven default is different is simply the >>>>> result of the Maven team picking the wrong default release naming >>>>> scheme. :-p >>>>> >>>>> If there's an easy way to tell the release plugin to use "upper case >>>>> and underscores" instead of "lower case and dashes", the continuity >>>>> would be nice, since there's no other good reason to change what we've >>>>> been doing for so long. If there isn't an easy way to do that, though, >>>>> and it's a nuisance to change the default for some reason, then I'm >>>>> not dead set against adopting the Maven way. >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>>> -Wes >>>>>> >>>>>>
Re: Version number ordering
Sweet! Thanks, Lukasz. I voted for it. I hope everyone else here votes for it too. On Fri, Dec 18, 2009 at 1:13 AM, Lukasz Lenart wrote: > Hi, > > Here is the solution for our problem -> > http://jira.codehaus.org/browse/MRELEASE-159 > though either we need to wait for Maven team or to build our own > release manager ;-) > > > Regards > -- > Lukasz > http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Moving Struts 1 Doc to Confluence
I would like to move the Struts 1 documentation from SVN to Confluence. As old (10 years almost?!) as Struts 1 is, today it is not possible for any community member to update it without having SVN commit access. I think it's too high a bar. Does anyone have any technical objections to this? Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
Thanks Martin and Wendy for your replies. On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper wrote: > If you're concerned about the need for committership, then certainly > the bar is a bit higher than just filing an iCLA. However, it's > absolutely possible to gain committership for documentation, rather > than code. I can think of two people, off the top of my head, who have > been given committership in Struts primarily for documentation, at > least initially. If there are people who are contributing patches for > the docs, then perhaps we should be looking at that. I didn't know people could be given committer rights to only documentation. Last time I probed this topic, I was told (and the email thread exists somewhere) that there are no such thing as partial rights -- you get to commit access to everything (or nothing) under the struts group. Since Confluence is a different system, perhaps things became more lenient when I wasn't looking. > One other option that comes to mind is Sidewiki. I haven't actually > played with this myself yet, but it seems like it might be an > interesting option for allowing anyone to add content and comments > alongside the official docs. Anyone have an opinion on how viable, or > otherwise, this might be? I wasn't hoping to open up a new wiki discussion ;-) but I do remember some committers saying they're unhappy with Confluence. If all of Struts could put their documentation in one place, I am willing to go wherever the group decides. > So I guess what I'm saying is that no, I don't think I have "technical > objections", but I think there might be other alternatives worth > discussing too. Migrating the docs would not be an easy task! Yes, I don't look forward to it, but I think keeping it in SVN is akin to being frozen in an ice-berg. Even I hate editing it. Anyway, with the help of Lukasz, I hope it is easier. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Accept the XWork project as donated by OpenSymphony
[X] Yes, accept the XWork project On Sat, Dec 26, 2009 at 11:11 AM, Martin Cooper wrote: >> This is a vote for the Struts PMC to formally accept the donation of >> the XWork project from OpenSymphony. This is a required step of the IP >> Clearance procedure documented here: >> >> http://incubator.apache.org/ip-clearance/index.html >> >> The XWork artifacts and software grant are available for your perusal here: >> >> https://issues.apache.org/struts/browse/WW-3248 >> >> Upon successful conclusion of this vote, the code base attached to the >> above issue will be checked in as a Struts subproject, and the IP >> Clearance procedure completed. >> >> PMC members, please indicate your vote below. >> >> [ ] Yes, accept the XWork project >> [ ] I don't really care one way or the other >> [ ] No, do not accept the XWork project, for these reasons (please specify) - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
Can we defer the research into another wiki? I would at least get into Confluence and then move everything to something new, if desired. Paul On Sat, Dec 26, 2009 at 11:55 AM, Martin Cooper wrote: > On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict wrote: >> Thanks Martin and Wendy for your replies. >> >> On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper wrote: >>> If you're concerned about the need for committership, then certainly >>> the bar is a bit higher than just filing an iCLA. However, it's >>> absolutely possible to gain committership for documentation, rather >>> than code. I can think of two people, off the top of my head, who have >>> been given committership in Struts primarily for documentation, at >>> least initially. If there are people who are contributing patches for >>> the docs, then perhaps we should be looking at that. >> >> I didn't know people could be given committer rights to only >> documentation. Last time I probed this topic, I was told (and the >> email thread exists somewhere) that there are no such thing as partial >> rights -- you get to commit access to everything (or nothing) under >> the struts group. > > That's not what I meant. Sorry if I wasn't clear. It's still true that > commit access is for all of the Struts repo and not for pieces of it. > What I meant is that people can earn commit rights on the basis of > their work on documentation. Merit is not confined only to code. > > -- > Martin Cooper > > >> Since Confluence is a different system, perhaps >> things became more lenient when I wasn't looking. >> >>> One other option that comes to mind is Sidewiki. I haven't actually >>> played with this myself yet, but it seems like it might be an >>> interesting option for allowing anyone to add content and comments >>> alongside the official docs. Anyone have an opinion on how viable, or >>> otherwise, this might be? >> >> I wasn't hoping to open up a new wiki discussion ;-) but I do remember >> some committers saying they're unhappy with Confluence. If all of >> Struts could put their documentation in one place, I am willing to go >> wherever the group decides. >> >>> So I guess what I'm saying is that no, I don't think I have "technical >>> objections", but I think there might be other alternatives worth >>> discussing too. Migrating the docs would not be an easy task! >> >> Yes, I don't look forward to it, but I think keeping it in SVN is akin >> to being frozen in an ice-berg. Even I hate editing it. Anyway, with >> the help of Lukasz, I hope it is easier. >> >> Paul >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
I may have gotten the wrong impression, but it seems all SideWiki content is stored in Google. I have a thing about letting Google owning all the world's data. Paul On Sat, Dec 26, 2009 at 8:03 PM, Martin Cooper wrote: > On Sat, Dec 26, 2009 at 5:42 PM, Paul Benedict wrote: >> Can we defer the research into another wiki? I would at least get into >> Confluence and then move everything to something new, if desired. > > Sigh. Please just take 2 minutes to look at what Sidewiki is. It's not > something else we would move our content to, it's an alternative means > for the community to add content to existing pages. > > -- > Martin Cooper > > >> Paul >> >> On Sat, Dec 26, 2009 at 11:55 AM, Martin Cooper wrote: >>> On Sat, Dec 26, 2009 at 9:41 AM, Paul Benedict wrote: >>>> Thanks Martin and Wendy for your replies. >>>> >>>> On Sat, Dec 26, 2009 at 10:15 AM, Martin Cooper wrote: >>>>> If you're concerned about the need for committership, then certainly >>>>> the bar is a bit higher than just filing an iCLA. However, it's >>>>> absolutely possible to gain committership for documentation, rather >>>>> than code. I can think of two people, off the top of my head, who have >>>>> been given committership in Struts primarily for documentation, at >>>>> least initially. If there are people who are contributing patches for >>>>> the docs, then perhaps we should be looking at that. >>>> >>>> I didn't know people could be given committer rights to only >>>> documentation. Last time I probed this topic, I was told (and the >>>> email thread exists somewhere) that there are no such thing as partial >>>> rights -- you get to commit access to everything (or nothing) under >>>> the struts group. >>> >>> That's not what I meant. Sorry if I wasn't clear. It's still true that >>> commit access is for all of the Struts repo and not for pieces of it. >>> What I meant is that people can earn commit rights on the basis of >>> their work on documentation. Merit is not confined only to code. >>> >>> -- >>> Martin Cooper >>> >>> >>>> Since Confluence is a different system, perhaps >>>> things became more lenient when I wasn't looking. >>>> >>>>> One other option that comes to mind is Sidewiki. I haven't actually >>>>> played with this myself yet, but it seems like it might be an >>>>> interesting option for allowing anyone to add content and comments >>>>> alongside the official docs. Anyone have an opinion on how viable, or >>>>> otherwise, this might be? >>>> >>>> I wasn't hoping to open up a new wiki discussion ;-) but I do remember >>>> some committers saying they're unhappy with Confluence. If all of >>>> Struts could put their documentation in one place, I am willing to go >>>> wherever the group decides. >>>> >>>>> So I guess what I'm saying is that no, I don't think I have "technical >>>>> objections", but I think there might be other alternatives worth >>>>> discussing too. Migrating the docs would not be an easy task! >>>> >>>> Yes, I don't look forward to it, but I think keeping it in SVN is akin >>>> to being frozen in an ice-berg. Even I hate editing it. Anyway, with >>>> the help of Lukasz, I hope it is easier. >>>> >>>> Paul >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
Martin, On Sun, Dec 27, 2009 at 11:00 AM, Martin Cooper wrote: > Okay. It was just an idea for how the community can add commentary to > our content without any of us having to do anything. The community > could still choose to use it, of course - it's more a question of > whether or not we promote it and take feedback from it. MySQL's documentation also has comments section. Likewise, I agree that SideWiki could supplant our documentation. I am for trying it if Apache will allow it. Do they have any policy against mash-ups that they can't control? > That said, though, if that's where your itch lies, you are of course > welcome to scratch it. :-) I would like to do both. Migrate to Confluence for S1 and make both S1/S2 use SideWiki. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving Struts 1 Doc to Confluence
Niall, You're against moving it? As in you don't like the idea or you would block it from moving forward? Paul On Sun, Dec 27, 2009 at 12:19 PM, Niall Pemberton wrote: > On Sat, Dec 26, 2009 at 6:51 AM, Paul Benedict wrote: >> I would like to move the Struts 1 documentation from SVN to >> Confluence. As old (10 years almost?!) as Struts 1 is, today it is not >> possible for any community member to update it without having SVN >> commit access. I think it's too high a bar. Does anyone have any >> technical objections to this? > > I'm -1 on this - not for technical reasons, but I don't see the point > when Struts 1 is effectively in maintenance mode (at best). Are there > really many people (even one?) that wants to contribute to Struts 1 > docs? > > Niall > >> Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
I recommend we immediately SVN tag or branch the initial check in so it can be refactored appropriately. Paul On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart wrote: > 2009/12/27 Martin Cooper : >> As many of you have no doubt noticed already, I've checked in the >> XWork code base, and added the Apache License 2.0 headers. The new >> XWork tree is here: > > Hurra!!! Thanks a lot! > > > Regards > -- > Lukasz > http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
Having XWork as a separate module is actually preferred, but only because it's a better design decision. It will create a clear separation of concerns within the code base. Now with that said, XWork should be a *child* module of Struts -- not a separate release. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Mon, Dec 28, 2009 at 1:37 PM, Wes Wannemacher wrote: > On Mon, Dec 28, 2009 at 2:16 PM, Paul Benedict wrote: >> Having XWork as a separate module is actually preferred, but only >> because it's a better design decision. It will create a clear >> separation of concerns within the code base. Now with that said, XWork >> should be a *child* module of Struts -- not a separate release. >> My fault for not being clear. I was intending to say XWork should be a "child module" (in the Maven sense) so it's actually part of Struts2 build and versioning process. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Happy New Year
Team, Hope your 2010 will be a great one. Nice work with all the improvements and releases this year. I hope we continue making Struts the best developed and supported framework in the world. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
