RE: CVS reorg: jakarta-struts - struts
At 9:03 AM -0700 7/15/04, Martin Cooper wrote: On Tue, 13 Jul 2004, Ted Husted wrote: On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote: As long as it's easy for me to check out the entire gorilla if that's what I want. ;-) But of course :) That sounds nice in theory, but there are going to be cases where we'll need to share code between different 'opt's, and it's not clear (to me, at least) where that fits. For example, where would we put the methods that are currently in RequestUtils but that are tied to JSP? I would be very much opposed to JSP specific code being in core, but I'm not sure where else it would go. Would we need an opt-jsp just for that, that the other 'opt's depend on? For now, they would have to stay in the core. Later, we can try and refactor them out. My concern is that if we don't think about this kind of thing up front, we're going to find ourselves in a bind when we do try to split these things out. I like the theory of not introducing a taxonomy, as you put it, but I don't see that it's really avoidable - or even desirable, in some cases. For example, if the core is independent of servlets, portlets, JSP, etc., then we need somewhere to put shared servlet code, shared JSP code, etc. A hierarchy seems like a pretty good way of partitioning this. So, we might have a JSP tree that has some shared or common JSP specific code, along with the JSP specific 'opt's like -taglibs, -el, et al. Without something like this, I can't help thinking we'll end up with a bazillion top level 'opt's with nothing other than (hopefully) clear documentation (which people never read ;) to tell people what depends on what. To put all that another way - if we have the structure you propose, where do you anticipate that we would put JSP specific code that is shared among opt-taglibs, opt-el and opt-faces? I think we need to have an answer to that question, at least, before we can know how well the structure will work. For the foreseeable future, I would expect opt-el to *depend on* opt-taglibs. I don't know what opt-faces would share, but if there's that dependency relationship, then there may be no need to have another lib-jsp artifact. Grepping imports in the struts-faces taglib package, I find these Struts imports: org.apache.struts.Globals; org.apache.struts.config.ModuleConfig; org.apache.struts.util.MessageResources; org.apache.struts.util.RequestUtils; org.apache.struts.validator.Resources; org.apache.struts.validator.ValidatorPlugIn; no dependency on other Struts JSP centric stuff. The RequestUtils calls all do accept pageContext as an argument: ModuleConfig config = RequestUtils.getModuleConfig(pageContext); Locale locale = RequestUtils.retrieveUserLocale(this.pageContext, null); return RequestUtils.isXhtml(this.pageContext); I kind of thought all of that stuff would have been moved to TagUtils, but if it hasn't and won't be, then there's no concern of the type that Martin suggests. If there is no current concern, I wouldn't want to get stuck planning for this one might-be. However, if we needed it, I guess I'd propose a general lib-* naming convention for libraries which are pieces of the puzzle. So in this case, we might have struts/lib-jsp/ /src /project.xml etc I'd be fine with them being at the top. But I'd rather not create them until they have substance. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
RE: CVS reorg: jakarta-struts - struts
On Thu, 15 Jul 2004, Joe Germuska wrote: At 9:03 AM -0700 7/15/04, Martin Cooper wrote: On Tue, 13 Jul 2004, Ted Husted wrote: On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote: As long as it's easy for me to check out the entire gorilla if that's what I want. ;-) But of course :) That sounds nice in theory, but there are going to be cases where we'll need to share code between different 'opt's, and it's not clear (to me, at least) where that fits. For example, where would we put the methods that are currently in RequestUtils but that are tied to JSP? I would be very much opposed to JSP specific code being in core, but I'm not sure where else it would go. Would we need an opt-jsp just for that, that the other 'opt's depend on? For now, they would have to stay in the core. Later, we can try and refactor them out. My concern is that if we don't think about this kind of thing up front, we're going to find ourselves in a bind when we do try to split these things out. I like the theory of not introducing a taxonomy, as you put it, but I don't see that it's really avoidable - or even desirable, in some cases. For example, if the core is independent of servlets, portlets, JSP, etc., then we need somewhere to put shared servlet code, shared JSP code, etc. A hierarchy seems like a pretty good way of partitioning this. So, we might have a JSP tree that has some shared or common JSP specific code, along with the JSP specific 'opt's like -taglibs, -el, et al. Without something like this, I can't help thinking we'll end up with a bazillion top level 'opt's with nothing other than (hopefully) clear documentation (which people never read ;) to tell people what depends on what. To put all that another way - if we have the structure you propose, where do you anticipate that we would put JSP specific code that is shared among opt-taglibs, opt-el and opt-faces? I think we need to have an answer to that question, at least, before we can know how well the structure will work. For the foreseeable future, I would expect opt-el to *depend on* opt-taglibs. I don't know what opt-faces would share, but if there's that dependency relationship, then there may be no need to have another lib-jsp artifact. It makes sense for opt-el to depend on opt-taglibs. It doesn't necessarily make sense for other taglibs that people might write to have to depend on that same package, though, especially if the only reason they depend on it is for a class like TagUtils, and the tags themselves have no relation to our opt-taglibs tags. As far as I can tell, the only other classes that have JSP dependencies (that are not part of taglibs) are RequestUtils and ResponseUtils, as well as several Tiles classes. I would like to see a clean separation of the JSP specific code, and something like lib-jsp, as you suggest below, would be one way of doing this. However, it seems at this point as if I'm the only one arguing for such a clean separation. It just seems to me that if we ever want to get to a clean separation of dependencies, now is the time to do that, not later, when people start building on top of the new code organisation, and we're locked into it ourselves. -- Martin Cooper Grepping imports in the struts-faces taglib package, I find these Struts imports: org.apache.struts.Globals; org.apache.struts.config.ModuleConfig; org.apache.struts.util.MessageResources; org.apache.struts.util.RequestUtils; org.apache.struts.validator.Resources; org.apache.struts.validator.ValidatorPlugIn; no dependency on other Struts JSP centric stuff. The RequestUtils calls all do accept pageContext as an argument: ModuleConfig config = RequestUtils.getModuleConfig(pageContext); Locale locale = RequestUtils.retrieveUserLocale(this.pageContext, null); return RequestUtils.isXhtml(this.pageContext); I kind of thought all of that stuff would have been moved to TagUtils, but if it hasn't and won't be, then there's no concern of the type that Martin suggests. If there is no current concern, I wouldn't want to get stuck planning for this one might-be. However, if we needed it, I guess I'd propose a general lib-* naming convention for libraries which are pieces of the puzzle. So in this case, we might have struts/lib-jsp/ /src /project.xml etc I'd be fine with them being at the top. But I'd rather not create them until they have substance. Joe -- Joe Germuska[EMAIL PROTECTED] http://blog.germuska.comIn fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS reorg: jakarta-struts - struts
On Tue, 13 Jul 2004 07:48:37 -0700, Martin Cooper wrote: That would be excellent, Ted. That would let us all learn SVN as well as play around with ideas without fear of messing things up too badly. ;-) If I could have found the time, I'd been thinking I wanted to do something like this too, except that I don't have any externally visible hardware. ;-( Minor holdup (mea culpa). I expect the CVS will be imported sometime today, and I'll setup accounts for the active Committers. I'll also set these people up to get SVN changelog mailings (unless you opt out). Since this will be a temporary, test, stomp-around repository, I don't know if want to announce the URI here, or just make it available to people on an individual want to know basis. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS reorg: jakarta-struts - struts
+1 for svn -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 4:57 PM To: Struts Developers List Subject: Re: CVS reorg: jakarta-struts - struts On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote: * Did we end up deciding to stick with CVS versus Subversion? I know the infrastructure team would be happier if we switched to svn ... I haven't played with it enough to form an opinion on that yet. I would be +1 for Subversion. I could also host a SVN repository for us, temporarily. -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: CVS reorg: jakarta-struts - struts
Hi, Yes, you can have a struts/site with site documentation that can include all modules documentation (and is the recommended way) About extending projects you shouldn't extend the concrete projects (e.g. struts core), it's better to create convenience project.xml files (e.g. in struts/maven) BTW the Maven 1.0 will be released by this week, it has already been voted in the PMC Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 12:45 AM To: Struts Developers List Subject: Re: CVS reorg: jakarta-struts - struts At 2:43 PM -0700 7/12/04, Martin Cooper wrote: I'm not completely sure I understand what you're proposing, but here are a couple of points to bear in mind: I may not understand it either. But I decided I'd like to see it move forward. So... Regarding CVS vs. SVN. I have zero SVN experience. I'm not opposed to it, but it will be slower for me personally if we go that route, as I'm starting at the bottom of the learning curve. However, the tool is much less important to what I'm trying to achieve than the structuring in preparation for using maven to its fullest. Regarding the limitations of Maven's multi-project capabilities, I'm sure there are some, but I'm not sure I'll know what they are until I see them. I've already set up struts-el and struts-chain with project.xml files which extend the Struts base one and it works for those, at least. This is just for building, not necessarily for extended features. I would agree that we should have a consensus on the top-level structure. After that, I would need to have some real files to work on to make sure that Maven is building correctly, etc. Regarding the structure: My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site with Maven. I'm not sure if that'll work or not. Regarding Martin's suggestion to import the current CVS HEAD into SVN and then move things around... I don't know enough SVN to know if that makes sense or not. Please speak up with suggestions and opinions... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
On Mon, 12 Jul 2004 17:44:40 -0500, Joe Germuska wrote: Regarding CVS vs. SVN. I have zero SVN experience. I'm not opposed to it, but it will be slower for me personally if we go that route, as I'm starting at the bottom of the learning curve. Subversion is designed (by teams like ours) to be both a replacement and an enhancement to CVS (for teams like ours). If you know CVS, you already know 90% of SVN. Most of the remaining 10% is unlearning a few things that SVN does differently (in a good way) than CVS. The hardest part of the SVN curve is just pulling out of the driveway :) I'll try to get a SVN repository imported from the Struts CVS module today, and then you can see what I mean. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
On Mon, 12 Jul 2004 14:43:28 -0700 (PDT), Martin Cooper wrote: I'm not completely sure I understand what you're proposing, but here are a couple of points to bear in mind: 1) As we move out of the Jakarta repo into our own TLP repo, we need to decide whether we want to ask infrastructure@ for a new CVS repo or an SVN repo. (Personally, I'm leaning towards saying that what's in CVS is the 1.2.x branch, and taking exactly what's labelled as 1.2.1 and moving that to SVN, where we can (theoretically) mess around to our hearts' content, but that's just my on opinion.) +1 But if people would like to experiment on non-Apache hardware first, I can help with that too. snip/ IMHO, we really need to come up with a complete proposal for all of this - or at least a proposal for a plan for getting there - before we start making actual changes to what's in CVS today. That shouldn't stop you experimenting with the CVS tree locally, but I wouldn't want to see changes in the real live repo before we've agreed on where we want to go with all of this. I agree that a living repository would be the best proposal. If there are different approaches, we'd like to try, we can discuss and demo those too. If we're uncomfortable with having infrastructure@ setting up a SVN repository for us now, I can setup one elsewhere and provide access to the commiters. In the end, the bulk of a proposal might be the easiest way to import (SVN) or rename (CVS) our latest repository and reorganize it again, since once we are done, we might want to do it again with the latest revision of jakarta-struts (which will hopefully remain a moving target). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
Looking at what the Geronimo crowd is doing (extensive use of this Maven facility) should provide some fruitful material for study. I'm sure that those guys would also provide pointers about what works (and, more importantly, what doesn't work) when managing a large, complex, code base with lots of cross dependencies. I didn't get very far on this last night; I stayed at the office to work on it and ended up helping someone else meet a deadline. But in any case, I'm starting to think about it and will be working on this as I have time, and I will definitely check out the Geronimo CVS repository for ideas. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: CVS reorg: jakarta-struts - struts
There is obviously a strong push from some people to move struts to subversion. I have no idea at all what subversion offers as benefits, but I can say that I know it will create some immediate problems for me. I use eclipse and I enjoy wonderful tools support for CVS. This is also the case across the board with winCVS, Tortise, and others. What happens to those of us used to using tools to work with our version control. Subversion is not nearly as supported as CVS. There is a Subversion Eclipse plugin, but I think it is still in beta and only works with some point release of subversion. Not exactly the upgrade I would be hoping for. Michael On Mon, 12 Jul 2004 17:57:04 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote: * Did we end up deciding to stick with CVS versus Subversion? I know the infrastructure team would be happier if we switched to svn ... I haven't played with it enough to form an opinion on that yet. I would be +1 for Subversion. I could also host a SVN repository for us, temporarily. -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: CVS reorg: jakarta-struts - struts
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 3:45 PM To: Struts Developers List Subject: Re: CVS reorg: jakarta-struts - struts At 2:43 PM -0700 7/12/04, Martin Cooper wrote: I'm not completely sure I understand what you're proposing, but here are a couple of points to bear in mind: I may not understand it either. But I decided I'd like to see it move forward. So... Regarding CVS vs. SVN. I have zero SVN experience. I'm not opposed to it, but it will be slower for me personally if we go that route, as I'm starting at the bottom of the learning curve. However, the tool is much less important to what I'm trying to achieve than the structuring in preparation for using maven to its fullest. Well, I have zero experience with SVN at this point as well. ;-) However, one of the most-touted advantages of SVN over CVS is the ease with which files and directories can be moved around. That is extremely appealing, given that that's exactly what we're going to be doing a lot of until we settle on our final new repo structure. :-) Regarding the limitations of Maven's multi-project capabilities, I'm sure there are some, but I'm not sure I'll know what they are until I see them. I've already set up struts-el and struts-chain with project.xml files which extend the Struts base one and it works for those, at least. This is just for building, not necessarily for extended features. I would agree that we should have a consensus on the top-level structure. After that, I would need to have some real files to work on to make sure that Maven is building correctly, etc. Absolutely. We can talk all we want about theoretical repo structures, but ultimately the rubber has to meet the road, and we have to make it actually work. Regarding the structure: My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site with Maven. I'm not sure if that'll work or not. +1 for a single module. We'll need to be disciplined, I think, so that we don't lump a lot of common stuff into the top level, but we can work that out. Regarding the particular structure noted above, I do have a couple of issues that I noted before on this list, mostly related to view technologies. * I would like to see the core be independent of servlets, portlets, and especially JSP. The above structure has nowhere to put code that is JSP specific, but not related to taglibs. * While I understand the intent behind opt-taglib, I feel it is misnamed, since opt-el is also a set of taglibs, and opt-faces includes a taglib as well. * As we move forward, I believe the general concensus is to deprecate (in some sense of the word) the tags that have effectively been supplanted by JSTL. We might want to think about how to separate legacy tags from those that retain their utility and are tied to Struts. (The idea of moving the tags out of Struts entirely has been suggested somewhere along the line, but I have concerns about Jakarta Taglibs being somewhat of a SourceForge for taglibs these days, so I'm not sure where I would land on that one.) * There was also discussion of an opt-sandbox (or opt-dev or opt-whiteboard) for experimental stuff, but this is obviously something that can be added later. Here's the thread that has most of the earlier discussion: http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248 Regarding Martin's suggestion to import the current CVS HEAD into SVN and then move things around... I don't know enough SVN to know if that makes sense or not. As mentioned above, I was thinking that having it in SVN would allow us to futz around with the tree more easily. One thing that comes to mind is that we might want to build up the final repo structure somewhat incrementally. For example, we could start with trying to put together a core that has no dependencies on servlets, portlets or view technologies. Once we have that, we'll have a better picture of what doesn't fit in there, which will likely suggest ways to structure that, and so on and so forth. Just an idea... Please speak up with suggestions and opinions... I doubt you'll be short on those! ;-) -- Martin Cooper Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme
RE: CVS reorg: jakarta-struts - struts
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 2:42 AM To: Struts Developers List Subject: Re: CVS reorg: jakarta-struts - struts On Mon, 12 Jul 2004 14:43:28 -0700 (PDT), Martin Cooper wrote: I'm not completely sure I understand what you're proposing, but here are a couple of points to bear in mind: 1) As we move out of the Jakarta repo into our own TLP repo, we need to decide whether we want to ask infrastructure@ for a new CVS repo or an SVN repo. (Personally, I'm leaning towards saying that what's in CVS is the 1.2.x branch, and taking exactly what's labelled as 1.2.1 and moving that to SVN, where we can (theoretically) mess around to our hearts' content, but that's just my on opinion.) +1 But if people would like to experiment on non-Apache hardware first, I can help with that too. snip/ IMHO, we really need to come up with a complete proposal for all of this - or at least a proposal for a plan for getting there - before we start making actual changes to what's in CVS today. That shouldn't stop you experimenting with the CVS tree locally, but I wouldn't want to see changes in the real live repo before we've agreed on where we want to go with all of this. I agree that a living repository would be the best proposal. If there are different approaches, we'd like to try, we can discuss and demo those too. If we're uncomfortable with having infrastructure@ setting up a SVN repository for us now, I can setup one elsewhere and provide access to the commiters. That would be excellent, Ted. That would let us all learn SVN as well as play around with ideas without fear of messing things up too badly. ;-) If I could have found the time, I'd been thinking I wanted to do something like this too, except that I don't have any externally visible hardware. ;-( In the end, the bulk of a proposal might be the easiest way to import (SVN) or rename (CVS) our latest repository and reorganize it again, since once we are done, we might want to do it again with the latest revision of jakarta-struts (which will hopefully remain a moving target). I'm hoping that it wouldn't be too terribly long before we have something we're mostly happy with in a new repo, so that a 1.2.x branch wouldn't have got too far ahead of the experimental repo. On the other hand, I think it would be good to assume that we'll want to transform the tree more than once before we're done. ;-) BTW, Fitz has been working on a much-improved cvs2svn tool. Not sure what state that is in right now, but I can find out. -- Martin Cooper -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: CVS reorg: jakarta-struts - struts
OK, here's a revised idea. James H had a post (http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248) where he mentioned a few popular Struts projects. Please note that none of these have been officially invited to be part of Struts, and some may not want to be part of Struts... This is just to help flesh out the exercise. I'm not sure how we settled on the opt-* convention, but my feeling is that it will get annoyingly wide at the top of the module, so this proposes changing opt to a directory. I agree with Martin that we may want better names to distinguish between taglib and el, especially if we were to introduce other taglib-ish things (like Struts Menu). But for now -- (a) does anyone hate opt as a directory, or really think it needs to be part of another directory name (do we need opt-*/...) and (b) do people have strong feelings about an opt directory having a subdirectory like view. Should view be parallel to opt? struts/ struts/core struts/apps struts/site struts/opt/view/taglib struts/opt/view/el struts/opt/view/menu struts/opt/view/stxx struts/opt/faces struts/opt/testcase struts/opt/workflow struts/opt/bsf Regarding a place for non-taglib JSP stuff, I'm not sure how that would look, so I'm not sure how to propose handling it. Joe My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site with Maven. I'm not sure if that'll work or not. +1 for a single module. We'll need to be disciplined, I think, so that we don't lump a lot of common stuff into the top level, but we can work that out. Regarding the particular structure noted above, I do have a couple of issues that I noted before on this list, mostly related to view technologies. * I would like to see the core be independent of servlets, portlets, and especially JSP. The above structure has nowhere to put code that is JSP specific, but not related to taglibs. * While I understand the intent behind opt-taglib, I feel it is misnamed, since opt-el is also a set of taglibs, and opt-faces includes a taglib as well. * As we move forward, I believe the general concensus is to deprecate (in some sense of the word) the tags that have effectively been supplanted by JSTL. We might want to think about how to separate legacy tags from those that retain their utility and are tied to Struts. (The idea of moving the tags out of Struts entirely has been suggested somewhere along the line, but I have concerns about Jakarta Taglibs being somewhat of a SourceForge for taglibs these days, so I'm not sure where I would land on that one.) -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
RE: CVS reorg: jakarta-struts - struts
I got the opt- convention from Maverick. They have a core distribution, and then several optional distributions for using the framework with different view technologies. The idea is that all of these other distributions are optional. Of course, Linux also uses /opt for packages that are not installed by RPM. It's my feeling that the repository should be as flat as possible. Each of the top-level directories should represent a discrete subproject, or Maven artifact, with its own release cycle. The subproject under each of these directories would not share any source code. All sharing would be by the JAR each produces. In other words, we treat the top-level directories like modules even though they would be defined with the one CVS module. Under SVN, you can could check-out any of these subdirectories out as if they were modules, so we can have it both ways. (You don't have to checkout the gorilla if you only want the banana.) I don't recommend trying to apply a taxonomy within the repository. If we want to categorize subprojects by technology on a webpage that's fine. But I don't want to have the conversation of whether faces belongs under view or not. :) A structure like this (opt names for example only -- I don't know if all of these communities would want to be Struts subprojects or not): struts-apps/ struts-core/ struts-site/ struts-opt-bsf/ struts-opt-el/ struts-opt-faces/ struts-opt-menu/ struts-opt-stxx/ struts-opt-taglib/ struts-opt-testcase/ struts-opt-workflow/ says that we host 11 distributions (yahoo!). Each of these subdirectory names would also be the name of the Maven artifact produced (struts-core-jar, struts-opt-el.jar). The first three distributions are part of the standard release, and the other eight are optional. You can use them or not, in whatever combination you please. If this many root folders is a real problem for people, I could also see struts/ ./apps ./core ./site struts-opt/ ./bsf ./el ./faces ./menu ./stxx ./taglib ./testcase ./workflow So, a project.xml at /struts-opt/bsf/project.xml would generate an artifact like struts-opt-bsf-1.0.1.jar. Anyway, I'm getting the Struts SVN module setup, and hopefully it will be available later today. This will be a direct dump of the current CVS that we can refactor. -Ted. On Tue, 13 Jul 2004 10:52:44 -0500, Joe Germuska wrote: OK, here's a revised idea. James H had a post (http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248) where he mentioned a few popular Struts projects. Please note that none of these have been officially invited to be part of Struts, and some may not want to be part of Struts... This is just to help flesh out the exercise. I'm not sure how we settled on the opt-* convention, but my feeling is that it will get annoyingly wide at the top of the module, so this proposes changing opt to a directory. I agree with Martin that we may want better names to distinguish between taglib and el, especially if we were to introduce other taglib- ish things (like Struts Menu). But for now -- (a) does anyone hate opt as a directory, or really think it needs to be part of another directory name (do we need opt-*/...) and (b) do people have strong feelings about an opt directory having a subdirectory like view. Should view be parallel to opt? struts/ struts/core struts/apps struts/site struts/opt/view/taglib struts/opt/view/el struts/opt/view/menu struts/opt/view/stxx struts/opt/faces struts/opt/testcase struts/opt/workflow struts/opt/bsf Regarding a place for non-taglib JSP stuff, I'm not sure how that would look, so I'm not sure how to propose handling it. Joe My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site with Maven. I'm not sure if that'll work or not. +1 for a single module. We'll need to be disciplined, I think, so that we don't lump a lot of common stuff into the top level, but we can work that out. Regarding the particular structure noted above, I do have a couple of issues that I noted before on this list, mostly related to view technologies. * I would like to see the core be independent of servlets, portlets, and especially JSP. The above structure has nowhere to put code that is JSP specific, but not related to taglibs. * While I understand the
RE: CVS reorg: jakarta-struts - struts
At 12:32 PM -0400 7/13/04, Ted Husted wrote: It's my feeling that the repository should be as flat as possible. Each of the top-level directories should represent a discrete subproject, or Maven artifact, with its own release cycle. The subproject under each of these directories would not share any source code. All sharing would be by the JAR each produces. I see the appeal of this, and accept that using directories to make taxonomies may lead to unnecessary and uninteresting debates. Now that I think about it, Maven's multiproject facilities will also probably work better with a number of parallel directories instead of projects arbitrarily scattered around the tree. At least, I have only ever used it with parallel projects. The main question here is how the Maven report-type documentation (like Javadoc, source code Xref, test reports, etc) from the various directories other than struts-site would get folded in. struts-apps would not map to a single Maven artifact, I don't think. Not if it maps to all of: struts-blank.war struts-documentation.war struts-examples.war struts-mailreader.war tiles-documentation.war Or even just to examples and mailreader. Joe At 12:32 PM -0400 7/13/04, Ted Husted wrote: A structure like this (opt names for example only -- I don't know if all of these communities would want to be Struts subprojects or not): struts-apps/ struts-core/ struts-site/ struts-opt-bsf/ struts-opt-el/ struts-opt-faces/ struts-opt-menu/ struts-opt-stxx/ struts-opt-taglib/ struts-opt-testcase/ struts-opt-workflow/ says that we host 11 distributions (yahoo!). Each of these subdirectory names would also be the name of the Maven artifact produced (struts-core-jar, struts-opt-el.jar). The first three distributions are part of the standard release, and the other eight are optional. You can use them or not, in whatever combination you please. If this many root folders is a real problem for people, I could also see struts/ ./apps ./core ./site struts-opt/ ./bsf ./el ./faces ./menu ./stxx ./taglib ./testcase ./workflow So, a project.xml at /struts-opt/bsf/project.xml would generate an artifact like struts-opt-bsf-1.0.1.jar. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS reorg: jakarta-struts - struts
On Tue, 13 Jul 2004, Ted Husted wrote: I got the opt- convention from Maverick. They have a core distribution, and then several optional distributions for using the framework with different view technologies. The idea is that all of these other distributions are optional. Of course, Linux also uses /opt for packages that are not installed by RPM. It's my feeling that the repository should be as flat as possible. Each of the top-level directories should represent a discrete subproject, or Maven artifact, with its own release cycle. The subproject under each of these directories would not share any source code. All sharing would be by the JAR each produces. In other words, we treat the top-level directories like modules even though they would be defined with the one CVS module. Under SVN, you can could check-out any of these subdirectories out as if they were modules, so we can have it both ways. (You don't have to checkout the gorilla if you only want the banana.) As long as it's easy for me to check out the entire gorilla if that's what I want. ;-) I don't recommend trying to apply a taxonomy within the repository. If we want to categorize subprojects by technology on a webpage that's fine. But I don't want to have the conversation of whether faces belongs under view or not. :) A structure like this (opt names for example only -- I don't know if all of these communities would want to be Struts subprojects or not): struts-apps/ struts-core/ struts-site/ struts-opt-bsf/ struts-opt-el/ struts-opt-faces/ struts-opt-menu/ struts-opt-stxx/ struts-opt-taglib/ struts-opt-testcase/ struts-opt-workflow/ says that we host 11 distributions (yahoo!). Each of these subdirectory names would also be the name of the Maven artifact produced (struts-core-jar, struts-opt-el.jar). The first three distributions are part of the standard release, and the other eight are optional. You can use them or not, in whatever combination you please. That sounds nice in theory, but there are going to be cases where we'll need to share code between different 'opt's, and it's not clear (to me, at least) where that fits. For example, where would we put the methods that are currently in RequestUtils but that are tied to JSP? I would be very much opposed to JSP specific code being in core, but I'm not sure where else it would go. Would we need an opt-jsp just for that, that the other 'opt's depend on? If this many root folders is a real problem for people, I could also see struts/ ./apps ./core ./site struts-opt/ ./bsf ./el ./faces ./menu ./stxx ./taglib ./testcase ./workflow So, a project.xml at /struts-opt/bsf/project.xml would generate an artifact like struts-opt-bsf-1.0.1.jar. Anyway, I'm getting the Struts SVN module setup, and hopefully it will be available later today. This will be a direct dump of the current CVS that we can refactor. Cool! ;-) -- Martin Cooper -Ted. On Tue, 13 Jul 2004 10:52:44 -0500, Joe Germuska wrote: OK, here's a revised idea. James H had a post (http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248) where he mentioned a few popular Struts projects. Please note that none of these have been officially invited to be part of Struts, and some may not want to be part of Struts... This is just to help flesh out the exercise. I'm not sure how we settled on the opt-* convention, but my feeling is that it will get annoyingly wide at the top of the module, so this proposes changing opt to a directory. I agree with Martin that we may want better names to distinguish between taglib and el, especially if we were to introduce other taglib- ish things (like Struts Menu). But for now -- (a) does anyone hate opt as a directory, or really think it needs to be part of another directory name (do we need opt-*/...) and (b) do people have strong feelings about an opt directory having a subdirectory like view. Should view be parallel to opt? struts/ struts/core struts/apps struts/site struts/opt/view/taglib struts/opt/view/el struts/opt/view/menu struts/opt/view/stxx struts/opt/faces struts/opt/testcase struts/opt/workflow struts/opt/bsf Regarding a place for non-taglib JSP stuff, I'm not sure how that would look, so I'm not sure how to propose handling it. Joe My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site
RE: CVS reorg: jakarta-struts - struts
On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote: As long as it's easy for me to check out the entire gorilla if that's what I want. ;-) But of course :) That sounds nice in theory, but there are going to be cases where we'll need to share code between different 'opt's, and it's not clear (to me, at least) where that fits. For example, where would we put the methods that are currently in RequestUtils but that are tied to JSP? I would be very much opposed to JSP specific code being in core, but I'm not sure where else it would go. Would we need an opt-jsp just for that, that the other 'opt's depend on? For now, they would have to stay in the core. Later, we can try and refactor them out. It's also possible that other taglib distributions are dependant on RequestUtils, so once we decide what to do, they'd have to be deprecated and available in both places for a while. For starters, we can make a clean drop of the taglib package into struts-opt-taglib, and proceed from there. (Better to get 80% of what you want now, then 100% never.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS reorg: jakarta-struts - struts
On Tue, 13 Jul 2004 13:01:05 -0500, Joe Germuska wrote: struts-apps would not map to a single Maven artifact, I don't think. Not if it maps to all of: struts-blank.war struts- documentation.war struts-examples.war struts-mailreader.war tiles-documentation.war True. Kinda of the exception that proves the rule. :) The outer portion of struts-documentation would become struts-site. Most of the userGuide portion would be rolled into struts-core, except for parts that pertain to the taglibs, which would rolled into that subproject instead. struts-blank, struts-examples, struts-mailreader, and tiles-documentation (or maybe tiles-examples), would all be subprojects of the struts-apps master project, and so, yes, struts-apps would produce multiple WAR artifacts. But there would be one for every directory immediately below struts-apps. ./struts/apps/blank ./struts/apps/examples ./struts/apps/mailreader ./struts/apps/tiles-examples -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
Michael Rassmussen wrote: There is obviously a strong push from some people to move struts to subversion. I have no idea at all what subversion offers as benefits, but I can say that I know it will create some immediate problems for me. I use eclipse and I enjoy wonderful tools support for CVS. This is also the case across the board with winCVS, Tortise, and others. What happens to those of us used to using tools to work with our version control. Subversion is not nearly as supported as CVS. There is a Subversion Eclipse plugin, but I think it is still in beta and only works with some point release of subversion. Not exactly the upgrade I would be hoping for. Michael I'm agree with you, i'm not a committer but i frequently synchronize my struts build with the apache repository. With subversion, which isn't integrated as well as CVS into Eclipse (AFAIK), it would be more difficult. Also a lot of people knows CVS, and perhaps (like me) don't want to integrate another software (svn) just for doing a rebuild of struts from CVS distro. I understand that SVN is - perhaps - the futur of versionning - and that this futur is really near us - but i think that it's more easy to install CVS (client at least) or, better, CVs is integrated into all unix, which is not the case of SVN. Please don't blame my english (nor my laziness to upgrade my develoment environment, but it's a lot of work!) -- Ludovic Maître Factory Productions | Tél: (33) 04 93 07 08 00 149, avenue des mimosas | Fax: (33) 04 93 07 04 02 06700 Saint-Laurent-du-Var (France) | Web: http://www.factory.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS reorg: jakarta-struts - struts
Apropos of the earlier discussion about Maven repositories and such, I'm going to try to spend at least a couple of hours staking out a new CVS repository for struts-as-TLP. I'm going to try to set up a local repository on my machine with a copy of /home/cvs/jakarta-struts and see what I can do with just moving files around. Assuming that I get anywhere at all, are people OK with setting it up in CVS under the module struts and letting people use the Apache CVS server to test it? If not, I might be able to find a place to host it. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: CVS reorg: jakarta-struts - struts
Joe Germuska wrote: Apropos of the earlier discussion about Maven repositories and such, I'm going to try to spend at least a couple of hours staking out a new CVS repository for struts-as-TLP. I'm going to try to set up a local repository on my machine with a copy of /home/cvs/jakarta-struts and see what I can do with just moving files around. Assuming that I get anywhere at all, are people OK with setting it up in CVS under the module struts and letting people use the Apache CVS server to test it? If not, I might be able to find a place to host it. Joe +1 on having a repository available somewhere to play with, if what you come up with looks useful. -0 on having it on Apache hardware, until we adopt it officially. I think it would be confusing to people in the interim period between when it was installed and when it was adopted/abandoned. Regarding a couple of other issues that are fuzzy in my mind: * Did we end up agreeing with one repository (versus multiple) in the new world repository? If so, struts is a good name for it. Otherwise, we might want to call it struts-experimental or something during the trial and testing phase. * Did we end up deciding to stick with CVS versus Subversion? I know the infrastructure team would be happier if we switched to svn ... I haven't played with it enough to form an opinion on that yet. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote: * Did we end up deciding to stick with CVS versus Subversion? I know the infrastructure team would be happier if we switched to svn ... I haven't played with it enough to form an opinion on that yet. I would be +1 for Subversion. I could also host a SVN repository for us, temporarily. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
At 2:43 PM -0700 7/12/04, Martin Cooper wrote: I'm not completely sure I understand what you're proposing, but here are a couple of points to bear in mind: I may not understand it either. But I decided I'd like to see it move forward. So... Regarding CVS vs. SVN. I have zero SVN experience. I'm not opposed to it, but it will be slower for me personally if we go that route, as I'm starting at the bottom of the learning curve. However, the tool is much less important to what I'm trying to achieve than the structuring in preparation for using maven to its fullest. Regarding the limitations of Maven's multi-project capabilities, I'm sure there are some, but I'm not sure I'll know what they are until I see them. I've already set up struts-el and struts-chain with project.xml files which extend the Struts base one and it works for those, at least. This is just for building, not necessarily for extended features. I would agree that we should have a consensus on the top-level structure. After that, I would need to have some real files to work on to make sure that Maven is building correctly, etc. Regarding the structure: My understanding was that we had settled on a single module, struts, under which we would have something like below (mostly lifted from an email from Ted to the [EMAIL PROTECTED] list) struts/ struts/core struts/apps struts/site struts/opt-taglib struts/opt-el struts/opt-faces etc. But I'm not married to that. I think a single module is easier for a lot of reasons, and you can partition the space within the module as much as you want so that I don't think you need parallel modules. I don't have a strong opinion about how the module is partitioned. One of the things I need to experiment with is whether it works to have a site directory alongside other directories when you go to build the site with Maven. I'm not sure if that'll work or not. Regarding Martin's suggestion to import the current CVS HEAD into SVN and then move things around... I don't know enough SVN to know if that makes sense or not. Please speak up with suggestions and opinions... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: CVS reorg: jakarta-struts - struts
Martin Cooper wrote: 3) Given the factoring into sub-projects that we want to do, we'll no doubt be making extensive use of Maven's multi-project capabilities. It would be nice to know what that actually means, especially in terms of constraints. (I'm afraid I don't have much of a clue, so I'm hoping someone else does. ;) Looking at what the Geronimo crowd is doing (extensive use of this Maven facility) should provide some fruitful material for study. I'm sure that those guys would also provide pointers about what works (and, more importantly, what doesn't work) when managing a large, complex, code base with lots of cross dependencies. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
