Stefano Mazzocchi wrote:
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).
It's not complete - at least InputModule interface is missing, may be something
else. But it is a good start.
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 am not sure everything declared in the cocoon.xconf is public API, although
most of the stuff is, such as xml parser, xslt processor, runnable manager, etc.
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.
Users that write *own* components *do* care about XMLPipe.
Vadim