Hi Roy, Yes, you are right, the only reason, why we have this in our repository is to hack the output stuff, such that the classes go into the repository. Unfortunately, there is no proper OOP way of doing this as part of it is hard coded into Jasper and other parts have not the correct visibility.
I am as unhappy with this as you are. I am currently considering two options to fix this: (1) Not writing the classes to the repository at all. This way, we can just use plain Jasper with our own CompilationContext. This has the drawback that removing classes remotely is difficult (it is not required but very helpfull sometimes). (2) Copy the classes to the repository after successfull compilation to the file system. This gives us the support for remote class removal at the expense of having to copy them. Regards Felix Am Montag, den 26.11.2007, 14:44 -0800 schrieb Roy T. Fielding: > On Nov 26, 2007, at 8:15 AM, [EMAIL PROTECTED] wrote: > > SLING-98 Migrate JSP scripting support > > + plus include Jasper Compiler and EL implementation > > Ouch. Just out of curiosity, why do we need the source of jasper? > Is it to replace the back-end storage bits with JCR? Would it be > possible to use some OOP to override the specific storage classes > within jasper instead of building the entire tree? If not, then > I think we should rename jasper to sling/ssi4j (or something) to > avoid the library binding clashes. > > ....Roy
