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 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.)
--------------------------------------------------------------------- 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]
