There is that, but in terms of project management for the Jakarta Taglibs, it'll turn each ELized version into a new project, or a branch or somewhat. Unless we declare org.apache.taglibs.<name>.el to be special perhaps, and output two jars, one with and one without the el sub-package.
Will ask Glenn. Hen On Fri, 1 Nov 2002, Karr, David wrote: > My goal is to not change the existing library at all, either at the > source level or the deployment level. If you put the new classes in the > old jar, then people deploying the old taglib will get those extra > classes. Those shouldn't cause any conflicts, but I don't like to > introduce changes that "very likely" won't have any effect. > > > -----Original Message----- > > From: Henri Yandell [mailto:bayard@;generationjava.com] > > Sent: Friday, November 01, 2002 12:31 PM > > > > On Fri, 1 Nov 2002, Karr, David wrote: > > > > > All the tag classes in the Struts-EL tag library are > > subclasses of the > > > corresponding class in the Struts tag library, and all of them look > > > almost identical. In each one, the "doStartTag()" method > > calls a method > > > called "evaluateExpressions()", which just has one block of almost > > > identical code for each property of the tag, which just passes the > > > current value of the property through the EL parser and into the > > > "setter" method for the property. The only exception to > > this relatively > > > > Okay. I'm convinced :) Will work on getting a 1.1 release out > > which has an > > EL'd component. Any reason it has to be a different jar? Or > > just one jar > > with them all and a different tld? > > -- > To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org>
