atom feed142 messages in org.apache.cocoon.devRe: Public/Private classification (wa...
FromSent OnAttachments
80 earlier messages
Torsten CurdtOct 4, 2005 3:47 am 
hepaboluOct 4, 2005 4:00 am 
Joerg HeinickeOct 4, 2005 4:39 am 
Sylvain WallezOct 4, 2005 4:57 am 
Daniel FagerstromOct 4, 2005 5:48 am 
Arje CahnOct 4, 2005 5:55 am 
Stefano MazzocchiOct 4, 2005 9:08 am 
Sylvain WallezOct 4, 2005 9:24 am 
Carsten ZiegelerOct 4, 2005 12:43 pm 
Steven NoelsOct 5, 2005 3:57 am 
Carsten ZiegelerOct 10, 2005 5:02 am 
Joerg HeinickeOct 11, 2005 2:03 pm 
Vadim GritsenkoOct 11, 2005 8:01 pm 
Stefano MazzocchiOct 11, 2005 8:16 pm 
Vadim GritsenkoOct 11, 2005 8:35 pm 
Bertrand DelacretazOct 11, 2005 11:20 pm 
Max PfingsthornOct 12, 2005 12:31 am 
Torsten CurdtOct 12, 2005 12:32 am 
Bertrand DelacretazOct 12, 2005 12:58 am 
Sylvain WallezOct 12, 2005 1:34 am 
Carsten ZiegelerOct 12, 2005 2:21 am 
Daniel FagerstromOct 12, 2005 4:52 am 
Stefano MazzocchiOct 12, 2005 8:58 am 
Stefano MazzocchiOct 12, 2005 9:01 am 
UpayaviraOct 12, 2005 9:20 am 
Vadim GritsenkoOct 12, 2005 9:38 am 
Stefano MazzocchiOct 12, 2005 9:47 am 
Niclas HedhmanOct 12, 2005 10:04 am 
UpayaviraOct 12, 2005 11:57 am 
hepaboluOct 12, 2005 12:43 pm 
Stefano MazzocchiOct 12, 2005 2:09 pm 
Stefano MazzocchiOct 12, 2005 2:18 pm 
Stefano MazzocchiOct 12, 2005 2:20 pm 
Sylvain WallezOct 12, 2005 2:35 pm 
Vadim GritsenkoOct 12, 2005 2:47 pm 
Daniel FagerstromOct 13, 2005 2:41 am 
Reinhard PoetzOct 13, 2005 3:25 am 
Vadim GritsenkoOct 13, 2005 8:07 am 
Ralph GoersOct 13, 2005 9:14 am 
Vadim GritsenkoOct 13, 2005 9:22 am 
Ralph GoersOct 13, 2005 9:44 am 
Daniel FagerstromOct 13, 2005 9:56 am 
Stefano MazzocchiOct 13, 2005 10:01 am 
Stefano MazzocchiOct 13, 2005 10:05 am 
Daniel FagerstromOct 13, 2005 1:59 pm 
Joerg HeinickeOct 13, 2005 2:03 pm 
Joerg HeinickeOct 13, 2005 2:05 pm 
Stefano MazzocchiOct 13, 2005 3:25 pm 
Reinhard PoetzOct 13, 2005 10:57 pm 
Daniel FagerstromOct 14, 2005 2:05 am 
Vadim GritsenkoOct 14, 2005 6:01 am 
Vadim GritsenkoOct 14, 2005 6:06 am 
Stefano MazzocchiOct 14, 2005 11:34 am 
Vadim GritsenkoOct 14, 2005 11:45 am 
Reinhard PoetzOct 15, 2005 1:38 am 
Joerg HeinickeOct 15, 2005 1:40 am 
Joerg HeinickeOct 15, 2005 1:45 am 
Stefano MazzocchiOct 15, 2005 8:53 am 
Stefano MazzocchiOct 15, 2005 9:08 am 
Peter HunsbergerOct 21, 2005 10:12 pm 
Stefano MazzocchiOct 23, 2005 10:39 am 
Peter HunsbergerOct 24, 2005 8:05 am 
Subject:Re: Public/Private classification (was Re: javadocs navigation)
From:Daniel Fagerstrom (dani@nada.kth.se)
Date:Oct 14, 2005 2:05:43 am
List:org.apache.cocoon.dev

Stefano Mazzocchi wrote: ...

Daniel,

let me repeat: I don't care about precision and elegance and completeness, I care about usability.

That is great Stefano, you find the the 673 classes and interfaces that need to be marked public or private, with usability in mind here: http://wiki.apache.org/cocoon/PublicAPIClasses. Go ahead and mark them if you haven't allready.

I am thinking at flow users that want to use java components to do their stuff.

I read your previous mail:

Here's my principle: since I write all my business logic in flow, I want to know which ones are the things that I can expect to call from flow.

Although Cocoon doesn't have the marked share that we would wish, we still have more users than you to care about;) Some of the users write custom sitemap components as an example, I think they need good JavaDoc as well.

Anyway, to get anywhere you need to be a little bit more concrete about what you think should be part of the public API for flow users. Classes mentioned in http://cocoon.apache.org/2.1/userdocs/flow/api.html obviously need to be part of the API: Request, Response, Session, Context, Logger, WebContinuation. PipelineUtil and as you mentioned SourceUtil and SourceResolver. Anything more?

They should *NOT* care about org.apache.cocoon.xml.XMLPipe.

In some cases users don't need to care about what classes or interfaces an API class extends or implements. For such cases we need to propagate down all documentation from the parent classes.

The other kind of dependency I looked at was what interfaces and classes the methods of the "public API" returns and have as arguments. I would find it rather frustrating to implement an method in an interface without having documentation of the types of the parameters, so I don't think that completeness is an unreasonable requirement. But maybe I'm the only one, and in that case we don't need to care as I read the source anyway ;)

Also I think it is quite good idea to do dependency analysis of our interfaces (although I need a better tool), as it help us to find dependencies that shouldn't be there. Most of the dependencies I found seemed rather reasonable, my main question is about ProcessingExceptions dependency on various classes and interfaces in org.apache.cocoon.util.location, there seem to be a lot of interdependencies in that package. But maybe I got some dependencies from the tool that wasn't on the acual API level. I haven't anlyzed what is going on in detail.

/Daniel