Disappointed about avalon usage

[Michael Lipp]

Hi,

having studied the avalon concepts some time ago, I just came upon a 
point where I wanted to take advantage of them and failed. Let me tell 
you why.

I have a problem with filenames of Java files generated from XSPs 
becoming too long. So I tracked processing down and found that if I 
modified ProgramGeneratorImpl.getNormalizedName a bit, I could fix this. 
In old times, I would have had to patch ProgramGeneratorImpl and put in 
in the classpath before cocoon.jar or replace it in cocoon.jar.

But we have Avalon. And ProgramGeneratorImpl is a component. So I 
thought instead of that nasty patching, I simply write a new component 
and change the configuration. GetNormalizedName is private, so I could 
not derive and override in the new class, but of course, this is 
perfectly legal, and I basically copied the code in my new class.

But when I tried to compile my new class, I found that it needs access 
to GeneratorSelector.addGenerator (from the same package) and that this 
method is protected! :-(

And GeneratorSelector is itself a component, so you cannot say that it 
is an intimate helper of ProgramGeneratorImpl. What now? Of course, I 
could have copied GeneratorSelector in my new package as well, but where 
 may this end...

So I went (half) back to the old times: I have a new class, but I had to 
put this class in package 
org.apache.cocoon.components.language.generator kind of "spoiling" the 
original distribution after all.

I admit, I have no great experience with Avalon. But to me it seems that 
the moral of this is that anything designed as an Avalon component 
should not use package visible methods of other classes unless those 
classes are only very private helpers. Otherwise you do not really get 
configurable components.

 - Michael