I see,
but what is the strategy if there is a feature request for tapestry
which is covered by a third party module already? Could it still be that
it will be reimplemented to tapestry-core or will the feature-request
most of the time be referred to the third party module?
From framework usage point of view it could be confusing/tedious to
include too much tapestry third-party stuff. Of course it is always
tricky to judge what is core stuff...
Howard Lewis Ship schrieb:
That's part of the reason why we're setting up Tapestry360
(http://tapestry.formos.com), as a secondary space for Tapestry
projects that can't be part of the project distribution itself, while
providing a more consistent set of resources (Bamboo CI, JIRA,
Confluence Wiki).
On Mon, Feb 2, 2009 at 2:44 AM, manuel aldana <ald...@gmx.de> wrote:
Hi,
what is the general strategy for tapestry when it comes to using own modules
vs. adding "similar-behaving" third party ones?
take the sample, where I need a asset-type which is based on URL (currently
tapestry supports only context and relative path). As mentioned in
https://issues.apache.org/jira/browse/TAP5-423 chenille-kit provides this
already. Never the less I see this as a core module which should be housed
in the tapestry-core module.
It is always a good idea to not reinvent the wheel and the pluggable module
framework of tapestry is great. But when including "core-things" through
third party modules problems occur:
-quality (test coverage, steady release-cycles, javadocs) is not maintained
by tapestry-development team
-ending up with tons of tapestry-third party module inclusions (getting even
more transitive dependencies) though just a little fraction is used
So which strategy does/should tapestry follow?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
