Taglibs/JSP future work, was: Time for Taglibs to be sent to the archive?
On Mar 2, 2015, at 5:21 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-03-01 1:04 GMT+03:00 Jeremy Boynes jboy...@apache.org: ... - 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? We had talked previously about dropping Java5 support and decided not to do that in 1.2.x release. I was thinking of a 2.x trunk that would allow us to baseline on a newer version, specifically Java8 given the public version of Java7 reaches EOL next month (April 2015). It was thinking about the lambda support that led me to the straw man I posted earlier today. Which leads to ... 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? JSP is included in the list of technologies “expected to be updated” in Java EE 8 but as the JSR is still closed we won’t see anything until the PFD phase. Given recent history I would not expect to see any major changes. Since JSTL 1.0 came out we’ve see many changes in its space: * EL became a standalone thing * EL can call Java functions directly eliminating the need for function definitions in TLDs * Script-free JSP pages became best-practice * Pooling became less important leading to the SimpleTag model * Annotation, introspection and injection became commonplace * MVC meant JSPs became primarily a View component rather than playing the Controller role With the introduction of pruning abilities in EE6 some things that could go might include: * EL 1.0 and the legacy JSP APIs that support it * JSTL’s XML and SQL tags Rather than wait for the spec we could start to simplify the the model for people working at the JSP level (i.e. above Servlets but lower than JSF, perhaps in conjunction with the new MVC spec). d) Work on built-in implementation of JSTL tags in Jasper? (Jasper Tag plugins) Jasper has plugin for JSTL core but there are some edge cases it handles incorrectly. I should open bugs for them and we could fix those :) I’d actually like to take a second look at the plugin mechanism anyway - for example, why does it key off the tag’s implementation class rather than its QName. 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. Things I was thinking of in the current implementation include: * Making Java 8 the baseline JRE and updating to it (separate from any functional work) * Making Java EE 7 the baseline container and dropping -jstlel in favour of -compat - This would get rid of a many of those code-health warnings in one swoop :) - -compat would merge back into -impl * Separating the 4 libraries into separate modules (core, fmt, xml, sql) so: - Users would only need the libraries they actually used - We could release each module separately as needed - Xalan would only be needed when using the XML library - We could do an alternate fmt using ICU4J which typically updates quicker than the JDK I probably wasn’t clear originally - I meant this type of work would be on trunk and we’d create a stable branch 1.2.x to support bug-fixes. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Time for Taglibs to be sent to the archive?
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
Re: Time for Taglibs to be sent to the archive?
On 28/02/2015 22:04, Jeremy Boynes wrote: 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 - Put Standard 1.2.x in maintenance mode for bug fixes only - Fix the sub-site so it’s easier to maintain - Start a tree/branch for new work without the limitations of the now-ancient 1.2 spec - Plan to release new work early often Thoughts? Go for it. Mark Jeremy [1] http://mail-archives.apache.org/mod_mbox/tomcat-dev/201210.mbox/%3C50694B65.9040904%40apache.org%3E On Oct 1, 2012, at 12:51 AM, Mark Thomas ma...@apache.org wrote: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
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 - Put Standard 1.2.x in maintenance mode for bug fixes only - Fix the sub-site so it’s easier to maintain - Start a tree/branch for new work without the limitations of the now-ancient 1.2 spec - Plan to release new work early often Thoughts? Jeremy [1] http://mail-archives.apache.org/mod_mbox/tomcat-dev/201210.mbox/%3C50694B65.9040904%40apache.org%3E On Oct 1, 2012, at 12:51 AM, Mark Thomas ma...@apache.org wrote: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Time for Taglibs to be sent to the archive?
On Jan 29, 2013, at 11:56 PM, Jeremy Boynes wrote: ... My interpretation was that a product must pass the TCK in all its configurations. In other words, you can't claim compatibility on Java7 unless you've tested on Java7. If we test on Java7 and pass, we can claim we're a compatible implementation in that mode; if we don't test on Java5 then we can't claim compatibility on Java5 but that does not stop us being compatible on Java7. I read it as being sufficient if we document what we require as a resource. @Henri, I ran all tests on Java6 and have not tried SQL on Java7. I'll pull the newer version and retest. I pulled the newer TCK and the current trunk revision passes all tests. Although the newer version says it was updated for Java7, the test harness does not compile due to JDBC issues. There are a couple of utility classes that were fixed to work with 1.6 but which do not support the methods added in 1.7. Rather than patch them, I built the tests using 1.6 and ran them with 1.6 and 1.7. I tested the following configurations: ServerHarness Tomcat 6.0.35/Java 1.6Java 1.6 Tomcat 6.0.35/Java 1.7Java 1.6 Tomcat 7.0.35/Java 1.7Java 1.6 Tomcat 7.0.35/Java 1.7Java 1.7 All tests pass in all configurations. OS: Mac OS X 10.7.5 DB: derby-10.6.1.0 Apache JSTL jars: taglibs-standard-spec-1.2-SNAPSHOT.jar taglibs-standard-impl-1.2-SNAPSHOT.jar taglibs-standard-jstlel-1.2-SNAPSHOT.jar xalan-2.7.1.jar serializer-2.7.1.jar The signature tests are no longer built and run from the top level. They pass if run on Java 1.6 but there is no signature file for running them on 1.7. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Mon, Jan 28, 2013 at 3:46 AM, Mark Thomas ma...@apache.org wrote: On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. We could use the Tomcat trick though. if(passTCKFlag) then do the no-one-wants option. Then by default it could run smoothly on JDK 7. I've vague memories that the SQL side of things makes that painful. Did you look at that Jeremy? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Jan 28, 2013, at 3:46 AM, Mark Thomas wrote: On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. My interpretation was that a product must pass the TCK in all its configurations. In other words, you can't claim compatibility on Java7 unless you've tested on Java7. If we test on Java7 and pass, we can claim we're a compatible implementation in that mode; if we don't test on Java5 then we can't claim compatibility on Java5 but that does not stop us being compatible on Java7. I read it as being sufficient if we document what we require as a resource. @Henri, I ran all tests on Java6 and have not tried SQL on Java7. I'll pull the newer version and retest. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Do we have to do any bureaucratize to register as having passed the TCK? Or is it: * Generate release artifacts. * VOTE on release. * VOTE on Attic. * Publish. * Make project read-only. Hen On Mon, Dec 31, 2012 at 3:11 PM, Henri Yandell flame...@gmail.com wrote: What exactly is left to do the release? Not having a permissively licensed JSTL 1.2 is a shame when the code is there. Even if we put it in the Attic, I'd love to say And here is a 1.2 compliant version, good luck rather than sorry, get it from SVN. I'd be happy to put in the effort to do the votes/website. I'd need to hit the site anyway as a part of sending it to the Attic. Is it 100% good on the TCK, nothing more needed? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. (...) Note: This is intended as a discussion topic - not a formal proposal/vote. Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. 2. Apparently, there are two implementations for JSTL 1.0 tags: jstlel, compat. jstlel provides its own EL engine according to the old specification, compat.uses EL engine from the container. I think having two implementations is too many. Can we drop compat? I have not studied the history yet, but my copy of jakarta-taglibs-standard-1.1.2 does not have those compat tags neither in binary nor in source distributive. 3. The README_*.txt files in the root directory are outdated and need some tweaking. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On 18/01/2013 08:48, Henri Yandell wrote: Do we have to do any bureaucratize to register as having passed the TCK? Or is it: * Generate release artifacts. * VOTE on release. * VOTE on Attic. * Publish. * Make project read-only. At most, it involves sending a couple of e-mails. I'm happy to handle that part. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. 2. Apparently, there are two implementations for JSTL 1.0 tags: jstlel, compat. jstlel provides its own EL engine according to the old specification, compat.uses EL engine from the container. I think having two implementations is too many. Can we drop compat? I did this to ensure that applications using 1.0 would not be impacted by any new features added to later versions of EL (for example stricter rules on names), but also to allow users to switch to the container's if they did not want to ship/rely on the older implementation. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
What exactly is left to do the release? Not having a permissively licensed JSTL 1.2 is a shame when the code is there. Even if we put it in the Attic, I'd love to say And here is a 1.2 compliant version, good luck rather than sorry, get it from SVN. I'd be happy to put in the effort to do the votes/website. I'd need to hit the site anyway as a part of sending it to the Attic. Is it 100% good on the TCK, nothing more needed? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On 29/12/2012 21:02, Henri Yandell wrote: Should we have a formal vote Mark? I think we have reached that point. svnpubsub has been set up (which means we can easily keep the website content up going forward) but the fact remains there has been little/no development effort and no sign of working towards a release. I suggest we leave it a week or two to give folks a chance to speak up and then - unless a reason not to emerges - have the vote. Mark Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Should we have a formal vote Mark? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
+0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Time for Taglibs to be sent to the archive?
In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
