[
https://issues.apache.org/jira/browse/WW-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107295#comment-18107295
]
Lukasz Lenart commented on WW-2278:
-----------------------------------
h3. Triage 2026-08-24 — recommending Won't Fix
Reviewed against the [dev@
thread|https://lists.apache.org/thread/xnqqc7617j6clv2rv253qyoj8x6rsmr7] (all
30 messages) and the current 7.4.0-SNAPSHOT code.
h4. History
Filed 2007-10-31. Fix version has been pushed nine times — 2.1.4, 2.2.x, 3.x,
6.1.0, 6.2.0, 7.0.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0 — and no commit has ever
referenced this ticket.
The Oct 2007 thread had genuine consensus (Don Brown, Ted Husted, Martin
Cooper, Musachy Barroso, Antonio Petrelli, Patrick Lightbody, Piero Sartini,
Chris Pratt in favour; Brian Pontarelli and Matt Raible hesitant on newcomer
experience, answered with "ship an omnibus jar"). Don's three goals were: (1)
less code in core to maintain, (2) encourage multiple tag libraries, (3) force
better tag pluggability. Chris Pratt supplied the concrete user benefit: an
application not using the taglibs could then drop ognl.jar and freemarker.jar
and skip TLD pre-loading.
h4. Why it is not actionable as written
_1. The headline user benefit is now unattainable._ OGNL is the value stack and
cannot leave core. FreeMarker is load-bearing for three non-tag features:
FreemarkerResult (registered in struts-default.xml),
DefaultDispatcherErrorHandler (dev-mode error page) and
ExecuteAndWaitInterceptor (wait page). Neither jar leaves the classpath
regardless of where the tags live.
_2. Core depends on the tags, not only the reverse._ Hard compile-time imports
from core into the would-be plugin:
* StrutsConstants imports components.date.DateFormatter
* StrutsBeanSelectionProvider imports components.UrlRenderer,
components.date.DateFormatter, views.freemarker.FreemarkerManager,
views.util.UrlHelper
* ComponentCacheDestroyable imports components.Component
* util.StrutsUtil and util.URLBean import views.util.UrlHelper /
DefaultUrlHelper
* ExecuteAndWaitInterceptor and DebuggingInterceptor import
views.freemarker.FreemarkerResult / FreemarkerManager
Plus nine bean registrations in struts-beans.xml. A plugin cannot be depended
on by core, so none of this compiles as a straight move.
_3. It is blocked behind WW-4759, which already scoped the same constraint._
WW-4759 established that OSGi Export-Package and the JPMS direction forbid
split packages, so a module cut must be whole-package with FQCNs preserved.
org.apache.struts2.components is exactly such a mixed package: extension-point
interfaces core needs (UrlRenderer, date.DateFormatter,
template.TemplateEngine, TemplateEngineManager) sit beside the 62 tag
components. views.freemarker is the same — FreemarkerResult and
FreemarkerManager are core, views.freemarker.tags is not. This ticket therefore
cannot start before WW-4759's internal de-mixing step.
_4. Goals 2 and 3 were met by other means._ Rendering pluggability arrived
through the TemplateEngine / TemplateEngineManager extension point, consumed by
the javatemplates plugin (the non-FreeMarker option Don wanted) and the
velocity plugin. No alternate base tag library ever emerged in nineteen years.
The Dojo split (WW-1607) is the precedent that did work — for optional tags,
later removed outright.
_5. Recent direction has been the opposite._ Tags were added to core in WW-5256
(Compress, 2025-12) and WW-5640 (WebJar, 2026-07).
h4. Blast radius, for the record
Roughly 25.6k LOC (components 14.0k, views 11.6k — about 23% of core's 108.9k),
136 template resources, the generated META-INF/struts-tags.tld, and seven
plugins importing these packages (javatemplates, velocity, jasperreports7,
jasperreports, tiles, convention, config-browser).
h4. Outcome
Closing as Won't Fix — not because the modularity goal is wrong, but because
"move the tags into a plugin" is not the change anyone would actually make
today.
The underlying idea remains sound and is worth pursuing properly as a lean-core
initiative: dedicated plugins for FreeMarker support, for the tag library and
for JSP support, leaving core as routing and dispatch logic only — so a
REST-only application need not carry JSP or the tags at all. That is Struts 8
scope, sequenced after the API/implementation de-mixing in WW-4759, and it will
get its own ticket rather than continuing under this one.
> Move S2 Tags into a plugin
> --------------------------
>
> Key: WW-2278
> URL: https://issues.apache.org/jira/browse/WW-2278
> Project: Struts 2
> Issue Type: Task
> Components: Plugin - Tags
> Affects Versions: 2.1.0
> Reporter: Ted Husted
> Priority: Major
> Fix For: 7.4.0
>
>
> See tread on list "Should tags be their own plugin?" beginning 5 Oct 2007.
> https://lists.apache.org/thread/xnqqc7617j6clv2rv253qyoj8x6rsmr7
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
