I believe that since in 2.1 the functionalities are cleanly separated into core and plugins for the first time, the next logical step is to have independant life cycles for them. This would give us the opportunity to assure core distribution quality better, as well as marking experimental/beta for what _is_ experimental or beta. With maven2 we have the tool to manage dependencies / requirements easily (man, I never believed I'm going to become a maven fellow ... :))
In another post Ted mentioned that this was tried in struts1 before, and it did not work. This was before the merger, so I don't know why that happened. I'm not sure if preconditions would be the same now, maybe it works better this time? If we start off with an independent lifecycle for non core plugins under the ASF/Struts umbrella and we see that it does not fit for one ore more of these plugins, we would still be free to move them out a google code plugin zoo project, which is a good idea at all to set up IMO. But in the first place, I personally would like to offer people the functionalities they might be using for years now (including those moving over from ww to struts2) from a single source. For the plugins itself: I believe that the spring plugin as well as the portlet plugin belong (close) to the core, since they are widely used and , afaik at least for the portlet plugin, actively maintained. Btw, what are the current issues with spring plugin, if there are? For the jasper, pell, plexus and jfreechart I don't see moving them out to some external project would give us. Do we have major open points for these plugins? IMO they should reside within the ASF part of the framework. Although dojo needs a lot of work, there seem to be lot of people out there to use functionalities we give them with dojo under the hood, mostly the widgets and the event systen integration. If people talk about broken, they often refer to the AJAX integration, but that's not all we (and many s2 users) use dojo for. On the other hand, to get momentum into the dojo development, a easy to entry community with many hands would help a lot. And 0.9 integration will be a point soon... So, why don't we fork off a 0.9 dojo plugin under the proposed struts external umbrella at google code or sourceforge? I think this would be a very attractive starting point with the potential to have many developers involved soon. The 0.4 dojo plugin would stay under the asf struts umbrella, ensuring people will find what they are known to find. Maybe we would want to strip it down to a more base functionality then. Maybe we should also put some thoughts into splitting up UI functionality integration from the pure AJAX functionalities integration, regarding dojo encapsulation through the struts framework. For the table tag plugin, and maybe even the JSF plugin, I believe that it is not that widely used till now and they might be also candidates to attract external developers by moving it out. Regards, Rene Ian Roughley schrieb: > > > Ted Husted wrote: >> I'm not sure that anyone is maintaining them now. I'm not sure that >> they all work. >> >> My thinking is that if they are kept at another location where there >> is a lower bar to entry, then perhaps we can attract someone to >> maintain them. >> > Or, the other option is that no one picks them up and then they are > outdated to the changes in the s2 code base. >> My concern is that some of the code in our distribution is not being >> used, or otherwise fully tested, by anyone in the group. When that is >> the case, then we should not be distributing the code. > This is my biggest concern. When I look at rails the biggest thing I > see is that every aspect of the core code works well, is integrated and > documented (or maybe I'm just lucky and this is all I've come across so > far). There is also a thriving plugin community, which is independent > from the core. > > Perhaps what is needed is a more understood labeling mechanism. So far > we have "experimental", but there are experimental features that are > documented and in excellent shape - so much so that I am using them in > production code. And there is other non-labeled code that I am very > cautious of using (XSLT results). > > For the plugins kept in s2, the other change I would like to see is > independent life cycles. If the code has not changed, I'm not sure why > its version needs to be incremented (other than staying with the s2 core > version). Would independent SVN repos help here? > > In retrospect, perhaps keeping the dojo plugin in s2 is the way to go > (the discussion that started this), but I still believe that an > independent life cycle is needed (someone just asked whether 2.0.x was > going to upgrade dojo from 0.4 to 0.9). >> We should >> archive it, and, perhaps, for added value, make it available at >> another location. >> >> -Ted. >> >> > > > > --------------------------------------------------------------------- > 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]
