Nicola Ken Barozzi wrote:
+1 for mock objects.
I've made a jsp block on my hd and tried to compile it, when I got six exceptions about class not found. Here's one:
C:\jbprojects\xml-apache\xml-cocoon2\build\cocoon\blocks\jsp\src\org
\apache\cocoon\components\jsp\JSPEngineImplWLS.java:157: package weblogic.servlet.internal does not exist
Eeeeck, this would be a block with a conditional compilation upon a package I don't have... do I need weblogic to compile it? Because is I don't compile the class, the block is not complete, and it's not good.
On the other hand, I can make a mock object to compile the classes, but then I have a block that has an optional dependency, and don't know how we will make the dependency resolution work with optional stuff.
So IMHO the real options are:
1) use mock objects
2) divide the block in two: jsp-block and jsp-weblogic-block
I prepend for (1), but it still doesn't satisfy me completely... heeeelp!
I was recently thinking about this particular problem of dependencies on libraries that we cannot put in Cocoon's CVS : this is a major problem, as we have a lot of source files that are never compiled if we don't place the required non-redistributable libraries in lib/local.
This means that we may release a version where some source files don't even compile !!
So mock objects seems to be a good solution, provided that the compilation classpath puts libraries in lib/local _before_ the mock classes, so that real classes are used when they're present.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
