Daniel Fagerstrom wrote: ...

To illustrate what I meant I tried to follow the dependencies for the sitemap component interfaces.

...

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.