cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Public/Private classification (was Re: javadocs navigation)
Date Thu, 13 Oct 2005 22:25:42 GMT
Daniel Fagerstrom wrote:
> Daniel Fagerstrom wrote:
> ...
> 
> To illustrate what I meant I tried to follow the dependencies for the 
> sitemap component interfaces.
> 
>> Cocoon API
>> ==========
> 
> 
> ...
> 
>> So what is the Cocoon API? All interfaces used in 
>> cocoon-core-sitemap.xconf are part of the Cocoon API: Generator, 
>> Transformer, Serializer, Reader, Matcher, Selector, Action, 
>> ProcessingPipeline. Then the interfaces refered to in the Cocoon API 
>> must be part of the API as well by transitive closure. So here we get 
>> various exceptions, SitemapModelComponent, XMLPipe, XMLProducer and 
>> much more. The ObjectModelHelper with dependencies is also part of the 
>> API.
> 
> 
> 
> Starting with:
> 
> org.apache.cocoon.acting.Action
> org.apache.cocoon.generation.Generator
> org.apache.cocoon.matching.Matcher
> org.apache.cocoon.reading.Reader
> org.apache.cocoon.selection.Selector
> org.apache.cocoon.serialization.Serializer
> org.apache.cocoon.transformation.Transformer
> 
> (I removed the ProcessingPipeline as it dependencies seem to explode to 
> all kinds of internal classes, we need to polish that interface if it 
> should be considered public)
> 
> These interfaces depends on:
> 
> org.apache.avalon.framework.parameters.Parameters
> org.apache.cocoon.ProcessingException
> org.apache.cocoon.environment.Redirector
> org.apache.cocoon.environment.SourceResolver
> org.apache.cocoon.sitemap.SitemapModelComponent
> org.apache.cocoon.sitemap.SitemapOutputComponent
> org.apache.cocoon.sitemap.PatternException
> org.apache.cocoon.xml.XMLConsumer
> org.apache.cocoon.xml.XMLPipe
> org.apache.cocoon.xml.XMLProducer
> 
> which depends on (skipping the avalon dependencies)
> 
> org.apache.avalon.framework.CascadingException
> org.apache.cocoon.util.location.LocatedException
> (org.apache.cocoon.util.location.LocatedRuntimeException)
> org.apache.cocoon.util.location.Location
> org.apache.cocoon.util.location.MultiLocatable
> 
> and again
> 
> org.apache.cocoon.util.location.Locatable
> org.apache.cocoon.util.location.LocatableException
> org.apache.cocoon.util.location.LocationImpl
> org.apache.cocoon.util.location.LocationUtils
> org.apache.commons.lang.exception.NestableException
> org.apache.commons.lang.exception.ExceptionUtils
> 
> ===
> 
> The object model helper must also be considered to be part of the Cocoon 
> API, there we get the dependencies:
> 
> org.apache.cocoon.environment.ObjectModelHelper
> 
> -->
> 
> org.apache.cocoon.environment.Context
> org.apache.cocoon.environment.Request
> org.apache.cocoon.environment.Response
> 
> -->
> 
> org.apache.cocoon.environment.Cookie
> org.apache.cocoon.environment.Session
> 
> ===
> 
> This should be a complete list of the public sitemap component API (I 
> did the dependency analysis semi automatically with 
> http://depfind.sourceforge.net/, so I could have done some mistakes).
> 
> ===
> 
> A similar list for the public component API, starting from 
> cocoon-core.xconf would also be a good idea. But I would need a better 
> tool than depfind for that excercise, any suggestions?
> 
> ===
> 
> I'm not suggesting that we can find out the Cocoon API automatically. 
> But given that we want a particular set of interfaces in the public API 
> and JavaDoc, I think it would be rather strange if we didn't made all 
> the o.a.c interfaces and classes that these interfaces depends on also 
> part of the public API.

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.

-- 
Stefano.


Mime
View raw message