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
