cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Public/Private classification (was Re: javadocs navigation)
Date Sat, 15 Oct 2005 08:38:35 GMT
Stefano Mazzocchi wrote:
> Reinhard Poetz wrote:
>> Stefano Mazzocchi wrote:
>>> Daniel Fagerstrom wrote:
>> [...]
>>> Daniel,
>>> let me repeat: I don't care about precision and elegance and 
>>> completeness, I care about usability.
>>> I am thinking at flow users that want to use java components to do 
>>> their stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe.
>> Not all Cocoon users are flow users only ...
> Reinhard, how many cocoon users have ever implemented 
> org.apache.cocoon.xml.XMLPipe?
> My point is not about flow, is about brevity over completeness.


TBH I have no strong opinion whether XMLPipe should be part of the public 
_documentation_.  Of course it is part of the _public API_ because otherwise 
you're not able to implement e.g. a transformer, but I'm sure that you know this 
as you're the author of this interface ;-)

I only doubt that the proposed way of how to find the classes and interfaces, 
that should become part of the public documentation, will lead to success. Do 
you guys really think that many people will start to evaluate ~670 classes and 
interfaces? And if yes, Daniel, Vadim you and me can't agree whether the 
interface XMLPipe is public or not. So I'm not really optimistice about the 
outcome as we have to discuss the other 669 classes and interfaces too.

I'm just with Daniel that we should talk about the principles of what is public 
and private first.
After agreeing on them one person can move the public interfaces and classes 
into a seperate directoy and then we can create a cocoon-api.jar and can create 
javadocs out of it.

If you or others think that the "wiki way" of tagging classes is more successful 
(and faster), please go for it. Believe me, it's not my intention to block this, 
especially as I don't have the time to work on the alternative within the next 
3-4 weeks.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message