You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by manuel aldana <al...@gmx.de> on 2009/02/02 11:44:30 UTC
[T5] strategy of tapestry-core vs. third-party modules
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] strategy of tapestry-core vs. third-party modules
Posted by manuel aldana <al...@gmx.de>.
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 <al...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] strategy of tapestry-core vs. third-party modules
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <al...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org