These are all good points. One reason I had been thinking about splitting each taglib into its own jar is so that we could put the tld file in there as well, instead of having those files "loose". With JSP 1.1, the tld file in a packaged taglib must be named taglib.tld, so it's not possible to package multiple taglibs in the same jar file. (This restriction was lifted in JSP 1.2, but we can't make use of that yet for compatibility reasons.) The end result would be the same number of files as we have today, but we'd have multiple Struts jars instead of one, and no loose tlds. However, you're right that these taglib jars would still be dependent on the core Struts jar.
With Ted's comments in mind, perhaps we should leave things as they are until we have a better understanding of what external presentation devices (e.g. Velocity Templates) would need from Struts. At that point, we would be in a better position to think about how to expose functionality from a core library to client libraries, including separate Struts taglibs. (By the way, the other changes to the build process that I referred to are actually additions related to simplifying the release process, and will have very little impact on the way people build Struts today.) -- Martin Cooper ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Sunday, January 13, 2002 1:56 PM Subject: Re: [SHORT TERM PLANS] > > > On Sat, 12 Jan 2002, Martin Cooper wrote: > > > Date: Sat, 12 Jan 2002 23:16:29 -0800 > > From: Martin Cooper <[EMAIL PROTECTED]> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: Struts Developers List <[EMAIL PROTECTED]> > > Subject: Re: [SHORT TERM PLANS] > > > > I know I'm coming in a month late on this, but the holidays are over and now > > I'm paying attention again... ;-) > > > > I guess I missed the original thread suggesting the breakup of the Struts > > jar file into core and taglibs. I can see the rationale for splitting the > > taglibs out from the core framework. However, I'm not so sure that all the > > taglibs should be split out as a single entity. It seems to me that it would > > make more sense to split out each taglib as its own self-contained entity, > > in the manner of Jakarta Taglibs. > > > > I'm planning on making some other changes to the Struts build process in the > > near future, and I could certainly roll these in if people think it would be > > desirable. > > > > What do people think? > > > > What about the stuff that's shared across multiple taglibs > (org.apache.struts.util.*, org.apache.struts.action.*, and so on)? I > haven't checked them all, but I'd be surprised if *any* of the tag > libraries can stand on their own without needing the proposed > struts-core.jar anyway. > > IMHO, having more smaller pieces makes life harder, not easier -- it's one > of the few negatives for using commons-*.jar instead of the old stuff that > was all right there waiting for you in struts.jar. > > > -- > > Martin Cooper > > > > Craig > > > > > > ----- Original Message ----- > > From: "Ted Husted" <[EMAIL PROTECTED]> > > To: "Struts Developers List" <[EMAIL PROTECTED]> > > Sent: Saturday, December 15, 2001 8:35 AM > > Subject: Re: [SHORT TERM PLANS] > > > > > > > Ooops, one more. > > > > > > * Adjust the build process so that there is a struts-core.jar and a > > > struts-tags.jar > > > > > > > > > Ted Husted wrote: > > > > > > > > So to wrap up several outstanding threads, here's what is on my > > > > near-term agenda > > > > > > > > * Commit the initial ContextHelper to ActionServlet. > > > > > > > > * Commit the InvokeAction class to ActionServet. > > > > > > > > * Commit a SuperForm base class to action, for discussion purposes. > > > > > > > > * Develop a "smart" ActionForward class, that can build a dynamic path > > > > at runtime. > > > > > > > > * Start moving the TODOs over to Bugzilla as enhancements requests. > > > > > > > > If someone wants to take a good look at Arron's nesting taglib, we > > > > should consider that too. I just don't do a lot of work with the tag > > > > extensions myself. We should also revisit the base class for exception > > > > handling sometime soon. > > > > > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > > > > -- Custom Software ~ Technical Services. > > > > -- Tel +1 716 737-3463 > > > > -- http://www.husted.com/struts/ > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > > > -- Custom Software ~ Technical Services. > > > -- Tel +1 716 737-3463 > > > -- http://www.husted.com/struts/ > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
