Quoting Ted Husted <[EMAIL PROTECTED]>: > On Wed, 24 Mar 2004 20:35:41 +0000, Peter A. Pilgrim wrote: > > Are keeping the basic `src' and `web' main sub directory under each > > top level directory? > > I'd prefer we followed the Maven project layout recommendations for each > deliverable. This will be the easiest for everyone to grok in the longrun. > > http://maven.apache.org/reference/dirlayout.html > > So, under each top-level directory, we would find a layout like > > /src > - java > - test > - webapp > > /xdocs > > /target (generated) > - *.jar > - distributions > - docs > - site > - ... > > > > May be it is worth putting `opt-legacy' and `opt-el' under a `view' > > directory especially if they are all to do rendering the web user > > interface > > You might have meant opt-taglib and opt-el. Legacy is the old datasource > implementation. > > I'd strongly prefer keeping a close relationship between > top-level-directories and deliverables, and that we avoid taxonomies. > > Joe suggested combining opt-el with opt-taglibs, though we'd have to be > careful which dependencies are used to build what. (Which makes me think they > are not the same deliverable. el might just have a dependency on taglib.) I > don't actually use either one much myself, so I have no preferences myself. > > The example applications tree might be a tad different. Here I'd favor a > master apps directory, with a directory for each application beneath that. > This makes it easy for the apps to extend a common Maven project.xml. We > could still offer a single zip/tarball with all the applications WARs within. > > > /apps > - examples > - mailreader > - tilesPortal > - userdb > > Now that I say it, the same approach might conceivably be used for el, > taglibs, and faces. > > /taglibs > - classic > - el > - faces > > But, the problem with binding the taglib packages too closely is that they > would all have to be distribution-ready before we did a new roll of any. So, > an ongoing refactoring in the "classic" taglibs could block a quick release > of the "faces" taglib. >
As I've mentioned before, JavaServer Faces is not just about JSP custom tags ... the components and renderers in this package are just like Struts itself, in that they're view technology independent. Technologically, therefoe, "faces" does not belong under "taglibs". Further, I'd think the Struts developers would want to explore ways in which other parts of Struts might benefit from some of the infrastructure features in JSF, such as managed beans and programmatic expression evaluation. They are darned handy. > I really want to try and avoid the hydraulic dependencies of the 1.1 era, > where we had to have everything ready to release all at once :( Agreed. > -Ted. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
