I would consider spliting based on criteria like js libs. The reason being why would I want to carry over 300~500KB worth of jar for prototype when i'm not using it?
On another note, i'm not sure why tapestry-upload needs a separate subproject (one can manually exclude commons-fileupload) As Howard said, it's probably not trivial to split core, esp. in so many pieces and indeed i too believe those where a lot! But that doesn't mean everything new should reside in core either. In the user messages case, what really caught my eye was the plan for js integration of it. While that makes total sense, it also ties the core even more to prototype (while as i said above i'd strive for the opposite direction). Of course it's always easy to talk and contribute no code (and i haven't) but the plan's for this to change. Another issue about separate subprojects is separate releases (and versions). As i understand it, most devs are against this - but it also feels this kills one of the benefits of separate projects. Does anyone see any value in making this work? How about building something like an appstore for components/projects? On Fri, Jan 21, 2011 at 01:31, Josh Canfield <joshcanfi...@gmail.com> 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 <hls...@gmail.com> 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 >> <thiag...@gmail.com> wrote: >>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <joshcanfi...@gmail.com> >>> 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: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> 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: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry PMC / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
