Re: Time for Taglibs to be sent to the archive?

[Jeremy Boynes <jb...@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
- 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 

Taglibs/JSP future work, was: Time for Taglibs to be sent to the archive?

[Jeremy Boynes <jb...@apache.org>]

On Mar 2, 2015, at 5:21 AM, Konstantin Kolinko <kn...@gmail.com> wrote:
> 
> 2015-03-01 1:04 GMT+03:00 Jeremy Boynes <jb...@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

Re: Time for Taglibs to be sent to the archive?

[Konstantin Kolinko <kn...@gmail.com>]

2015-03-01 1:04 GMT+03:00 Jeremy Boynes <jb...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Time for Taglibs to be sent to the archive?

[Mark Thomas <ma...@apache.org>]

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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org