So, this went out about a week ago, and the guidelines only cover as far as
publishing a proposal on the Jakarta General List.  What is the next step?

So far, I haven't seen any real negative responses, and a lot of positive
ones (I think a lot of ex-WebObjects folks are lurking about :-)).  I could
summarize in more detail if that would be helpful.  Obviously, the PMC
hasn't really weighed in.  Again, what next?

----- Original Message -----
From: "Ship, Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 18, 2002 10:29 AM
Subject: [PROPOSAL] Tapestry joins Jakarta


Background

Tapestry, currently housed at the SourceForge (http://tapestry.sf.net), is
component-based web application framework.  Tapestry falls generally into
the pull-MVC model of development.

Tapestry is designed specifically around the creation of completely
re-usable components.  Components can easily be packaged into libraries and
distributed as Jar files, even when they contain assets such as image files
and stylesheets.

Tapestry is organized around an abstraction that isolates
application-specific logic from the details of the servlet API, such as
HttpSession, request, response, URLs and query parameters.

Tapestry is highly pluggable, allowing any and all behavior to be customized
by subclassing appropriate base classes.

Tapestry is specifically not a JSP taglib, though future enhancements
(scheduled for the next release) will allow it to partially act as one.
Tapestry uses its own method for instrumenting HTML that is extremely
non-obtrusive (it still previews properly in a WYSIWYG editor).  Tapestry
has well specified, separate roles for HTML producers and Java developers,
and allows them to work together without interfering with each other.

The goal of Tapestry is to shift much of the burden of developing web
applications onto the framework, and free the developer to work cleanly and
effectively without concern for the many small details of web application
development.  The primary function of Tapestry is the automatic creation of
URLs by the framework, facilitating a fine-grained dispatch model.  The
bird's-eye view is that, in Tapestry, actions (such as clicking a link, or
submitting a form) are associated with a particular component and, through a
simple delegation system, a particular bit of user code.  There is no global
registry of actions, as in Struts, and it's easy to create reusable
components that define their own behaviors (in terms of links or forms),
independent of the containing page.

Tapestry applications can be extremely sophisticated with surprising little
code.

Tapestry includes a significant amount of documentation describing its
strengths and features in great detail, available at http://tapestry.sf.net.
Live demos, a great collection of user quotes, extensive documentation (HTML
and PDF) and a recent code coverage report are all online.

Tapestry has been an open-source project on SourceForge since June 2000.
Milestone releases (such as 2.1 in July, or the just-released 2.2) result in
6K - 7K downloads (increasing by over 1K downloads with each successive
release).  Tapestry has averaged over 3000 downloads a month during 2002,
with peaks above 8K/month.

Tapestry would benefit from Jakarta in terms of greater exposure and
acceptance, but also in terms of better infrastructure, such as Bugzilla and
Maven.

Tapestry is currently in the Java package net.sf.tapestry; this could easily
be changed to org.apache.tapestry.

Tapestry is currently licensed under the LGPL, but relicensing under the
Apache license is completely acceptible.  The main criteria used when
selecting a license three years ago was that Tapestry be open source and
reusable even in proprietary software, and both licenses ensure that.

In order to spur discussions, I've worked through the list of criteria and
warning signs (as per http://jakarta.apache.org/site/newproject.html).
Pardon the use of third person in reference to myself (it seemed appropriate
for prose that will likely be cut and pasted frequently).

Criteria

Meritocracy:  Tapestry is currently a benign dictatorship, but it has been
Howard Lewis Ship's intention, even prior to considering a move to Jakarta,
to organize around more democratic principals.

Community:  Tapestry has a modest, but very active community, centered
around a mailing list (approx. 170 members) and the Tapestry Wiki
(http://tapestry.sf.net/wiki).  The Tapestry mailing list has an
exceptionally good signal-to-noise ratio; discussions typically revolve
around planning new extensions to the framework, creating new components and
documentation, and diagnosing developer issues.

Core Developers.  The principal developer for the life of the project is
Howard Lewis Ship, he will continue his involvement with Tapestry
indefinitely.  Richard Lewis-Shell and Mind Bridge are frequent contributors
of components and bug fixes.  Neil Clayton and Malcolm Edgar provide some
code and significant amounts of documentation.  Geoff Longman has created an
excellent plugin for the Eclipse IDE (as a separate project).  Several other
developers have contributed bugs fixes, components or documentation in the
past.

Alignment:  Tapestry makes use of the ORO, commons-lang and commons-logging
packages internally.

Scope:  Tapestry is entirely a server-side framework, well aligned with the
overall goals of the Jakarta project.

Warning Signs

Orphaned products.  Tapestry is far from orphaned, it was originally
conceived and executed specifically as an open-source project.

Inexperience:  Howard Lewis Ship has been coding, documenting, mentoring and
managing this open source project for nearly three years.

Homogeneous Developers:  All of the committers listed above came to the
project entirely through appreciation of its qualities (none are known to
Howard Lewis Ship except through Tapestry); representatives from Canada,
England, Australia and New Zealand are included; other contributors
represent South America and Asia (no records have been kept on contributor's
country of origin).  This is just the opposite of the "smoke filled room".

Reliance on Salaried Developers.  Tapestry is largely developed during free
time. Many contributions are developed by consultants to address specific
needs of their clients, then modularized and provided back to the community
(for example, Geoff is developing a workflow management subsystem for
Tapestry that may be released into the framework proper when completed).
Increasingly, developers are finishing projects with Tapestry and
contributing components created for those projects back into the framework.

No ties to other Apache Products:  As stated above, Tapestry makes use of
the ORO and commons packages and has numerous places where greater
integration with Jakarta could occur.  It is servlet container agnostic,
working well with Tomcat, Jetty, Resin and others.

Fascination with Apache Brand:  Tapestry has been, and always will be an
open-source project.

Overlap with Turbine

Turbine has a similar model to Tapestry, but uses more levels of abstraction
(Layout, Module and Navigation where Tapestry simply has Component).
Turbine provides more choices for rendering responses, whereas Tapestry
supports only its own HTML template format.

The focus of the two projects is somewhat divergent.  Turbine is a
service-oriented where Tapestry is component-oriented.  Turbine provides a
larger toolkit (in the form of services) for aspects of the application not
related directly to the presentation layer.  Tapestry provides more
flexibility and power in the presentation layer but doesn't provide any
other services (such as scheduling, database access, security, etc.).

Many Tapestry developers are using Tapestry for the presentation layer, but
leveraging the many Turbine services (especially Torque).

Summary

Tapestry is a mature, powerful framework whose focus aligns well with the
overall scope of the Jakarta project.  Both Tapestry and Jakarta would be
well served by moving Tapestry under the Jakarta umbrella.

--
Howard Lewis Ship
[EMAIL PROTECTED]
http://tapestry.sf.net


--
To unsubscribe, e-mail:   <mailto:general-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:general-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>

Reply via email to