Don't be too harsh on the 3rd party developers; we're still working out what needs to be public and how.
We take the "internals can change at any time" vow seriously, which is painful for any 3rd party library developers, as sometimes you have to dive into the internal side to accomplish things. I encourage any 3rd party library developer who does use internals to get a dialog going on the mailing list (and then on JIRA) so that necessary, stable, public interfaces can be created. On Tue, Oct 19, 2010 at 6:08 AM, Vangel V. Ajanovski <a...@ii.edu.mk> wrote: > I don't think it's a framework problem but Chenillekit problem. > Imagine for example you are building an application with Oracle database > via JDBC but you are not using the regular published JDBC interfaces > that everybode else does, but some internal class that is part of the > exact implementation of the JDBC oracle driver. And Oracle decides to > implement it's own driver in a different way so your application will be > dead. Not a problem of Oracle. > > On 10/19/2010 02:24 PM, Inge Solvoll wrote: >> This is a big problem for third party libraries. I already removed equanda >> from my application to avoid these situations, now I'm tempted to let >> chenillekit go too. I only use it to a very limited extent. It's been a >> couple of months now with a rather stable 5.2, third parties should have had >> plenty of time to sort out trivial compatibility issues. >> >> I know you guys are all volunteers, and you do a great job. This is a >> framework issue too, that version bumps cause third party libs to stop >> working... > > > -- 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
