Splitting tapestry-core into sub-modules in non-trivial, there's a bit of a rat's nest of dependencies between components and services and other components and other even hard to quantify things!
On Thu, Jan 20, 2011 at 4:49 PM, Bob Harner <[email protected]> wrote: > 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] >> > -- 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]
