You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leif Mortenson <le...@silveregg.co.jp> on 2002/01/25 05:38:37 UTC
JavaDocs for Excalibur Scratchpad classes
Currently, the classes in the scratchpad are not being included in the
building of javadocs. Should they be? I found it quite useful to modify
my local build to include them with the rest of the classes, however
that may be confusing to most users.
Another option would be to have another build/scratchpad-javadocs and
docs/scratchpad-api directories containing the scratchpad javadocs.
Preferences?
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Some silly Clarifications
Posted by vinay nair <vi...@yahoo.com>.
Hi berin,
Thanks a lot.
Missed the system/* package under
excalibur-scratchpad.
But the reason i wrote the mail was to clarify the
a code snippet the shows a ComponentHandler
being added to the ComponentManager with the
addComponent(..) call.
(pg 37 of pdf or
http://jakarta.apache.org/avalon/developing/implementing.html)
.
That should be typo if i am not wrong .
am I ?
V i n a y.
--- Berin Loritsch <bl...@apache.org> wrote:
> vinay nair wrote:
>
> > Hi,
> > While reading the "implementing the dream" chapter
> ,
> > (page 37 of the pdf version)
> > i found a code snippet adding ComponentHandler
> > instance with the DefaultComponentManager .
> > Of what i have seen so far in the code ,
> > ComponentHandler is not Component.
> > am I overlooking something in arriving at this
> > conclusion?
>
>
> ComponentHandler is a wrapper to handle the logic of
> whether
> the Component should be accessed via Factory method,
> Pooled
> Component, or singleton (ThreadSafe).
>
> So you are right. ComponentHandler is not a
> Component.
> You use it to get your hands on one--without
> worrying about
> the details of how the Component should be managed.
>
>
>
> > With Loggable interface deprecated would be it be
> > advisable to make the excalibur.component.*
> > classes also extend AbstractLogEnabled instead
> > of AbstractLoggable. ?
> >
> > Maybe here too i am missing something all-together
> .
>
>
> Unfortunately, we do have to maintain backwards
> compatibility.
>
> There is a new package in scratchpad which will
> properly separate
> the ComponentManager interface from the Container
> (unlike the
> ExcaliburComponentManager which acts as both).
>
> That will be LogEnabled clean, and will not support
> Loggable
> components.
>
>
>
>
>
> ----------------------------------------------------
> Sign Up for NetZero Platinum Today
> Only $9.95 per month!
> http://my.netzero.net/s/signup?r=platinum&refcd=PT97
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Some silly Clarifications
Posted by Berin Loritsch <bl...@apache.org>.
vinay nair wrote:
> Hi,
> While reading the "implementing the dream" chapter ,
> (page 37 of the pdf version)
> i found a code snippet adding ComponentHandler
> instance with the DefaultComponentManager .
> Of what i have seen so far in the code ,
> ComponentHandler is not Component.
> am I overlooking something in arriving at this
> conclusion?
ComponentHandler is a wrapper to handle the logic of whether
the Component should be accessed via Factory method, Pooled
Component, or singleton (ThreadSafe).
So you are right. ComponentHandler is not a Component.
You use it to get your hands on one--without worrying about
the details of how the Component should be managed.
> With Loggable interface deprecated would be it be
> advisable to make the excalibur.component.*
> classes also extend AbstractLogEnabled instead
> of AbstractLoggable. ?
>
> Maybe here too i am missing something all-together .
Unfortunately, we do have to maintain backwards compatibility.
There is a new package in scratchpad which will properly separate
the ComponentManager interface from the Container (unlike the
ExcaliburComponentManager which acts as both).
That will be LogEnabled clean, and will not support Loggable
components.
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Some silly Clarifications
Posted by vinay nair <vi...@yahoo.com>.
Hi,
While reading the "implementing the dream" chapter ,
(page 37 of the pdf version)
i found a code snippet adding ComponentHandler
instance with the DefaultComponentManager .
Of what i have seen so far in the code ,
ComponentHandler is not Component.
am I overlooking something in arriving at this
conclusion?
If i am not ,
would the recommended way to register a component
within a ContainerComponent be by using the
ComponentManager.addComponent(role,class,configuration)
call on the ComponentManager received by the
COntainerComponent during its composition.
With Loggable interface deprecated would be it be
advisable to make the excalibur.component.*
classes also extend AbstractLogEnabled instead
of AbstractLoggable. ?
Maybe here too i am missing something all-together .
regards,
V i n a y.
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JavaDocs for Excalibur Scratchpad classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Leif Mortenson wrote:
> Peter Donald wrote:
>
>> On Fri, 25 Jan 2002 15:38, Leif Mortenson wrote:
>>
>>> Currently, the classes in the scratchpad are not being included in the
>>> building of javadocs. Should they be? I found it quite useful to modify
>>> my local build to include them with the rest of the classes, however
>>> that may be confusing to most users.
>>>
>>
>> How about adding them into the main javadocs target but grouping them
>> in their own category if possible. Something like
>>
>> <group title="Scratchpad Packages">
>> <package name="org.apache.excalibur.foo"/>
>> <package name="org.apache.excalibur.bar"/>
>> </group>
>> etc?
>>
>> That would give people ample warning that they are experimental but
>> would still allow one set of javadocs to be generated.
>
>
>
>
> Good idea, but the problem is that there are several packages which
> contain both scratchpad and excalibur classes. (How do you refer to the
> non-excalibur classes).
>
> That would also be tough to maintain as all new packages would have to
> be added to build.xml when the were created.
>
> How about I create a second javadocs directory called
> build/scratchpad-javadocs until we come up with a better solution. It
> would be nice to have the links between the scratchpad and excalibur
> javadocs. But I think that it would be more confusing to have them
> together.
I went ahead and implemented this and checked it in. It is easy to
change :-)
Noticed one problem though. The packages which have files both in
Scratchpad and the main Excalibur source trees include some of the main
Excalibur classes in the scratchpad javadocs. They don't include any
text, so they must be being built from the class files.
Could be a little confusing, but at least there are javadocs on the
scratchpad now.
Let me know if you have any ideas though.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JavaDocs for Excalibur Scratchpad classes
Posted by Peter Donald <pe...@apache.org>.
On Sun, 27 Jan 2002 02:28, Leif Mortenson wrote:
> Good idea, but the problem is that there are several packages which
> contain both scratchpad and excalibur classes. (How do you refer to the
> non-excalibur classes).
oops - forgot about that ;)
> How about I create a second javadocs directory called
> build/scratchpad-javadocs until we come up with a better solution. It
> would be nice to have the links between the scratchpad and excalibur
> javadocs. But I think that it would be more confusing to have them
> together.
Works for me.
--
Cheers,
Pete
------------------------------
Kitsch never goes out of style
------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JavaDocs for Excalibur Scratchpad classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Peter Donald wrote:
> On Fri, 25 Jan 2002 15:38, Leif Mortenson wrote:
>
>>Currently, the classes in the scratchpad are not being included in the
>>building of javadocs. Should they be? I found it quite useful to modify
>>my local build to include them with the rest of the classes, however
>>that may be confusing to most users.
>>
>
> How about adding them into the main javadocs target but grouping them in
> their own category if possible. Something like
>
> <group title="Scratchpad Packages">
> <package name="org.apache.excalibur.foo"/>
> <package name="org.apache.excalibur.bar"/>
> </group>
>
> etc?
>
> That would give people ample warning that they are experimental but would
> still allow one set of javadocs to be generated.
Good idea, but the problem is that there are several packages which
contain both scratchpad and excalibur classes. (How do you refer to the
non-excalibur classes).
That would also be tough to maintain as all new packages would have to
be added to build.xml when the were created.
How about I create a second javadocs directory called
build/scratchpad-javadocs until we come up with a better solution. It
would be nice to have the links between the scratchpad and excalibur
javadocs. But I think that it would be more confusing to have them
together.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JavaDocs for Excalibur Scratchpad classes
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 25 Jan 2002 15:38, Leif Mortenson wrote:
>
>>Currently, the classes in the scratchpad are not being included in the
>>building of javadocs. Should they be? I found it quite useful to modify
>>my local build to include them with the rest of the classes, however
>>that may be confusing to most users.
>>
>
> How about adding them into the main javadocs target but grouping them in
> their own category if possible. Something like
>
> <group title="Scratchpad Packages">
> <package name="org.apache.excalibur.foo"/>
> <package name="org.apache.excalibur.bar"/>
> </group>
>
> etc?
>
> That would give people ample warning that they are experimental but would
> still allow one set of javadocs to be generated.
+1
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JavaDocs for Excalibur Scratchpad classes
Posted by Peter Donald <pe...@apache.org>.
On Fri, 25 Jan 2002 15:38, Leif Mortenson wrote:
> Currently, the classes in the scratchpad are not being included in the
> building of javadocs. Should they be? I found it quite useful to modify
> my local build to include them with the rest of the classes, however
> that may be confusing to most users.
How about adding them into the main javadocs target but grouping them in
their own category if possible. Something like
<group title="Scratchpad Packages">
<package name="org.apache.excalibur.foo"/>
<package name="org.apache.excalibur.bar"/>
</group>
etc?
That would give people ample warning that they are experimental but would
still allow one set of javadocs to be generated.
--
Cheers,
Pete
------------------------------------------
I just hate 'yes' men, don't you Smithers?
------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>