2015-03-01 1:04 GMT+03:00 Jeremy Boynes <jboy...@apache.org>: > Resurrecting this old thread[1] as the topic came up related to the site > changes. First message included for context below. > > TL;DR: Konstantin and I had interest in new work on Standard, Henri has > helped with logistics. No-one had any interest in RDC. A concern at the time > was lack of progress toward a release but since then we released 1.2.1 in > 2014/01 and recently 1.2.3. The 1.2 version has been picked up by some > downstream projects; to my knowledge, it is the only implementation available > under an Apache-style license. > > Rather than retire Taglibs now I would propose we attempt to reignite > community interest which will require steps beyond simply maintaining 1.2.x. > I’d propose the following: > > - Retire RDC to the Attic
No objections here. Well, its site already says that it is retired, "2014/01/18 - The RDC Taglib has been retired." > - Fix the sub-site so it’s easier to maintain +1 > - Put Standard 1.2.x in maintenance mode for bug fixes only > - Start a tree/branch for new work without the limitations of the now-ancient > 1.2 spec > - Plan to release new work early & often I do not see a reason for branching. The library implements specification. In what direction is "trunk" supposed to go? Possible directions: a) Improve it for newer versions of Java, while still maintaining the same API? b) Extend the library outside of specification? c) Update it to newer versions of specification? I think there is no new specification version now, but maybe there is some development/plans? d) Work on built-in implementation of JSTL tags in Jasper? (Jasper Tag plugins) I mean: If there is no new development planned, we would better stay on the current trunk without separate maintenance branch. It is a bit more risky, but it has less overhead. I would like to fix some of many generics warnings shown by Eclipse IDE (either implement generics or to add @SupressWarning). No definite time slot for that though as I am not sure whether it is worth to spend time on that. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
