Frank W. Zammetti wrote:
point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep?
Right now, the Standard is already a sub-project of the Jakarta Taglibs. So, what we meant (sorry for the confusion) is that the Standard wouldn't be migrated to this new project; instead, it would be a Jakarta sub-project, sibling of the new project.
Regarding the other taglibs, I agree, it might make more sense for all of them to be direct sub-projects of the new project, instead of having an intermediate taglibs sub-project. But that's something we can decide later one - as we (the Jakarta Taglibs project) decided that we should create new taglibs from scratch (using the legacy code), the structure wouldn't matter at this point.
My own JWP project has a taglib package that has individual taglibs within it (AjaxTags, BasicString, etc), so I have the same thing going on... I personally wouldn't go beyond 3-levels like this, and I just wanted to raise the issue now before anything actually moves forward in case others have thoughts on this.
I agree - sometimes it makes more sense to aggregate components by functionality than classes. For instance, we could have a Security sub-project which would produce taglibs (like a PageGuardTag), filters and even Struts actions.
-- Felipe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
