JSGenerator.java CompiledJavaScriptLanguage.java
Also, for what it's worth, although the jxpath jar is in lib/optional there seem to be dependencies on it elsewhere in the core (not just in flow code), e.g:
org/apache/cocoon/components/modules/input/AbstractJXPathModule.java org/apache/cocoon/components/modules/input/JXPathMetaModule.java org/apache/cocoon/components/validation/schematron/SchematronFactory.java org/apache/cocoon/components/validation/schematron/SchematronValidator.ja org/apache/cocoon/transformation/XMLFormTransformer.java
Do you hava a plan for removing the InputModule and XMLForm code from the core as well?
Regards,
Chris
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
I personally don't like it. Adding fake facades for just one thing doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the rhino jar. Please, Carsten, correct me if I'm wrong.
Not exactly. Yes, I don't want to have the rhino jar (and possibly others
only used by flow). But I also want to have meaningful error messages,
if I use flow in the sitemap but does not have "installed" flow. And if, for example, flow would be implemented by "a lot of classes" in
Cocoon, I also don't want to have this overhead.
So, in the end: if I don't want to use flow in my app, I simly don't want
any part of it, neither any jars nor any compiled cocoon flow stuff. :)
Now, if my sitemap doesn't use *any* flow elements, would the jar need to be in the classloader?
I don't think that this is always working. If a flow class in Cocoon directly references/uses one of the rhino classes, then this might cause problems.
So, getting technically: the treeprocessor uses a selector that returns for an element used in the sitemap the corresponding builder. I still think, that this selector could return a dummy implementation, if the required builder class is not available. The flow would still be configured in the tree processor configuration and I can leave out everything of the flow stuff if I don't need it. And in addition: the dummy implementation can give meaningful error messages.
What do you think?
Carsten
Carsten Ziegeler Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
