>From a technical point of view, some of the code in T5 can only be realistically tested using integration tests (i.e. Selenium, etc.). Splitting into smaller chunks hurts there, because (for the command line build, at least) its hard to track code coverage of tests between modules. Thus there's a bit of code in tapestry-core that can only be tested by the integration test inside tapestry-components.
Tapestry and T5 IoC are not like other frameworks ... its designed for you to be able to precisely override selected services and other infrastructure, so the benefit of breaking into smaller pieces is signifantly diminished. On 10/23/07, Christian Gruber <[EMAIL PROTECTED]> wrote: > > Additionally, smaller pieces means cleaner dependencies, because you > can have circular dependencies within a jar, but by separating things > out, you force cleaning out such things, which results in better > usability. (well, again, if you're using something that disallows > circular dependencies, like maven). > > Also, smaller code chunks tends to improve testability, because you > have smaller independent units of code. > > But the big thing, as Paul mentions, is to reduce the volatility of > the versions themselves. If hls ships 5.0.9, but all the 3rd party > components are linked against 5.0.8, instead of against some blah- > api-5.0 which is stable, then you have to wait for the component > vendor to update it. I mean you can always do it yourself (which I'm > doing in the short term with the redijedi stuff), but in my experience > in fortune-500 companies, they have build regulations which do not > allow such things. Only things that have been tested and put into a > local "safe" repository can be used, and making six updates to that > would cause bureaucratic hell and be problematic for a deadline, vs., > say, just updating the implementation jar or the "official" components > jar. > > Or simply - reduce the breadth of the impact of change. > > Christian. > > On 23-Oct-07, at 8:47 AM, Paul Cooley wrote: > > > As long as maven is used to handle the dependencies for you, this is > > actually the better way to do it. Reason being, if there's a bugfix > > in say > > a component, it doesn't require the entire stack to be rebuilt. > > Instead, > > interim releases of certain modules can be made for rapid > > development/release rather than having to build/release the entire > > stack to > > address critical bug fixes in one module. Think microsoft service > > pack and > > you get an idea of the kind of hell that can result. > > > > Just my 2 cents. > > > > On 10/23/07, Chris Lewis <[EMAIL PROTECTED]> wrote: > >> > >> A user's perspective: I /loathe/ dependency hell of all > >> incarnations - > >> jar/dll/rpm whatever. They make life difficult and far from > >> enjoyable. I > >> don't know that this conversation is leading down the path of > >> creating > >> this kind of situation, but I want to preemptively speak against > >> anything that smells of it. Ease of use, in my opinion, as > >> difficult and > >> worthy a goal as software usability. As long as remains an obvious > >> goal > >> on the forefront, great, no problem. > >> > >> sincerely, > >> chris > >> > >> Fernando Padilla wrote: > >>> I will support this idea. > >>> > >>> specially if components are broken up too, base components, html > >>> components, etc. > >>> > >>> Christian Gruber wrote: > >>> > >>>> Hi, > >>>> > >>>> I realize that -annotations has already been converted, but I'm > >>>> wondering if it wouldn't help reuse and modularity to take the > >>>> raw APIs > >>>> (key interfaces) and some other bits, including components and > >>>> separate > >>>> it from core. This came from looking at the redijedi stuff and how > >> it's > >>>> linked to 5.0.5. It seems to me that there's some raw API stuff > >>>> that > >>>> won't change between minor versions (now) and that 3rd party > >>>> component > >>>> libraries or other things would be able to depend on those without > >>>> having to re-set or nudge versions numbers every time a bugfix > >>>> release > >>>> is made. > >>>> > >>>> Christian. > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >>> > >>> > >>> > >> > >> > > > > > > -- > > Gotta find my destiny, before it gets too late.-- Ian Curtis > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
