Release of Apache Taglibs
I made a couple of minor improvements to Apache Taglibs last year related to XML parsing and to how we load libraries (it now uses the TCCL which means the jars can be shared between webapps as well as be included in a webapp as before). I would like to perform a minor release (1.2.2) to include these. Before I do, are there any other issues that should be addressed? One change in 1.2 I think was not useful was the split of the 1.0 EL evaluator into its own jar. I propose to merge that back so we end up with two jars: one with the javax classes and one with our implementation. Thanks Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Release of Apache Taglibs
On 08/01/2015 06:42, Jeremy Boynes wrote: > I made a couple of minor improvements to Apache Taglibs last year related to > XML parsing and to how we load libraries (it now uses the TCCL which means > the jars can be shared between webapps as well as be included in a webapp as > before). I would like to perform a minor release (1.2.2) to include these. > Before I do, are there any other issues that should be addressed? > > One change in 1.2 I think was not useful was the split of the 1.0 EL > evaluator into its own jar. I propose to merge that back so we end up with > two jars: one with the javax classes and one with our implementation. Sounds good to me. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release of Apache Taglibs
2015-01-08 9:42 GMT+03:00 Jeremy Boynes : > I made a couple of minor improvements to Apache Taglibs last year related to > XML parsing and to how we load libraries (it now uses the TCCL which means > the jars can be shared between webapps as well as be included in a webapp as > before). I would like to perform a minor release (1.2.2) to include these. > Before I do, are there any other issues that should be addressed? > > One change in 1.2 I think was not useful was the split of the 1.0 EL > evaluator into its own jar. I propose to merge that back so we end up with > two jars: one with the javax classes and one with our implementation. I do not see a point in merging them back. Personally, I do not use JSTL 1.0 EL implementation and do not plan to use it. (IIRC, the only occurrence when I used them was when I made a typo in tag library url, like copy-pasting from a wrong tld file. Hilarity ensued). Unexpectedly using a wrong implementation may be confusing. Another point is that I do not like changing release packaging in a point release. Is this driven by a real users' demand? Have there been any public complaints from real users (e.g. an issue in Bugzilla)? What do we do with Maven artifacts? Abandon one of them? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release of Apache Taglibs
On Jan 8, 2015, at 1:42 PM, Konstantin Kolinko wrote: > > 2015-01-08 9:42 GMT+03:00 Jeremy Boynes : >> I made a couple of minor improvements to Apache Taglibs last year related to >> XML parsing and to how we load libraries (it now uses the TCCL which means >> the jars can be shared between webapps as well as be included in a webapp as >> before). I would like to perform a minor release (1.2.2) to include these. >> Before I do, are there any other issues that should be addressed? >> >> One change in 1.2 I think was not useful was the split of the 1.0 EL >> evaluator into its own jar. I propose to merge that back so we end up with >> two jars: one with the javax classes and one with our implementation. > > I do not see a point in merging them back. Personally, I do not use > JSTL 1.0 EL implementation and do not plan to use it. (IIRC, the only > occurrence when I used them was when I made a typo in tag library url, > like copy-pasting from a wrong tld file. Hilarity ensued). > Unexpectedly using a wrong implementation may be confusing. That was the kind of thing that prompted me to split it off in the first place. The other was to the allow users to use a newer EL implementation (such as the one from the container) which could have performance or efficiency improvements over the original one, especially now EL has been decoupled from JSTL and JSP. However, I found a problem with the -compat packaging that would prevent that jar being used; see #57427. As no-one else had reported that my assumption was that this was not that useful. > Another point is that I do not like changing release packaging in a > point release. Is this driven by a real users' demand? Have there > been any public complaints from real users (e.g. an issue in > Bugzilla)? What do we do with Maven artifacts? Abandon one of them? As I’d not seen any feedback on the split (public or private) I was thinking of simply reverting to the 1.1.x model. Sounds better though to fix the problems with the -compat version and defer merging until a potential 1.3 release. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Release of Apache Taglibs
On Jan 8, 2015, at 9:26 PM, Jeremy Boynes wrote: > > On Jan 8, 2015, at 1:42 PM, Konstantin Kolinko wrote: >> >> 2015-01-08 9:42 GMT+03:00 Jeremy Boynes : >>> I made a couple of minor improvements to Apache Taglibs last year related >>> to XML parsing and to how we load libraries (it now uses the TCCL which >>> means the jars can be shared between webapps as well as be included in a >>> webapp as before). I would like to perform a minor release (1.2.2) to >>> include these. Before I do, are there any other issues that should be >>> addressed? >>> >>> One change in 1.2 I think was not useful was the split of the 1.0 EL >>> evaluator into its own jar. I propose to merge that back so we end up with >>> two jars: one with the javax classes and one with our implementation. >> >> I do not see a point in merging them back. Personally, I do not use >> JSTL 1.0 EL implementation and do not plan to use it. (IIRC, the only >> occurrence when I used them was when I made a typo in tag library url, >> like copy-pasting from a wrong tld file. Hilarity ensued). >> Unexpectedly using a wrong implementation may be confusing. > > That was the kind of thing that prompted me to split it off in the first > place. > > The other was to the allow users to use a newer EL implementation (such as > the one from the container) which could have performance or efficiency > improvements over the original one, especially now EL has been decoupled from > JSTL and JSP. However, I found a problem with the -compat packaging that > would prevent that jar being used; see #57427. As no-one else had reported > that my assumption was that this was not that useful. > >> Another point is that I do not like changing release packaging in a >> point release. Is this driven by a real users' demand? Have there >> been any public complaints from real users (e.g. an issue in >> Bugzilla)? What do we do with Maven artifacts? Abandon one of them? > > As I’d not seen any feedback on the split (public or private) I was thinking > of simply reverting to the 1.1.x model. Sounds better though to fix the > problems with the -compat version and defer merging until a potential 1.3 > release. I’ve fixed the issues with the -compat version and verified that that configuration also passes the TCK. I am going to update the release notes and start the release process. Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
