Josh's approach sounds ideal to me. Maven makes it easy to aggregate many
small pieces, but splitting up a monolithic core only gets harder over time.
On Jan 20, 2011 6:38 PM, "Robert Zeigler" <[email protected]>
wrote:
> +1 to leaner, lighter-weight modules, and a maven dependency that has all
(almost?) of the tapestry modules as dependencies. Becomes easier to pick
and choose at that point; you can explicitly include a small number of
modules, or depend on tapestry-kitchensink and exclude a few pieces that you
don't want/need. The quickstart archetype would either add all of the
"important" dependencies, or else add a dependency on the "kitchen sink".
>
> Robert
>
> On Jan 20, 2011, at 1/205:31 PM , Josh Canfield wrote:
>
>>> So what are the advantages/disadvantages of having another module at
>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>> tapestry-core?
>>
>> Bloat is a disadvantage to continue putting things into tapestry-core,
>> both from a size of dependency as well as a maintenance standpoint.
>>
>> You can build the tapestry-kitchensink (not really what I would
>> consider core) module that has compile dependencies on everything, but
>> mostly I'd like to include the leanest meanest dependencies possible.
>>
>> To the extreme, I'd go so far as to say that I'd like to separate out
>> * tapestry-ioc - IOC container
>> * tapestry-servlets - Servlet request processing
>> * tapestry-templates - Component/page rendering code (t:block,
>> t:container, t:body, etc... i.e. non-component based template
>> elements)
>> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any,
t:zone)
>> * tapestry-forms - Form components (t:form, t:textfield, etc.)
>> * tapestry-beaneditor - BeanEditor components
>> * tapestry-gridview - Grid components
>> * tapestry-usermessages - User message tracking components
>> * etc.
>>
>> Deciding how large a feature needs to be in order to get it's own
>> module is debatable. (AjaxFormLoop?)
>>
>> I'm working on a project now that would just use tapestry-(ioc |
>> servlets | hibernate | resteasy) (and tapestry-monitoring, but that's
>> in the works!).
>>
>> There _is_ a value to having a simple single dependency that a
>> Tapestry and possibly Java newbie could use to rip through a tutorial,
>> write the tutorial such that a single entry pointing at the
>> kitchen-sink module in the pom and all the transient dependencies are
>> sucked down with it.
>>
>> An example of a project with lots of extensions is the Restlet API.
>> While the docs in general are not great, they have an impressive list
>> of extensions:
http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet.html.
>>
>>
>> Josh
>>
>> On Thu, Jan 20, 2011 at 12:52 PM, Howard Lewis Ship <[email protected]>
wrote:
>>> So what are the advantages/disadvantages of having another module at
>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>> tapestry-core?
>>>
>>> To me, the idea of saying "if you want to present confirmation to a
>>> user, just use the AlertsManager and Alerts component" is more
>>> satisifying in a tutorial than saying "create a flash-scoped message
>>> field, etc., etc.,". However, if the AlertsManager is in a optional
>>> library, I might not feel as good about referencing it in a tutorial
>>> compared to if it was in tapestry-core. And if we end up effectively
>>> mandating the user of tapestry-stdllib, how valuable is it separate
>>> from tapestry-core.
>>>
>>> Alternately, if we have a stdlib, do we move some of our existing
>>> components and mixins out of core?
>>>
>>>
>>> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
>>> <[email protected]> wrote:
>>>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <
[email protected]>
>>>> wrote:
>>>>
>>>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>>>> library (or libraries) beyond core.
>>>>>
>>>>> My gut tells me to pull as much of the system apart into independent
>>>>> modules as possible. Smaller is better, easier to understand, easier
>>>>> to test.
>>>>
>>>> Please do it as a Tapestry subproject (tapestry-morecomponents?)
instead of
>>>> TapX or other external packages. It seems to me that people consider
>>>> anything outside the Tapestry project, even being linked from there, as
not
>>>> part of the out-of-the-box experience. Something like "feature X is so
>>>> important, but I need a third-party package to have it" (something used
a
>>>> lot to criticize JSF).
>>>>
>>>> --
>>>> Thiago H. de Paula Figueiredo
>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant,
developer, and
>>>> instructor
>>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>>> http://www.arsmachina.com.br
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
