The only difference being that when refactoring the internals, tapestry-hibernate will be refactored along with tapestry-core. Because ChenilleKit is external, it may suffer when tapestry-core internals are refactored. There's no easy solution for this, beyond a dialog of what internal services need to be exposed publicly, preferably with a stable public facade (rather than just making everything public).
On Tue, Jul 20, 2010 at 12:40 AM, Massimo Lusetti <mluse...@gmail.com> wrote: > On Mon, Jul 19, 2010 at 11:18 PM, Pierce Wetter <pie...@paceap.com> wrote: > >> >> On Jul 15, 2010, at 11:33 PM, Andreas Andreou wrote: >> >>> Pierce raises a valid point though - tapestry-hibernate ideally shouldn't >>> need >>> to depend on internal core / ioc classes >> >> Exactly! Is that a bug in tapestry or tapestry-hibernate? > > Well that's definetely not a bug. Andreas talked right, he said > "ideally", but tapestry-hibernate is a library around (very near) the > core framework so if it choose to depend on an "internal" > implementation it's a library's owner choice. What has not to be done > is to public (in any way) the internal API on which the module/library > depends on. > This is the same choice ChenilleKit as done since day one. > > Cheers > -- > Massimo > http://meridio.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-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: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
