Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Whether we do this now or not is debatable, in my mind, but the more I think about it, the more I think we'll need to do it, and just from a project management perspective, let alone a end user confusion one. Shale has components, Action 2 will have components, and certainly Action 1 has components. If the components need their own release cycle, then the alternative is to have a three-tier organization, but I think Apache wants to avoid that after Jakarta. I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day so the release and Apache import should happen tomorrow), and I'm seeing that Action 2 will have at least the following components: - Core (WebWork 2) - Apps - Legacy And probably more if we split up WebWork 2 further. WebWork 2 currently handles this by setting up Ivy configurations, but leaving the code in one tree. You do have the problem where an infrequently, non-core part of your project holds up releases, but again, unless we could do a three-tiered (Struts - Action 2 - Core, each having their own releases), that's what we'll have to do. Giving Apps its own subproject, with branches for Action 1, Action 2, and Shale is too complicated, I think. I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon, but we should resolve this before Action 2 gets out of Incubator. Don Ted Husted wrote: On 3/21/06, Wendy Smoak [EMAIL PROTECTED] wrote: And I didn't mean to discourage you -- in fact I offered to help. :) My comment was qualified with 'from a release manager perspective'. Obviously, it's easier to package and verify a release for a single jar than several of them plus example apps. If anyone really wanted to keep the separate sub-projects, I think they would have spoken up by now. Somehow I don't think you're going to get any opposition, and now that the proposal is on the table, I'd like to see a decision made one way or the other. I think the important thing is that we not halt any forward progress. If someone wants to move forward with another build of one or more of the Action 1 subprojects, then I would suggest staying the course and rolling the build. If no one is eager to start moving things about, I'd suggest an optimum time to recombine the subprojects would be after each had a GA release. At least then we would have something out the door, where more teams could use it. A GA release orf each would also demonstrate an ongoing need to move things about. But, again, AFAIC, whoever is ready to do the work is welcome to make the decision. -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]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
When you released 1.3.1, did you just roll Action or did you create a release for each module? If only action, does that mean the rest are still at 1.3.0? Frank's idea of a compatibility table, in my mind, shows how potentially ugly this can become. Still, if there was a group of Struts committers that only wanted to work on a single part of Action 1, say core and not taglibs, I can see us leaving things the way it is, however, we need to realize the huge price in end user complexity and confusion that costs. The burden of proof, so to speak, should be on separate releases, not consolidation. At this point, I just don't see a lot of new development done on Action 1 with Shale and Action 2 in the works. I could be wrong, of course. :) Wendy Smoak wrote: Looking at the list again, struts-tiles is missing. And I'm not sure how Faces is going to fit in there, it has a different set of dependencies than the others. That will all sort itself out when you start moving things around, though. :) For Faces and Tiles, I put forth the same test for a subproject: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) You know, there might be another option. We could have two subprojects: Action 1 core and Action 1 extras. This would allow Action releases to not require everyone to wait until Faces bugs are fixed, and with just one extension subproject, the dependency would be much easier to follow. However, this might have the some of the disadvantages of both, especially when a project like Tiles is more active than the others. Don -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On Mar 21, 2006, at 1:56 PM, Don Brown wrote: Wendy Smoak wrote: Looking at the list again, struts-tiles is missing. And I'm not sure how Faces is going to fit in there, it has a different set of dependencies than the others. That will all sort itself out when you start moving things around, though. :) For Faces and Tiles, I put forth the same test for a subproject: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I understood the Tiles omission to mean that you intended for it to remain a subproject. I would like for that to happen so it can be released independently from anything else. So I'm +1 on your original proposal and +1 on Tiles remaining a subproject. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/21/06, Don Brown [EMAIL PROTECTED] wrote: The burden of proof, so to speak, should be on separate releases, not consolidation. :) No one is arguing with you, Don. :) All anyone said is that we didn't take the separate releases idea far enough to prove anything one way or the other. If someone wants to spend their volunteer time going back to consolidated releases, so far everyone has said be our guest. In other words, You had us at hello. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
I guess it is good to summarize the possible options everyone has mentioned with regards to distributions: 1. Individual libraries with independent versioning. 2. Individual libraries with single versioning. 3. Action (action+taglib) and Extras libraries only, (independent versioning?). 4. Single monolothic (negative buzzword) library. I hope this is resolved before Action 2 because I'd like to use a production quality Struts 1.3 soon. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/21/06, Don Brown [EMAIL PROTECTED] wrote: Oh, sorry, I didn't mean to come across as confrontational as I'm still mulling it around in my own mind. Perhaps we should put off any major decision like this until Action 2 has been going for several weeks (svn cutover is tomorrow). Then, we may have a better idea of who will be working on it and who will still be actively developing Action 1. And I didn't mean to discourage you -- in fact I offered to help. :) My comment was qualified with 'from a release manager perspective'. Obviously, it's easier to package and verify a release for a single jar than several of them plus example apps. If anyone really wanted to keep the separate sub-projects, I think they would have spoken up by now. Somehow I don't think you're going to get any opposition, and now that the proposal is on the table, I'd like to see a decision made one way or the other. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/21/06, Wendy Smoak [EMAIL PROTECTED] wrote: And I didn't mean to discourage you -- in fact I offered to help. :) My comment was qualified with 'from a release manager perspective'. Obviously, it's easier to package and verify a release for a single jar than several of them plus example apps. If anyone really wanted to keep the separate sub-projects, I think they would have spoken up by now. Somehow I don't think you're going to get any opposition, and now that the proposal is on the table, I'd like to see a decision made one way or the other. I think the important thing is that we not halt any forward progress. If someone wants to move forward with another build of one or more of the Action 1 subprojects, then I would suggest staying the course and rolling the build. If no one is eager to start moving things about, I'd suggest an optimum time to recombine the subprojects would be after each had a GA release. At least then we would have something out the door, where more teams could use it. A GA release orf each would also demonstrate an ongoing need to move things about. But, again, AFAIC, whoever is ready to do the work is welcome to make the decision. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/19/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I can certainly buy into release consolidation along these four paths. That being said, separating the source artifacts (and the binary jar files that result from them) is still useful in terms of clearly articulating dependencies *within* a particular release. That becomes much more important as we offer finer grained jar files that are optional but impose their own external dependencies. Certainly correct me if I'm wrong, but wouldn't this proposal more or less do away with the idea of offering finer grained jar files? Except for Tiles, which I know is being spun off on its own (I presume so the same code base can support Struts, Shale and anything else?), are any of the other dwarfs in the same kind of boat as Tiles? It sounds from this proposal like they may not be?... For Shale, at least, I would *not* advocate eliminating separate JAR files. There are optional features of Shale that themselves have their own dependencies, and it would be a burden on all Shale users if everything was combined into one JAR file. As Ted mentioned earlier in some thread, this is a lesson that we in the Struts community can learn from what Spring is doing. Two use cases in the Shale world: * Shale Remoting -- a completely standalone JAR file that does not depend on anything else in Shale, but is useful for component authors and app developers doing AJAX style development. 40k and zero dependencies, versus 140k (for shale-core.jar) and a bunch of dependencies. * Tiger Extensions -- optional layer on top of Shale that utilizes JDK 1.5annotations to reduce or eliminate configuration files. Including this stuff in a core Shale JAR file would require *all* users to be based on JDK 1.5. In the Struts 1.x world, the same kind of argument applies to struts-el.jar(only needed if you are on a JSP 2.0 platform) and struts-faces.jar (only needed if you are using JSF components in a Struts based application). Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Certainly correct me if I'm wrong, but wouldn't this proposal more or less do away with the idea of offering finer grained jar files? I think the separate jars are still a good idea, so that developers can choose what they want to include in their applications. A recent thread on the WebWork user forum brought up a similar issue, and it sounds like WW is also going to be offering separate jars in addition to the single one with everything. Since the sub-projects are already separated, there's nothing to be gained from re-consolidating the code. Back to Don's original question, I don't think this change would be too difficult. The build doesn't know about the 'trunk' directories and if we were to just 'svn mv' it, should work as-is under 'action' the same as it now works under 'current'. Then we would just need to find something to make what in m2 terms is an 'assembly,' to contain whatever we're going to include in the release. It looks lke the next version of the m1 distribution plugin has 'dist:multiproject'. * http://maven.apache.org/maven-1.x/plugins/dist/goals.html It could also be done in maven.xml, but using a plugin would be better. Along the way it would be nice to make a few changes, such as dropping the svn:external 'build' directory and nudging things into a more consistent structure. I'm in favor of the proposal, but I probably won't be able to work on it for a while. I'll help, though, if someone else wants to get started. It might be a good idea to try it in the test repo (https://svn.apache.org/repos/test/) first. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Thanks Wendy, that's what I needed to hear. So far, I haven't heard any -1 type objections, so I'll take your advice and try the reorg on that other svn site. When I have it working correctly, I suppose I'll call for the vote. This would be a significant change, and honestly, I thought there'd be a lot more resistance :) Not that I'm complaining Don Wendy Smoak wrote: On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Certainly correct me if I'm wrong, but wouldn't this proposal more or less do away with the idea of offering finer grained jar files? I think the separate jars are still a good idea, so that developers can choose what they want to include in their applications. A recent thread on the WebWork user forum brought up a similar issue, and it sounds like WW is also going to be offering separate jars in addition to the single one with everything. Since the sub-projects are already separated, there's nothing to be gained from re-consolidating the code. Back to Don's original question, I don't think this change would be too difficult. The build doesn't know about the 'trunk' directories and if we were to just 'svn mv' it, should work as-is under 'action' the same as it now works under 'current'. Then we would just need to find something to make what in m2 terms is an 'assembly,' to contain whatever we're going to include in the release. It looks lke the next version of the m1 distribution plugin has 'dist:multiproject'. * http://maven.apache.org/maven-1.x/plugins/dist/goals.html It could also be done in maven.xml, but using a plugin would be better. Along the way it would be nice to make a few changes, such as dropping the svn:external 'build' directory and nudging things into a more consistent structure. I'm in favor of the proposal, but I probably won't be able to work on it for a while. I'll help, though, if someone else wants to get started. It might be a good idea to try it in the test repo (https://svn.apache.org/repos/test/) first. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Craig McClanahan wrote: In the Struts 1.x world, the same kind of argument applies to struts-el.jar(only needed if you are on a JSP 2.0 platform) and struts-faces.jar (only needed if you are using JSF components in a Struts based application). +1 As I mentioned, I'm proposing each extension still have its own directory structure, build, and artifact, but just be moved up under action/trunk instead of the root. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Craig McClanahan wrote: On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: You know, I was looking at the Struts front page a few minutes ago, specifically the Extensions, which are the seven dwarfs IIRC. The one that sticks out for me as a problem, if that's the right word, is the JSP Taglib. I suspect that Struts users who abhor JSP, but like things like Velocity, would not agree with you :-). Hehe, probably right :) Indeed, if you're using Struts as the server end of AJAX transactions, you don't need this library even if you do happen to use JSP for the human user interface portion of your application (perhaps using a different framework). I think it's fair to say that the majority of Struts developers consider the Struts tags to be intrinsically part of the Struts Action Framework (SAF). Except for me who rarely uses them! :) The analogy I would use us the component kit you use in a JSF app... *can* you build a JSF app with no component kit at all? You bet you can. Do you have any feel for how common it is though? My guess is that it isn't very common, but your certainly in a better position to tell then I am. It just doesn't *feel* like something I would expect to find to be common, just like not using the Struts taglibs probably isn't the most common usage pattern. Come to think of it ... there's even a 40kb standalone jar file ( shale-remoting.jar) that does exactly this kind of thing, with no dependencies on the UI components part of JSF, or even on the rest of Shale :-). Cute :-) Craig Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: You know, I was looking at the Struts front page a few minutes ago, specifically the Extensions, which are the seven dwarfs IIRC. The one that sticks out for me as a problem, if that's the right word, is the JSP Taglib. I suspect that Struts users who abhor JSP, but like things like Velocity, would not agree with you :-). Hehe, probably right :) Indeed, if you're using Struts as the server end of AJAX transactions, you don't need this library even if you do happen to use JSP for the human user interface portion of your application (perhaps using a different framework). I think it's fair to say that the majority of Struts developers consider the Struts tags to be intrinsically part of the Struts Action Framework (SAF). Except for me who rarely uses them! :) The analogy I would use us the component kit you use in a JSF app... *can* you build a JSF app with no component kit at all? You bet you can. Do you have any feel for how common it is though? My guess is that it isn't very common, but your certainly in a better position to tell then I am. It just doesn't *feel* like something I would expect to find to be common, just like not using the Struts taglibs probably isn't the most common usage pattern. Common now? Probably ot very ... especially if you point someone at the current website documentaton for this feature[1] :-). You need to peruse the Javadocs, and ask questions on the list, to get very far right at the moment. And, most people who evaluate JSF never seem to look at the underlying infrastructure ... they get obsessed with the components and either like or dislike it on that basis. Common in the future? That's the plan ... it's especially designed for folks who want to create the server side of AJAX interactions, plus people who want to write AJAX-enabled components. The power of expression evaluation, plus the basic dependency injection capabilities of managed beans, are just too much goodness to pass up. JSF's fundamental front controller architecture is plenty of power for this sort of use case. With Shale Remoting, you can plug in (out of the box) a call to any arbitrary method (it maps based on the request URL), or to any Commons Chain command or chain implementation. Adding support to map to an XWork (the underlying framework that WebWork is based on) interceptor chain is on my list of things to add, but it's going to be really easy. Also, something to think about for the future ... in JSF 1.2 and JSP 2.1, the expression language APIs and implementation got factored into their own spec document, which *might* ultimately be a candidate for inclusion in the JDK. It turns out that a common expression evaluation library is pretty handy in simplifying quite a few use cases. For example, anything that Commons BeanUtils can do is *much* more elegantly handled with EL expressions and a few appropriate complementary classes (like converters). We (Sun) are using this library in the next version of the demo AJAX components that you can get with Java Studio Creator 2 [2]. Doing so cut the number of lines of code per component down dramatically (besides the fact that the original approach didn't take advantage of browser caching, required you to use /faces/* mapping, yadda yadda). More importantly, it got rid of the approach that was used in the initial prototyping of these components (a separate PhaseListener per component for serving up static resources and responding to AJAX requests), which is not a particularly scalable design :-). Come to think of it ... there's even a 40kb standalone jar file ( shale-remoting.jar) that does exactly this kind of thing, with no dependencies on the UI components part of JSF, or even on the rest of Shale :-). Cute :-) Craig Frank Craig [1] http://struts.apache.org/struts-shale/features-remoting.html [2] http://developers.sun.com/jscreator/
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Craig McClanahan wrote: For Shale, at least, I would *not* advocate eliminating separate JAR files. There are optional features of Shale that themselves have their own dependencies, and it would be a burden on all Shale users if everything was combined into one JAR file. As Ted mentioned earlier in some thread, this is a lesson that we in the Struts community can learn from what Spring is doing. Two use cases in the Shale world: * Shale Remoting -- a completely standalone JAR file that does not depend on anything else in Shale, but is useful for component authors and app developers doing AJAX style development. 40k and zero dependencies, versus 140k (for shale-core.jar) and a bunch of dependencies. * Tiger Extensions -- optional layer on top of Shale that utilizes JDK 1.5annotations to reduce or eliminate configuration files. Including this stuff in a core Shale JAR file would require *all* users to be based on JDK 1.5. In the Struts 1.x world, the same kind of argument applies to struts-el.jar(only needed if you are on a JSP 2.0 platform) and struts-faces.jar (only needed if you are using JSF components in a Struts based application). That all makes perfect sense, thanks Craig. You know, I was looking at the Struts front page a few minutes ago, specifically the Extensions, which are the seven dwarfs IIRC. The one that sticks out for me as a problem, if that's the right word, is the JSP Taglib. there have been VelocityStruts users eager for the Struts tags to be separated from the core for a long time. there's plenty of people using Struts without the tags. I think it's fair to say that the majority of Struts developers consider the Struts tags to be intrinsically part of the Struts Action Framework (SAF). Except for me who rarely uses them! :) The analogy I would use us the component kit you use in a JSF app... *can* you build a JSF app with no component kit at all? I would guess yes... but how many people *would* ever do that? I would guess very few. I think the same is true of the Struts tags. I think everything else, Tiles, Flow, EL, etc., really do seem to me to be true extensions, and as such it makes sense for them to develop on their own, be packaged on their own, and be downloaded separately as needed. My only concern there is simply to document well what version(s) of a given extension can be used with a given version of SAF. I think this information should always be front and center and easy to find quickly. But, the JSP Taglib, that one I think really does make more sense to go along with the core itself. I'm not saying it can't be its own JAR... that's just a matter of the final build artifact. I'd probably opt to include it in the Struts JAR, but that's really a minor point IMO. What is more important is that I think the taglib should share the same version number, release cycle, etc., as the core, and in fact should just simply BE part of the core. I guess I'm saying I would propose amending Don's proposal to only apply to the Struts taglibs :) Craig Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Craig McClanahan wrote: Common in the future? That's the plan ... it's especially designed for folks who want to create the server side of AJAX interactions, plus people who want to write AJAX-enabled components. The power of expression evaluation, plus the basic dependency injection capabilities of managed beans, are just too much goodness to pass up. Obviously going OT for this thread, so I'd be happy to start a new one if you want, but this is very interesting to me as a pretty big AJAX booster.. Have you ever looked at DWR? I wonder what your impression is of that? Especially since it has Spring integration, which I'm sure you would agree if better dependency injection than the basic capabilities JSF provides, and since it works with *any* framework, and allows you to access POJOs, I would personally favor that than start using a whole new framework. What benefits would you say there are to using Shale/JSF than that with any other framework over a DWR-based solution? Certainly you can fire off a chain in any case if that's your need, so I don't see that as being one. Again, just curious here as an AJAX guy. I guess what I'm *really* getting at is to ask doesn't AJAX make much of this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat irrelevant? Might it even be better to just develop the Shale remoting as a separate AJAX library? Not trying to pick fight :-) Craig Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Nathan Bubna wrote: there have been VelocityStruts users eager for the Struts tags to be separated from the core for a long time. there's plenty of people using Struts without the tags. I didn't know that, thanks for pointing it out. Do the tags being there hinder those users in any way though? Assuming not, and assuming my belief that more Struts developers *DO* use the tags than don't (which may not be true!) then I'm not sure it matters, and I would still suggest the tags should be part of the core. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Craig McClanahan wrote: Common in the future? That's the plan ... it's especially designed for folks who want to create the server side of AJAX interactions, plus people who want to write AJAX-enabled components. The power of expression evaluation, plus the basic dependency injection capabilities of managed beans, are just too much goodness to pass up. Obviously going OT for this thread, so I'd be happy to start a new one if you want, but this is very interesting to me as a pretty big AJAX booster.. Have you ever looked at DWR? I wonder what your impression is of that? Especially since it has Spring integration, which I'm sure you would agree if better dependency injection than the basic capabilities JSF provides, and since it works with *any* framework, and allows you to access POJOs, I would personally favor that than start using a whole new framework. What benefits would you say there are to using Shale/JSF than that with any other framework over a DWR-based solution? Certainly you can fire off a chain in any case if that's your need, so I don't see that as being one. Again, just curious here as an AJAX guy. I've looked at DWR some, but the guys here that did the initial research on AJAX frameworks liked DOJO better. Doesn't mean DWR is in any way bad, mind you ... just that we chose differently. I guess what I'm *really* getting at is to ask doesn't AJAX make much of this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat irrelevant? Might it even be better to just develop the Shale remoting as a separate AJAX library? Not trying to pick fight :-) Not swinging back either :-). At a 30,000 foot level, there are three basic architectures for usng AJAX (and yes, they overlap a bunch too): * Eye Candy -- add a little bit of asynch interactivity to an existing application, often done by utilizing existing JavaScript event handlers on the relevant HTML tags directly (perhaps with the help of a client side JS library, perhaps with just hand coded cut-n-paste JS that you saw on some website). * Server Side UI -- the UI of an app fundamentally based on widgets with asynchronous callbacks, but it's still rendered on the server side as is typical of webapps today ... except that the JavaScript/DHTML madness is encapsulated in some sort of API (custom tags, JSF components, PHP objects, whatever) that hides the complexity from the developer. * Client Side Controller -- the app itself moves to the client side, and asynch callbacks are strictly for exchanging model tier data. JSF UI components (as well as the framework) work great for the first two cases. The UI components are of less use in the third case (although in an ideal scenario the client side widgets you encapsulated with JSF components for the first two cases is the same code you use directly for the third case), but the framework part is still fully capable of doing what you need to map incoming requests to particular business logic, and helping you format the response. Shale Remoting is still very useful in the third case (as well as being a nice utility library for those building JSF components to handle the first two cases). By the way, I agree with you that Spring's dependency injection is more powerful than that provided by JSF managed beans. Wouldn't it be cool if you could use both Spring and JSF together, but configure your JSF managed beans in Spring just like you do your business logic beans? Oh yah ... that's already possible :-). Spring includes integration with JSF's expression evaluation facilities, so you can use Spring-created beans in your JSF value binding and method binding expressions, without the expression user (UI component, Shale Remoting mapping of an AJAX request, whatever) having to know that. And that one doesn't even take Shale ... basic support for this comes out of the box with Spring, and there's an extension library at SourceForge if you want to get a little fancier (i.e. put Spring-managed beans into request/session/application scope automatically, not just create singletons and per-request instances). Craig Frank Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Nathan Bubna wrote: there have been VelocityStruts users eager for the Struts tags to be separated from the core for a long time. there's plenty of people using Struts without the tags. I didn't know that, thanks for pointing it out. Do the tags being there hinder those users in any way though? Assuming not, and assuming my belief that more Struts developers *DO* use the tags than don't (which may not be true!) then I'm not sure it matters, and I would still suggest the tags should be part of the core. Not directly. But in so far as extras can hinder releases and sap development effort from the core, they do hinder the users. In general, one of the reasons i liked seeing the Struts extras pulled out of the core was the hope that bugs and slow development in such non-essential parts of Struts would no longer be a hinderance to fresh Struts core releases. It's a tough trade-off though, i admit. Either risk dependency confusion and frustration or else risk having good code be held back by extras that only a portion of the userbase is interested in. Personally, i prefer a little extra dependency complexity (and that preference even predates the usefulness of Maven and Ivy for such things) to the stifling of release frequency and freedom. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
I do see benefit in having the struts-taglibs (and actions) being their own release because there are some very minor enhancements that don't really require a new action framework release. For instance, Struts 1.2.5 added the errorStyle and errorStyleClass attributes, which probably could have been released faster if they were separate. This is the same situation for the struts-actions library which doesn't need a framework upgrade to add new functionality. However, the biggest downside of separate releases, as I see it, will be the confusion in the separate versioning of the libraries. Someone might be asking one day, Does taglibs-1.3.11 go with struts-action-1.3.4 or struts-action-1.3.6? It is really going to be difficult to eyeball which version library depends on which version library of another. Did I get this wrong? Isn't this how the independent libraies will be released at different schedules? If so, an alternative would be to re-tag all libraries and release them under one distribution version. If struts-taglibs go through 5 quick releases, that's also 5 quick releases of Struts too. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Paul Benedict [EMAIL PROTECTED] wrote: I do see benefit in having the struts-taglibs (and actions) being their own release because there are some very minor enhancements that don't really require a new action framework release. For instance, Struts 1.2.5 added the errorStyle and errorStyleClass attributes, which probably could have been released faster if they were separate. This is the same situation for the struts-actions library which doesn't need a framework upgrade to add new functionality. However, the biggest downside of separate releases, as I see it, will be the confusion in the separate versioning of the libraries. Someone might be asking one day, Does taglibs-1.3.11 go with struts-action-1.3.4 or struts-action-1.3.6? It is really going to be difficult to eyeball which version library depends on which version library of another. Did I get this wrong? Isn't this how the independent libraies will be released at different schedules? compatibility is not that difficult to maintain in reality. for project developers there are just 3 simple rules to follow: - no point release (1.3.1 to 1.3.2) should ever break a working, outward facing API - all minor versions (1.3.x to 1.4.x) should deprecate working, outward facing APIs before removing (release foo in 1.3.x, deprecate in 1.4.x, and remove no sooner than 1.5.x, if at all). - all major versions (1.x.x to 2.x.x) are free to break or change whatever they wish. assuming developers respect these well-established patterns, then users worried about compatibility and dependencies and unwilling to track all project changes, there are only three simple rules: - point release versions that go GA are always safe to upgrade - watch for deprecations when upgrading minor version numbers - expect things to break with a major version upgrade and all of that can be done without any documentation apart from the version numbers themselves. throw in notice of deprecations in changelogs, and simple instructions about the latest versions (struts-taglibs 1.6.x depends on struts-action-core 1.4.x) and what's the big deal? also, by separating out the various extra components, you make the development and maintenance of entirely new components (e.g. VelocityStruts) easier, because some former internal APIs are now the external APIs of the core compenents. since those are now outward facing, compatibility and stability of the core is more rigorously maintained. so for those not under the Struts umbrella, life becomes better. :) If so, an alternative would be to re-tag all libraries and release them under one distribution version. If struts-taglibs go through 5 quick releases, that's also 5 quick releases of Struts too. heh. who ever heard of a quick Struts release? now you're just talking nonsense. ;-) but seriously, this is totally unrealistic. the different projects will overlap in their various states of readiness/buginess and the next GA release of any of it must wait until all of it is ready. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Nathan Bubna [EMAIL PROTECTED] wrote: compatibility is not that difficult to maintain in reality. for project developers there are just 3 simple rules to follow: - no point release (1.3.1 to 1.3.2) should ever break a working, outward facing API - all minor versions (1.3.x to 1.4.x) should deprecate working, outward facing APIs before removing (release foo in 1.3.x, deprecate in 1.4.x, and remove no sooner than 1.5.x, if at all). - all major versions (1.x.x to 2.x.x) are free to break or change whatever they wish. assuming developers respect these well-established patterns, then users worried about compatibility and dependencies and unwilling to track all project changes, there are only three simple rules: - point release versions that go GA are always safe to upgrade - watch for deprecations when upgrading minor version numbers - expect things to break with a major version upgrade One of the problems is when a point release change in one package relies on a specific point release change in another package. If struts-action-1.3.2 adds some new functionality, and struts-taglib-1.3.1 uses this new functionality, a user who is using struts-action-1.3.1 can't just plug in struts-taglib-1.3.1 without upgrading the action jar as well. Throw in several jars each with several versions each, and a user wanting to upgrade just enough to get one specific feature, but not to all the newest jars, and you can understand where the confusion can come from. Hubert Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Nathan Bubna wrote: heh. who ever heard of a quick Struts release? now you're just talking nonsense. ;-) but seriously, this is totally unrealistic. the different projects will overlap in their various states of readiness/buginess and the next GA release of any of it must wait until all of it is ready. But this hinges on each project having different committed developers, actively developing their code. My original point is that the committers that are working on action are the same as EL, taglibs, extras, and plugins. Even then, those projects are more or less in maintenance mode, save perhaps Action 1, which is still being worked on. The situation you describe is what prompted the splitting of subprojects originally. However, after almost two years of subprojects and the looming addition of Action 2 later, I think we are seeing based on previous activity that the new subprojects didn't facilitate easier releases and more activity, but rather complicated our build and release processes. In the end, if you can do the same thing but with less work and complexity, then do it. I think consolidating Action 1 subprojects, which have no life outside Action 1, is the right step to evolve our code and project structure to better fit the community and those willing to maintain it. Don Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Don Brown [EMAIL PROTECTED] wrote: I think we are seeing based on previous activity that the new subprojects didn't facilitate easier releases and more activity, but rather complicated our build and release processes. I don't have a problem with anything anyone wants to do here, but I don't think we've had the opportunity to see anything yet. The only 1.3.x release anyone has actually tried to make so far was all seven together, so it was no different that the type of release we did for 1.1 and 1.2 -- and it took forever. Not because there were subproject releases, but because for the initial 1.3.0 builds, everything in all seven had to be just right before anything was tagged. Same old, same old. Case in point: All but 1 subproject was ready to go in November, but we held the other 6 subprojects for three months waiting for a dependency to mature that affected only one of the subprojects. That said, I'm happy to let them that is going to do the work make the decision. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Throw in several jars each with several versions each, and a user wanting to upgrade just enough to get one specific feature, but not to all the newest jars, and you can understand where the confusion can come from. Agreed. How does anyone feel about this philosophy, which I see can solve this problem: On any GA release of a subproject, the version number of Struts is incremented, and all the jars are upgraded to the next version number? The biggest benefit is that a struts-1.3.5.zip would contain all jars labeled 1.3.5. Granted, most of these subproject upgrades would be benign because nothing would change, but there will never be confusion about the versioning. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Paul Benedict wrote: Agreed. How does anyone feel about this philosophy, which I see can solve this problem: On any GA release of a subproject, the version number of Struts is incremented, and all the jars are upgraded to the next version number? The biggest benefit is that a struts-1.3.5.zip would contain all jars labeled 1.3.5. Granted, most of these subproject upgrades would be benign because nothing would change, but there will never be confusion about the versioning. I can't really say I like the idea... you could envision a situation where one subproject has a number of releases in a relatively short time, so all of sudden there's X new versions of Struts that people have to figure out it they need or want or not. Your goal of wanting to remove questions about version compatibility is worthy though, I'm just not sure this is the best way to do it. I actually think this can be dealt with using nothing more than good documentation. Something simple like a table along these lines: If you use: Action 1.2.7 Then you can use: EL- 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7 Flow- 1.2.9, 1.3.0 If you use: Action 1.3.0 Then you can use: EL- 1.2.5, 1.2.6, 1.2.7 Flow- 1.3.0 ...and so on... And also for each subproject: If you want to use: EL- 1.2.3 You can use: Action- 1.2.7, 1.2.8, 1.3.0 If you want to use: EL- 1.2.4 You can use: Action- 1.2.8, 1.3.0 ...and so on... Probably a better way to lay it out, but you get the idea, and I think that would do the trick. The person can grab whatever version of a given extension they want, after researching the versions to see what they provide, or they can just grab the highest compatible version. I think the key though is that it should be driven off the core Action version. However, it is important to have a reverse-lookup, in effect, so that if you need a specific feature in a specific extension version, you can at a glance see what version of Action it will work with. Paul Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Don Brown [EMAIL PROTECTED] wrote: Thanks Wendy, that's what I needed to hear. So far, I haven't heard any -1 type objections, so I'll take your advice and try the reorg on that other svn site. When I have it working correctly, I suppose I'll call for the vote. This would be a significant change, and honestly, I thought there'd be a lot more resistance :) Not that I'm complaining From me? As long as I get my fancy Maven build, I'm happy. ;) I'm in favor of grouping the Action-related modules in the repository. From a release manager perspective, (now that I have one,) I'm less thrilled about the consolidated release, but that only means I'm less likely to volunteer to do it. Struts Action 1.3.1 was simple to put together, while Shale 1.0.1 was _not_. Being able to concentrate on a single jar, a single set of docs, etc., better fits into the blocks of time that I can devote to this. I don't think the separate releases ever got a chance to prove themselves, but if more people (who are going to do the work) want the consolidated release, it's fine with me. Looking at the list again, struts-tiles is missing. And I'm not sure how Faces is going to fit in there, it has a different set of dependencies than the others. That will all sort itself out when you start moving things around, though. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Frank, Thanks for the response, but I find that idea more creative and less clear. I don't know if there is a good answer here. I suppose another solution would be to say if you're in 1.3, all 1.3 libraries are compatible; any feature that requires more than one dependency to upgrade in tandem, must wait until 1.4 Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: On Fri, March 17, 2006 1:48 pm, Don Brown said: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. Just to see if I understand... There would be a single Action entity, that contains all of these? If you download Action you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity Action as opposed to Struts. Is that correct? If so, definite +1 from me. Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1 jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the version number of each component matching up. think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. The subproject split was way before the WW merger, and IIRC, I was the one that did the original SVN moving arounds at ApacheCon two years ago. The emergence of Action 2 changes things completely, and IMO, the reasons we split as we did aren't valid anymore. I don't see it as much as a reversal, but a new evolution. We are still keeping many of the same subprojects, just consolidating the Action 1-specific ones ahead of the Action 2 start. I'm not sure that action2 changes things completely, but it does introduce a separate development path that needs to be accounted for. I think that leaves us with four main development domains (or whatever term you like that implies grouping but does not imply hierarchy :-): * Struts 1.x -- ongoing maintenance support of the 1.3 codebase (our users will string us up from the yardarms if this is not a first class notion in our minds) * WebWork 2.x -- same thing for existing WW users (although this might legitimately stay at OpenSymphony?) * Struts 2.x -- the endgame for the merger efforts * Shale -- All the stuff around Shale (which, like Struts 1.x, is segregated in terms of source repository directory structure but has not actually been released in fine grained units (yet)). I can certainly buy into release consolidation along these four paths. That being said, separating the source artifacts (and the binary jar files that result from them) is still useful in terms of clearly articulating dependencies *within* a particular release. That becomes much more important as we offer finer grained jar files that are optional but impose their own external dependencies. Don Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Craig McClanahan wrote: I can certainly buy into release consolidation along these four paths. That being said, separating the source artifacts (and the binary jar files that result from them) is still useful in terms of clearly articulating dependencies *within* a particular release. That becomes much more important as we offer finer grained jar files that are optional but impose their own external dependencies. Certainly correct me if I'm wrong, but wouldn't this proposal more or less do away with the idea of offering finer grained jar files? Except for Tiles, which I know is being spun off on its own (I presume so the same code base can support Struts, Shale and anything else?), are any of the other dwarfs in the same kind of boat as Tiles? It sounds from this proposal like they may not be?... Don Craig Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib What is the difference between el and taglib besides el support? Would not it be more logical to have action/trunk/taglib and action/trunk/taglib-el ? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On Fri, March 17, 2006 1:48 pm, Don Brown said: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. Just to see if I understand... There would be a single Action entity, that contains all of these? If you download Action you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity Action as opposed to Struts. Is that correct? If so, definite +1 from me. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. If I'm understanding your proposal, it would be a course change, but I think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. I think this proposal would eliminate a lot of potential confusion with version dependencies, which I think is clearly a good thing. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. I wouldn't consider it a step backward actually... an idea was proposed... it was implemented... there is now some thought that maybe it didn't work out quite as hoped... now a decision is made to do something different which just happens to be what was done before the decision. This is just good, flexible, thoughtful decision-making and leadership. I can only speak as a member of the developer community... I thought the separate release cycles, while not without merit, had the potential to be confusing and make things more difficult on developers, and maybe too the committers. Therefore, I would support this proposal, just as an interested third-party. Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
If we're going to consolidate, why not go whole hog and have a single artifact? I agree that past experience and the future of action2 suggest that there's not going to be a lot of activity in various subprojects independent of an individual release. Joe At 10:48 AM -0800 3/17/06, Don Brown wrote: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Michael Jouravlev wrote: On 3/17/06, Don Brown [EMAIL PROTECTED] wrote: The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib What is the difference between el and taglib besides el support? Would not it be more logical to have action/trunk/taglib and action/trunk/taglib-el ? Well, yes, I suppose that name would be more accurate, and we could switch if this proposal was accepted. Don Michael. - 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] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Joe Germuska wrote: If we're going to consolidate, why not go whole hog and have a single artifact? I still see value in the extensions having their own artifacts. For one, it makes it easier to grok for new folks, and in cases like taglib and el, they can't be merged. I see it working similarly to how Spring manages its components. Don I agree that past experience and the future of action2 suggest that there's not going to be a lot of activity in various subprojects independent of an individual release. Joe At 10:48 AM -0800 3/17/06, Don Brown wrote: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Frank W. Zammetti wrote: On Fri, March 17, 2006 1:48 pm, Don Brown said: I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle. Just to see if I understand... There would be a single Action entity, that contains all of these? If you download Action you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity Action as opposed to Struts. Is that correct? If so, definite +1 from me. Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1 jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the version number of each component matching up. think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. The subproject split was way before the WW merger, and IIRC, I was the one that did the original SVN moving arounds at ApacheCon two years ago. The emergence of Action 2 changes things completely, and IMO, the reasons we split as we did aren't valid anymore. I don't see it as much as a reversal, but a new evolution. We are still keeping many of the same subprojects, just consolidating the Action 1-specific ones ahead of the Action 2 start. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Don Brown wrote: Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1 jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the version number of each component matching up. Great! Yes, I think just simply not having to worry about the versions is worth it. Don Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
