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 > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
