Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> 
> Sounds like, I need to improve my english. If for you my english is like
> an "old Chinese proverb" (You need to think a lot to understand what is
> behind the words). ;-) lol.

No, it was my fault - reading too quickly and jumping
to conclusions.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mie, 12 de Enero de 2005, 23:00, David Crossley dijo:
> David Crossley wrote:
>> Antonio Gallardo wrote:
>> [snip]
>> > I did some System.out of the process (included in the commit). Made a
>> > workaround "hack" and I will commit. The hack works. :-D
>>
>> No difference for me. Doing 'build clean, build' still fails.
>
> Your fix works for me today (sorry, must have been my mistake).

:-D

>
> [snip]
>> > If the "hack" is OK, please copy paste back to 2.1. I am too tired to
>> do
>> > that now. ;-)
>
> Okay, i am doing that now.

I see the commits, thanks for your time.
>
>> > A posible solution is try to generate core + blocks docs in 1 run.
>> That
>> > way "the current hack" can be gone.
>> >
>> > Currently, seems like we need 2 runs. I am not sure why we need 2 runs
>> at
>> > all.
>
> Ah, now i understand what you are saying. The docs-build.xml
> calls  twice. Yeah, just historical. It didn't
> ever do scanning of the blocks. I added the second call recently.

Sounds like, I need to improve my english. If for you my english is like
an "old Chinese proverb" (You need to think a lot to understand what is
behind the words). ;-) lol.

Best Regards,

Antonio Gallardo.

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

David Crossley wrote:
> Antonio Gallardo wrote:
> [snip]
> > I did some System.out of the process (included in the commit). Made a
> > workaround "hack" and I will commit. The hack works. :-D
> 
> No difference for me. Doing 'build clean, build' still fails.

Your fix works for me today (sorry, must have been my mistake).

[snip]
> > If the "hack" is OK, please copy paste back to 2.1. I am too tired to do
> > that now. ;-)

Okay, i am doing that now.

> > A posible solution is try to generate core + blocks docs in 1 run. That
> > way "the current hack" can be gone.
> > 
> > Currently, seems like we need 2 runs. I am not sure why we need 2 runs at
> > all.

Ah, now i understand what you are saying. The docs-build.xml
calls  twice. Yeah, just historical. It didn't
ever do scanning of the blocks. I added the second call recently.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Geoff Howard wrote:
> David Crossley wrote:
> > Antonio Gallardo wrote:
> > > Can you post where the problem is showed to you trying a full build? I am
> > > trying to get an idea if the problem is truly random or just because users
> > > have diferent blocks configurations in local.blocks.properties. The
> > > lastest seems to be the case, but lets to be sure.
> > 
> > I showed that a few messages ago in this thread.
> > Both Ross and i are doing a full build, javadocs and all,
> > with no blocks disabled. It breaks in different places
> > for each of us.
> 
> It looks like you've moved on past the need to understand this, ...

No, we still need to understand what is going on.

> ... but I think 
> you're mistaken here, no?  Ross is doing a default unmodified build, which 
> has some blocks excluded by default.  You're reporting all blocks enabled 
> which would require some editing of the properties.

Maybe i expressed that poorly ... I have no local*.properties

>  I'd guess that Antonio has 
> a separate set of blocks chosen, so this still may explain the
> different fail points,
> though it seems this is now just a curiosity in the larger problem.

Probably.

> Unfortunately, time to crawl back into my hole.

Thanks for your help.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mie, 12 de Enero de 2005, 7:01, Geoff Howard dijo:
> On Wed, 12 Jan 2005 16:57:31 +1100, David Crossley <[EMAIL PROTECTED]>
> wrote:
>> Antonio Gallardo wrote:
>> > Can you post where the problem is showed to you trying a full build? I
>> am
>> > trying to get an idea if the problem is truly random or just because
>> users
>> > have diferent blocks configurations in local.blocks.properties. The
>> > lastest seems to be the case, but lets to be sure.
>>
>> I showed that a few messages ago in this thread.
>> Both Ross and i are doing a full build, javadocs and all,
>> with no blocks disabled. It breaks in different places
>> for each of us.
>
> It looks like you've moved on past the need to understand this, but I
> think
> you're mistaken here, no?  Ross is doing a default unmodified build, which
> has some blocks excluded by default.  You're reporting all blocks enabled
> which would require some editing of the properties.  I'd guess that
> Antonio has
> a separate set of blocks chosen, so this still may explain the
> different fail points,
> though it seems this is now just a curiosity in the larger problem.

Nope. I am using a full build (no local.* at all).

Sorry guys, sometimes I need to work too. ;-)

I will try to fix it today at night.

Best Regards,

Antonio Gallardo

Re: trunk build broken (Was: how to list all sitemap components)

[Geoff Howard]

On Wed, 12 Jan 2005 16:57:31 +1100, David Crossley <[EMAIL PROTECTED]> wrote:
> Antonio Gallardo wrote:
> > Can you post where the problem is showed to you trying a full build? I am
> > trying to get an idea if the problem is truly random or just because users
> > have diferent blocks configurations in local.blocks.properties. The
> > lastest seems to be the case, but lets to be sure.
> 
> I showed that a few messages ago in this thread.
> Both Ross and i are doing a full build, javadocs and all,
> with no blocks disabled. It breaks in different places
> for each of us.

It looks like you've moved on past the need to understand this, but I think 
you're mistaken here, no?  Ross is doing a default unmodified build, which 
has some blocks excluded by default.  You're reporting all blocks enabled 
which would require some editing of the properties.  I'd guess that Antonio has 
a separate set of blocks chosen, so this still may explain the
different fail points,
though it seems this is now just a curiosity in the larger problem.

Unfortunately, time to crawl back into my hole.

Thanks,
Geoff

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> Hi David:
> 
> 4:00 a.m. here! :-(
> 
> I guess I found and fixed the source error. (Am I telling the same again?
> - lol.).
> 
> I did some System.out of the process (included in the commit). Made a
> workaround "hack" and I will commit. The hack works. :-D

No difference for me. Doing 'build clean, build' still fails.

> I guess the trouble is made by 1 of this 2 posibilities:
> 
> 1-While we generate blocks docs qdox has no info of the cocoon core libs.
> qdox is not able to know where is o.a.c.transformation.Tranformer or
> inherancy as:
> 
> HTMLGenerator isA ServiceableGenerator isA AbstractGenerator isA Generator

It is not "generating" the blocks, just scanning their sources.

> 2-A qdox bug in isA()? To me it is a lesser posibility. I checked in the
> qdox JIRA and nothing similar is there:
> 
> http://jira.codehaus.org/browse/QDOX
> 
> WDYT?

I don't know what to think yet. It needs more exploration.

> BTW, is not funy to wait 7 minuts to see the results of a small change and
> see if this is working. :-(

I know, we must fine-tune the whole build system.

> If the "hack" is OK, please copy paste back to 2.1. I am too tired to do
> that now. ;-)
> 
> A posible solution is try to generate core + blocks docs in 1 run. That
> way "the current hack" can be gone.
> 
> Currently, seems like we need 2 runs. I am not sure why we need 2 runs at
> all.

This is still the same workaround.

> Now I am getting again in RequestAttributeGenerator (from scratchpad?):
> 
> [Fatal Error] include-transformer.xml:1:896: The entity name must
> immediately follow the '&' in the entity reference.

I fixed that in SVN, perhaps you need 'svn up'.

> Anyway, the hack shows how this can be fixed too. :-D
> 
> I hope this helps.

It does, thanks.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> Hi David:
> 
> 4:00 a.m. here! :-(
> 
> I guess I found and fixed the source error. (Am I telling the same again?
> - lol.).

:-)

There you go, doing one of your super-human efforts again.

Thanks, that is an excellent step forward.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

Hi David:

4:00 a.m. here! :-(

I guess I found and fixed the source error. (Am I telling the same again?
- lol.).

I did some System.out of the process (included in the commit). Made a
workaround "hack" and I will commit. The hack works. :-D

I guess the trouble is made by 1 of this 2 posibilities:

1-While we generate blocks docs qdox has no info of the cocoon core libs.
qdox is not able to know where is o.a.c.transformation.Tranformer or
inherancy as:

HTMLGenerator isA ServiceableGenerator isA AbstractGenerator isA Generator

2-A qdox bug in isA()? To me it is a lesser posibility. I checked in the
qdox JIRA and nothing similar is there:

http://jira.codehaus.org/browse/QDOX

WDYT?

BTW, is not funy to wait 7 minuts to see the results of a small change and
see if this is working. :-(

If the "hack" is OK, please copy paste back to 2.1. I am too tired to do
that now. ;-)

A posible solution is try to generate core + blocks docs in 1 run. That
way "the current hack" can be gone.

Currently, seems like we need 2 runs. I am not sure why we need 2 runs at
all.

Now I am getting again in RequestAttributeGenerator (from scratchpad?):

[Fatal Error] include-transformer.xml:1:896: The entity name must
immediately follow the '&' in the entity reference.

Anyway, the hack shows how this can be fixed too. :-D

I hope this helps.

Best Regards,

Antonio Gallardo

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> 
> I think I got the source of the problem: some transformers has "bad"
> written javadocs that don't use the agreed format. Please do an SVN update
> to see if it changes in your case too. Now I am getting a diferent one
> after adding a new tag in the Includetranformer:

It seems that you forgot to do 'build clean' so you are
getting the workaround of 'build; build'. Now you are getting on
to the actual docs generation and finding new errors, i.e. not
the main issue yet.

> [Fatal Error] include-transformer.xml:1:896: The entity name must
> immediately follow the '&' in the entity reference.

I fixed that by moving the @cocoon.sitemap.component.documentation
tag down a bit. Perhaps it only allows limited html content.

--David

> The IncludeTransformer in placed:
> 
> src/blocks/scratchpad/java/org/apache/cocoon/transformation/IncludeTransformer.java
> 
> Best Regards,
> 
> Antonio Gallardo

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> 
> I think I got the source of the problem: some transformers has "bad"
> written javadocs that don't use the agreed format. Please do an SVN update
> to see if it changes in your case too. Now I am getting a diferent one
> after adding a new tag in the Includetranformer:
> 
> [Fatal Error] include-transformer.xml:1:896: The entity name must
> immediately follow the '&' in the entity reference.
> 
> The IncludeTransformer in placed:
> 
> src/blocks/scratchpad/java/org/apache/cocoon/transformation/IncludeTransformer.java

I haven't yet looked at the result of your change
due to the other "trunk broken" problem.

However, be aware that there are many *.java components
that are missing the "sitemap" javadoc stuff, even in the
core which does not exhibit this "build failed". That is the
purpose of http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
... we will gradually add all of that documentation.

So i don't think that you have got the source of the problem.
The SitemapTask reads each *.java and *if* it has that javadoc
stuff then it generates a doc, otherwise it skips.

During the "build docs" there is no problem doing the core stuff.
There are many missing that info in src/java/o/a/c/transformation/*.java

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mie, 12 de Enero de 2005, 1:27, David Crossley dijo:
> Ralph Goers wrote:
>> David Crossley wrote:
>>
>> >I showed that a few messages ago in this thread.
>> >Both Ross and i are doing a full build, javadocs and all,
>> >with no blocks disabled. It breaks in different places
>> >for each of us.
>> >
>> Does it fail for you in BRANCH_2_1_X (before you disabled it) in the
>> same place it did for me?  Note that the error seems to be different.
>
> Are you talking about the PhpGenerator.java stumble?
> If so then i just rm it to get past that problem.
>
> After that yes, cocoon-2_1_X fails at a different place:
> For me with all blocks enabled, it fails at NekoHTMLGenerator.

I suspect the aparently random point of fail (the exactly file) has
nothing to do with the real problem. Is posible that it happens just
because the random order nature of the HashMap used as file cache. So this
is notimportant here.

I think I got the source of the problem: some transformers has "bad"
written javadocs that don't use the agreed format. Please do an SVN update
to see if it changes in your case too. Now I am getting a diferent one
after adding a new tag in the Includetranformer:

[Fatal Error] include-transformer.xml:1:896: The entity name must
immediately follow the '&' in the entity reference.

The IncludeTransformer in placed:

src/blocks/scratchpad/java/org/apache/cocoon/transformation/IncludeTransformer.java

Best Regards,

Antonio Gallardo

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Ralph Goers wrote:
> David Crossley wrote:
> 
> >I showed that a few messages ago in this thread.
> >Both Ross and i are doing a full build, javadocs and all,
> >with no blocks disabled. It breaks in different places
> >for each of us.
> >
> Does it fail for you in BRANCH_2_1_X (before you disabled it) in the 
> same place it did for me?  Note that the error seems to be different.

Are you talking about the PhpGenerator.java stumble?
If so then i just rm it to get past that problem.

After that yes, cocoon-2_1_X fails at a different place:
For me with all blocks enabled, it fails at NekoHTMLGenerator.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Ralph Goers]

David Crossley wrote:
I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.
--David
 

Does it fail for you in BRANCH_2_1_X (before you disabled it) in the 
same place it did for me?  Note that the error seems to be different.

Ralph

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> David Crossley dijo:
> > I showed that a few messages ago in this thread.
> > Both Ross and i are doing a full build, javadocs and all,
> > with no blocks disabled. It breaks in different places
> > for each of us.
> 
> Then the problem is somewhere in the Ant task:
> 
> /tools/src/anttasks/SitemapTask.java
> 
> Is this correct?

That is the file that emits the error message
and that is the task that is being executed.

However, i cannot say if that is where the
"problem" is.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mar, 11 de Enero de 2005, 23:57, David Crossley dijo:
> I showed that a few messages ago in this thread.
> Both Ross and i are doing a full build, javadocs and all,
> with no blocks disabled. It breaks in different places
> for each of us.

Then the problem is somewhere in the Ant task:

/tools/src/anttasks/SitemapTask.java

Is this correct?

Best Regards,

Antonio Gallardo

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> David Crossley dijo:
> >
> > It is not the cause, it just enables to bug to manifest.
> 
> OK.
> 
> Can you post where the problem is showed to you trying a full build? I am
> trying to get an idea if the problem is truly random or just because users
> have diferent blocks configurations in local.blocks.properties. The
> lastest seems to be the case, but lets to be sure.

I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> David Crossley dijo:
> > Anyway, i spent most of the day investigating.
> > Did "svn update -r" and am now right back to
> > r106987 2004-11-30 and it is happening there too.
> 
> Try r124700. Seems to be OK, but as you told there is off the build option.

No, that is just where the bug was unmasked.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mar, 11 de Enero de 2005, 23:35, David Crossley dijo:
> It is being done as part of the documentation effort.
> http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
>
> It is not the cause, it just enables to bug to manifest.

OK.

Can you post where the problem is showed to you trying a full build? I am
trying to get an idea if the problem is truly random or just because users
have diferent blocks configurations in local.blocks.properties. The
lastest seems to be the case, but lets to be sure.

Best Regards,

Antonio Gallardo.

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mar, 11 de Enero de 2005, 23:30, David Crossley dijo:
> Anyway, i spent most of the day investigating.
> Did "svn update -r" and am now right back to
> r106987 2004-11-30 and it is happening there too.

Try r124700. Seems to be OK, but as you told there is off the build option.

Best Regards,

Antonio Gallardo.

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Antonio Gallardo wrote:
> 
> The lastest changes of docs-build.xml (SVN 124702):
> 
> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110523951602586&w=2
> 
> from:
> 
>  source="${java}"/>
> 
> to:
> 
>  source="${blocks}"/>
> 
> see the change: from ${java} -> ${block}.
> 
> SVN 124701 is compile with 0 Errors. But 124702 is not. I guess there is
> the problem. ;-)

That is just where the problem was unmasked.

> I am not sure why this change was done. Can someone review this?

It is being done as part of the documentation effort.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html

It is not the cause, it just enables to bug to manifest.

Yes please, someone help.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Ross Gardler wrote:
> David Crossley wrote:
> >Geoff Howard wrote:
> >
> >>odd that this is breaking in different places for everyone.  Do you
> >>all have different sets of blocks enabled?
> >
> >I have all blocks enabled.

Breaks for me on RequestAttributeGenerator

> Mine is an unmodified checkout of SVN head.

Breaks for Ross on JXTemplateGenerator.

So it doesn't depend on which blocks are enabled.

I figured out why we are suddenly seeing this.
It must have been happening for ages. It was unmasked
recently when i switched on scanning of blocks with
Qdox to generate the sitemap documentation.

I cannot figure out why it worked okay for me for
the last two months. Perhaps i never did a build clean,
though i cannot imagine that. Mystery.

Anyway, i spent most of the day investigating.
Did "svn update -r" and am now right back to
r106987 2004-11-30 and it is happening there too.

--David

Re: trunk build broken (Was: how to list all sitemap components)

[Antonio Gallardo]

On Mar, 11 de Enero de 2005, 10:55, Geoff Howard dijo:
> odd that this is breaking in different places for everyone.  Do you
> all have different sets of blocks enabled?

Seems like have to do with diferent blocks enabled ;-)

In my case (a full build):

BUILD FAILED
/home/agallardo/svn/cocoon-2.2/tools/targets/docs-build.xml:55: Sitemap
component org.apache.cocoon.transformation.IncludeTransformer does not
implement a sitemap component interface.

See below

>> > BUILD FAILED
>> > /Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
>> > docs-build.xml:55: Sitemap component
>> > org.apache.cocoon.generation.NekoHTMLGenerator does not implement a
>> > sitemap component interface.
>>
>> I may be at risk of repeating things already known, but...
>>
>> I just did a new svn checkout and got a similar error:
>>
>> Building component docs from blocks.
>> Collecting sitemap components info
>>
>> BUILD FAILED
>> D:\openSource\cocoon\tools\targets\docs-build.xml:55: Sitemap component
>> org.apache.cocoon.template.jxtg.JXTemplateGenerator does not implement a
>> sitemap component interface.

The lastest changes of docs-build.xml (SVN 124702):

http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110523951602586&w=2

from:



to:



see the change: from ${java} -> ${block}.

SVN 124701 is compile with 0 Errors. But 124702 is not. I guess there is
the problem. ;-)

I am not sure why this change was done. Can someone review this?

Best Regards,

Antonio Gallardo.

Re: trunk build broken (Was: how to list all sitemap components)

[Ross Gardler]

David Crossley wrote:
Geoff Howard wrote:
odd that this is breaking in different places for everyone.  Do you
all have different sets of blocks enabled?

I have all blocks enabled.
Mine is an unmodified checkout of SVN head.
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005

Re: trunk build broken (Was: how to list all sitemap components)

[David Crossley]

Geoff Howard wrote:
> odd that this is breaking in different places for everyone.  Do you
> all have different sets of blocks enabled?

I have all blocks enabled.

> If not, I'm suspicious of out of memory error or something odd like
> that.  In that case, any chance that the docs build tasks could mask
> some odd condition like that with such an error?

Watched top, and memory seemed to be okay when it failed.

This problem only started happening recently. So perhaps
some other change has caused it. It also happens in the
2.1 branch.

I will try rolling back to previous revisions to find the breakdown.

--David

> > BUILD FAILED
> > D:\openSource\cocoon\tools\targets\docs-build.xml:55: Sitemap component
> > org.apache.cocoon.template.jxtg.JXTemplateGenerator does not implement a
> > sitemap component interface.

Re: trunk build broken (Was: how to list all sitemap components)

[Geoff Howard]

odd that this is breaking in different places for everyone.  Do you
all have different sets of blocks enabled?

If not, I'm suspicious of out of memory error or something odd like
that.  In that case, any chance that the docs build tasks could mask
some odd condition like that with such an error?

Geoff


On Tue, 11 Jan 2005 14:01:08 +, Ross Gardler <[EMAIL PROTECTED]> wrote:
> Jeremy Quinn wrote:
> > I am getting the same problem, but with :
> >
> > BUILD FAILED
> > /Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
> > docs-build.xml:55: Sitemap component
> > org.apache.cocoon.generation.NekoHTMLGenerator does not implement a
> > sitemap component interface.
> 
> I may be at risk of repeating things already known, but...
> 
> I just did a new svn checkout and got a similar error:
> 
> Building component docs from blocks.
> Collecting sitemap components info
> 
> BUILD FAILED
> D:\openSource\cocoon\tools\targets\docs-build.xml:55: Sitemap component
> org.apache.cocoon.template.jxtg.JXTemplateGenerator does not implement a
> sitemap component interface.
> 
> Ross
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005
> 
>

Re: trunk build broken (Was: how to list all sitemap components)

[Ross Gardler]

Jeremy Quinn wrote:
I am getting the same problem, but with :
BUILD FAILED
/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/ 
docs-build.xml:55: Sitemap component  
org.apache.cocoon.generation.NekoHTMLGenerator does not implement a  
sitemap component interface.
I may be at risk of repeating things already known, but...
I just did a new svn checkout and got a similar error:
Building component docs from blocks.
Collecting sitemap components info
BUILD FAILED
D:\openSource\cocoon\tools\targets\docs-build.xml:55: Sitemap component 
org.apache.cocoon.template.jxtg.JXTemplateGenerator does not implement a 
sitemap component interface.

Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005

Re: trunk build broken (Was: how to list all sitemap components)

[Jeremy Quinn]

I am getting the same problem, but with :
BUILD FAILED
/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/ 
docs-build.xml:55: Sitemap component  
org.apache.cocoon.generation.NekoHTMLGenerator does not implement a  
sitemap component interface.

This was after a ./build.sh clean webapp
Doing a ./build.sh webapp straight afterwards, resulted in a successful  
build.

regards Jeremy
On 11 Jan 2005, at 03:22, David Crossley wrote:
The Cocoon SitemapTask in trunk is suddenly throwing a wobbly.
-
...
Building component docs from blocks.
Collecting sitemap components info
BUILD FAILED
/opt/cocoon-trunk/tools/targets/docs-build.xml:55:
Sitemap component org.apache.cocoon.generation.HTMLGenerator
does not implement a sitemap component interface.
-
It is very strange. If you immediately run './build.sh' again
then there are no problems. It is the first build after a
'build clean' that has trouble and then only when it is
scanning the "src/blocks" not when scanning "src/java".
--David


  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

trunk build broken (Was: how to list all sitemap components)

[David Crossley]

The Cocoon SitemapTask in trunk is suddenly throwing a wobbly.

-
...
Building component docs from blocks.
Collecting sitemap components info

BUILD FAILED
/opt/cocoon-trunk/tools/targets/docs-build.xml:55:
Sitemap component org.apache.cocoon.generation.HTMLGenerator
does not implement a sitemap component interface.
-

It is very strange. If you immediately run './build.sh' again
then there are no problems. It is the first build after a
'build clean' that has trouble and then only when it is
scanning the "src/blocks" not when scanning "src/java".

--David

Re: how to list all sitemap components

[David Crossley]

Carsten Ziegeler wrote:
> David Crossley wrote:
> > 
> > That is the trouble - i don't know what is "correct".
> :)
> 
> > The file called components-javadoc-sitemaptask-diff.txt
> > is the difference between the list produced by scanning 
> > javadocs (finding extra clutter, maybe missing some) and the 
> > list produced by the SitemapTask.
> > diff components-source.txt components-sitemaptask.txt
> Yepp.
> 
> > This is not to say that the scanning javadocs is finding all 
> > components. It is just to provide a method for comparison.
> Ok.
> 
> > 
> > Here are some examples of components that are not found by 
> > the SitemapTask ...
> > org/apache/cocoon/matching/RegexpTargetHostMatcher
> > org/apache/cocoon/transformation/JXTemplateTransformer
> > org/apache/cocoon/selection/SessionStateSelector
> > org/apache/cocoon/transformation/CachingCIncludeTransformer
> > org/apache/cocoon/forms/formmodel/RepeaterAction
> 
> Ah, so it's the other way round and the list I provided above are those
> that are not found in the javadocs, right? I'm still trying to make
> sense of the diff file: what line is missing in which file.
> 
> > The *Pipeline components that you listed above are found by 
> > the SitemapTask but not by the scan of javadocs. That is 
> > because the correlate-table.sh script forgot to look for 
> > pipelines. But do we consider them "sitemap components"
> > that should be documented in the Userdocs?
> 
> Yes, we should :) These are sitemap components, you can selected between
> different pipeline implementations in your sitemap (caching, non-caching
> etc.), so imho it makes sense to document them as well.

That is what i thought but wasn't sure. Thanks.

I will generate some fresh files and put them at my web space
perhaps i can remove a bit more of the clutter.

--David

RE: how to list all sitemap components

[Carsten Ziegeler]

David Crossley wrote:
> 
> > So if I read the diff correctly, these classes are not found by the 
> > sitemap
> > task:
> > 65a64,71
> > >
> > 
> org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPi
> > peline
> > > 
> org/apache/cocoon/components/pipeline/impl/BaseCachingProcessingPipe
> > > line 
> > > 
> org/apache/cocoon/components/pipeline/impl/CachingPointProcessingPip
> > > eline 
> > > 
> org/apache/cocoon/components/pipeline/impl/CachingProcessingPipeline
> > >
> > 
> org/apache/cocoon/components/pipeline/impl/ExpiresCachingProcessingPip
> > eline
> > > 
> org/apache/cocoon/components/pipeline/impl/NonCachingProcessingPipel
> > > ine 
> > > 
> org/apache/cocoon/components/profiler/ProfilingCachingProcessingPipe
> > > line
> > >
> > 
> org/apache/cocoon/components/profiler/ProfilingNonCachingProcessingPip
> > eline
> > > org/apache/cocoon/woody/acting/AbstractWoodyAction
> > > org/apache/cocoon/woody/acting/HandleFormSubmitAction
> > > org/apache/cocoon/woody/acting/MakeFormAction
> > > org/apache/cocoon/woody/generation/WoodyGenerator
> > > org/apache/cocoon/woody/samples/InitForm1Action
> > > org/apache/cocoon/woody/transformation/WoodyTemplateTransformer
> > > org/apache/garbage/serializer/AbstractSerializer
> > > org/apache/garbage/serializer/EncodingSerializer
> > > org/apache/garbage/serializer/HTMLSerializer
> > > org/apache/garbage/serializer/XHTMLSerializer
> > > org/apache/garbage/serializer/XMLSerializer
> > 
> > Is this correct?
> 
> That is the trouble - i don't know what is "correct".
:)

> 
> The file called components-javadoc-sitemaptask-diff.txt
> is the difference between the list produced by scanning 
> javadocs (finding extra clutter, maybe missing some) and the 
> list produced by the SitemapTask.
> diff components-source.txt components-sitemaptask.txt
Yepp.

> 
> This is not to say that the scanning javadocs is finding all 
> components. It is just to provide a method for comparison.
Ok.

> 
> Here are some examples of components that are not found by 
> the SitemapTask ...
> org/apache/cocoon/matching/RegexpTargetHostMatcher
> org/apache/cocoon/transformation/JXTemplateTransformer
> org/apache/cocoon/selection/SessionStateSelector
> org/apache/cocoon/transformation/CachingCIncludeTransformer
> org/apache/cocoon/forms/formmodel/RepeaterAction
> 
Ah, so it's the other way round and the list I provided above are those
that are not found in the javadocs, right? I'm still trying to make
sense of the diff file: what line is missing in which file.

> 
> The *Pipeline components that you listed above are found by 
> the SitemapTask but not by the scan of javadocs. That is 
> because the correlate-table.sh script forgot to look for 
> pipelines. But do we consider them "sitemap components"
> that should be documented in the Userdocs?

Yes, we should :) These are sitemap components, you can selected between
different pipeline implementations in your sitemap (caching, non-caching
etc.), so imho it makes sense to document them as well.

Carsten

Re: how to list all sitemap components

[David Crossley]

Carsten Ziegeler wrote:
> David Crossley wrote: 
> 
> > Okay, i uploaded them to my ASF committer space 
> > www.apache.org ~crossley/review-sitemap-docs/ See the notes 
> > in SVN cocoon-2_1_X/tools/review-sitemap-docs/README.txt
> > and cocoon-2_1_X/tools/review-sitemap-docs/TODO.txt
> > 
> Thanks!!
> 
> So if I read the diff correctly, these classes are not found by the sitemap
> task:
> 65a64,71
> >
> org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline
> > org/apache/cocoon/components/pipeline/impl/BaseCachingProcessingPipeline
> > org/apache/cocoon/components/pipeline/impl/CachingPointProcessingPipeline
> > org/apache/cocoon/components/pipeline/impl/CachingProcessingPipeline
> >
> org/apache/cocoon/components/pipeline/impl/ExpiresCachingProcessingPipeline
> > org/apache/cocoon/components/pipeline/impl/NonCachingProcessingPipeline
> > org/apache/cocoon/components/profiler/ProfilingCachingProcessingPipeline
> >
> org/apache/cocoon/components/profiler/ProfilingNonCachingProcessingPipeline
> > org/apache/cocoon/woody/acting/AbstractWoodyAction
> > org/apache/cocoon/woody/acting/HandleFormSubmitAction
> > org/apache/cocoon/woody/acting/MakeFormAction
> > org/apache/cocoon/woody/generation/WoodyGenerator
> > org/apache/cocoon/woody/samples/InitForm1Action
> > org/apache/cocoon/woody/transformation/WoodyTemplateTransformer
> > org/apache/garbage/serializer/AbstractSerializer
> > org/apache/garbage/serializer/EncodingSerializer
> > org/apache/garbage/serializer/HTMLSerializer
> > org/apache/garbage/serializer/XHTMLSerializer
> > org/apache/garbage/serializer/XMLSerializer
> 
> Is this correct?

That is the trouble - i don't know what is "correct".

The file called components-javadoc-sitemaptask-diff.txt
is the difference between the list produced by scanning
javadocs (finding extra clutter, maybe missing some)
and the list produced by the SitemapTask.
diff components-source.txt components-sitemaptask.txt

This is not to say that the scanning javadocs is finding
all components. It is just to provide a method for
comparison.

Here are some examples of components that are not
found by the SitemapTask ...
org/apache/cocoon/matching/RegexpTargetHostMatcher
org/apache/cocoon/transformation/JXTemplateTransformer
org/apache/cocoon/selection/SessionStateSelector
org/apache/cocoon/transformation/CachingCIncludeTransformer
org/apache/cocoon/forms/formmodel/RepeaterAction

The "woody" and "garbage" stuff are probably not relevant.
The PhpGenerator is listed as missing because it caused
'build docs' to crash, so i moved it out of the way.

The *Pipeline components that you listed above are found
by the SitemapTask but not by the scan of javadocs. That
is because the correlate-table.sh script forgot to look
for pipelines. But do we consider them "sitemap components"
that should be documented in the Userdocs?

--David

RE: how to list all sitemap components

[Carsten Ziegeler]

David Crossley wrote: 

> Okay, i uploaded them to my ASF committer space 
> www.apache.org ~crossley/review-sitemap-docs/ See the notes 
> in SVN cocoon-2_1_X/tools/review-sitemap-docs/README.txt
> and cocoon-2_1_X/tools/review-sitemap-docs/TODO.txt
> 
Thanks!!

So if I read the diff correctly, these classes are not found by the sitemap
task:
65a64,71
>
org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline
> org/apache/cocoon/components/pipeline/impl/BaseCachingProcessingPipeline
> org/apache/cocoon/components/pipeline/impl/CachingPointProcessingPipeline
> org/apache/cocoon/components/pipeline/impl/CachingProcessingPipeline
>
org/apache/cocoon/components/pipeline/impl/ExpiresCachingProcessingPipeline
> org/apache/cocoon/components/pipeline/impl/NonCachingProcessingPipeline
> org/apache/cocoon/components/profiler/ProfilingCachingProcessingPipeline
>
org/apache/cocoon/components/profiler/ProfilingNonCachingProcessingPipeline
> org/apache/cocoon/woody/acting/AbstractWoodyAction
> org/apache/cocoon/woody/acting/HandleFormSubmitAction
> org/apache/cocoon/woody/acting/MakeFormAction
> org/apache/cocoon/woody/generation/WoodyGenerator
> org/apache/cocoon/woody/samples/InitForm1Action
> org/apache/cocoon/woody/transformation/WoodyTemplateTransformer
> org/apache/garbage/serializer/AbstractSerializer
> org/apache/garbage/serializer/EncodingSerializer
> org/apache/garbage/serializer/HTMLSerializer
> org/apache/garbage/serializer/XHTMLSerializer
> org/apache/garbage/serializer/XMLSerializer

Is this correct?

Carsten

Re: how to list all sitemap components

[David Crossley]

Carsten Ziegeler wrote:
> David Crossley wrote:
> > 
> > 
> > I am working on this in cocoon-2_1_X branch.
> > In tools/targets/docs-build.xml uncomment the 
> >  task at line 56 to also scan the blocks.
> > Then run 'build javadocs'.
> > Then run 'build docs'. This will also produce lists of all 
> > possible sitemap components at 
> > build/all-sitemap-components*.txt via the SitemapTask.
> > Then follow tools/review-sitemap-docs/README.txt to run the 
> > shell script correlate-table.sh which attempts to scan 
> > javadocs and match with what we have manually identified as 
> > being possible sitemap components.
> 
> It seems that my linux machine isn't working the way it should be
> (perhaps it's already on holiday), so I can't even get Cocoon
> build using unix right now. Can you provide the result of the
> comparison?

Okay, i uploaded them to my ASF committer space
www.apache.org ~crossley/review-sitemap-docs/
See the notes in SVN cocoon-2_1_X/tools/review-sitemap-docs/README.txt
and cocoon-2_1_X/tools/review-sitemap-docs/TODO.txt

--David

RE: how to list all sitemap components

[Carsten Ziegeler]

David Crossley wrote:
> 
> 
> I am working on this in cocoon-2_1_X branch.
> In tools/targets/docs-build.xml uncomment the 
>  task at line 56 to also scan the blocks.
> Then run 'build javadocs'.
> Then run 'build docs'. This will also produce lists of all 
> possible sitemap components at 
> build/all-sitemap-components*.txt via the SitemapTask.
> Then follow tools/review-sitemap-docs/README.txt to run the 
> shell script correlate-table.sh which attempts to scan 
> javadocs and match with what we have manually identified as 
> being possible sitemap components.
> 
It seems that my linux machine isn't working the way it should be
(perhaps it's already on holiday), so I can't even get Cocoon
build using unix right now. Can you provide the result of the
comparison?

Thanks
Carsten

Re: how to list all sitemap components

[David Crossley]

Carsten Ziegeler wrote:
> David Crossley wrote: 
> >  ...
> > which misses src/java/o/a/c/serialization/XMLSerializer.java
> > perhaps because that extends AbstractTextSerializer.
> > 
> Ah, ok, that's strange. My understanding was that this should work
> and if I'm not mistaken it works for other classes. For example
> the transformers that are found inherit from abstract class as well;
> those abstract classes are declaring to implement the Transformer
> interface.
> Hmm, can you provide a list of which classes are found? (Perhaps
> with a list of which classes are not found - so we could see if
> we find similarities)

I am working on this in cocoon-2_1_X branch.
In tools/targets/docs-build.xml uncomment the 
task at line 56 to also scan the blocks.
Then run 'build javadocs'.
Then run 'build docs'. This will also produce lists of all
possible sitemap components at build/all-sitemap-components*.txt
via the SitemapTask.
Then follow tools/review-sitemap-docs/README.txt to run the shell
script correlate-table.sh which attempts to scan javadocs and
match with what we have manually identified as being possible
sitemap components.

--David

Re: how to list all sitemap components

[David Crossley]

Carsten Ziegeler wrote:
> David Crossley wrote:
> >> ...Fiddling with the SitemapTask.java i can also
> >> getting a listing.
> >> So i will be able to work out a solution. Thanks.
> > 
> > Hmmm, no joy so far.
> > 
> > Using the grep javadocs method does not find any serializers, 
> > actions, matchers, selectors.
> > 
> > Using the SitemapTask finds components only if their package 
> > name is "o.a.c.transformation.Transformer" etc.
> 
> Hmmm, are you sure? The SitemapTaks is able (should be able to)
> to generate docs for all sitemap components. It does so by using qdox
> and introspecting the classes (if a class implements the
> corresponding interface).

Welcome back Carsten. You probably have stacks of email
to catch up with. Here is the reason for my questions.
 Re: review of sitemap component documentation
 http://marc.theaimsgroup.com/?t=11012753601
 http://marc.theaimsgroup.com/?t=11019584291
 http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html

> For example, the task creates an xml document for a sitemap
> component if the javadoc containes the corresponding javadoc tags.

That part i understand. The part that i am having trouble with
is the mechanism by which it determines which java files to
investigate to see if they do contain those tags.

> I think the only sources that have this tag right now are transformers
> in the o.a.c.transformation package, so this might be the reason.

That is the next stage of my mission. Once all possible components
are identified, i will add the javadoc-like tags to them and we
can start adding the documentation. The abovementioned table lists
the components that do currently have the tags: not many.

> But changing the SitemapTask to just spit out a list of all sitemap
> components should be fairly easy.

That is what i thought too. I have local modifications that does that,
but it seems to not find all components. The SitemapTask has
 ...
 // Class Constants
 private static final String SERIALIZER = 
"org.apache.cocoon.serialization.Serializer";
 ...
 if ( javaClass.isA(SERIALIZER) ) {
 ...
which misses src/java/o/a/c/serialization/XMLSerializer.java
perhaps because that extends AbstractTextSerializer.

> I can't help you with this today -
> I'm now awake for more than 36 hours, but later this week should work.

Thanks, i was hoping that you would help when you returned.
I will commit the work that i have done so far in the 2.1 branch.

--David

Re: how to list all sitemap components

[David Crossley]

Upayavira wrote:
> David Crossley wrote:
> >Bertrand Delacretaz wrote:
> >>David Crossley a ?crit :
> >>
> >>>...Using the grep javadocs method does not find any
> >>>serializers, actions, matchers, selectors.
> >>>
> >>Why, can't you grep their base interfaces like:
> >> for i in $(egrep -rl 'SitemapModelComponent|OtherBaseInterface|Other)?
> >
> >Oh, i haven't tried that. I expected all sitemap components to have
> >SitemapModelComponent, but evidently not.
> 
> I just used "SitemapModelComponent" as something of a throwaway comment, 

Ah, i see now. Your comment sounded definitive.

> actually, if you search for
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/Generator.html,
>  
> 
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/Transformer.html,
>  
> etc, in the Javadoc files, you _will_ get everything!
> 
> >>Also, how about defining a marker interface for components that need to 
> >>be documented in this way? AutoDocumentedComponent extends Component or 
> >>something like this.
> >
> >At the moment i am trying to get a list of all possible
> >sitemap components, so that we know which components should
> >be documented.
> >
> >When we know that, then we can add such a marker to the
> >relevant components. Actually the SitemapTask will handle that
> >because it searches for the javadoc-like comments, e.g.
> >@cocoon.sitemap.component.name
> >http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html#Introduction
> 
> Yup, once marked up, we'll be there. But a simple script we can run 
> everyso often to ensure that we haven't added new ones without markup 
> would be useful.

Yes, my first task is twofold:
- find all possible components
- develop a shell script which will scan the code and match against
the coordination table.

--David

RE: how to list all sitemap components

[Carsten Ziegeler]

David Crossley wrote: 
> 
> Welcome back Carsten. You probably have stacks of email to 
> catch up with. 
Yes I had, now I'm done to 50 (I just deleted all the stuff dealing
with jxtg, tags, templates blabla :) )

> Here is the reason for my questions.
>  Re: review of sitemap component documentation
>  http://marc.theaimsgroup.com/?t=11012753601
>  http://marc.theaimsgroup.com/?t=11019584291
>  http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
> 
Thanks for the pointers!

> > But changing the SitemapTask to just spit out a list of all sitemap 
> > components should be fairly easy.
> 
> That is what i thought too. I have local modifications that 
> does that, but it seems to not find all components. The 
> SitemapTask has  ...
>  // Class Constants
>  private static final String SERIALIZER = 
> "org.apache.cocoon.serialization.Serializer";
>  ...
>  if ( javaClass.isA(SERIALIZER) ) {
>  ...
> which misses src/java/o/a/c/serialization/XMLSerializer.java
> perhaps because that extends AbstractTextSerializer.
> 
Ah, ok, that's strange. My understanding was that this should work
and if I'm not mistaken it works for other classes. For example
the transformers that are found inherit from abstract class as well;
those abstract classes are declaring to implement the Transformer
interface.
Hmm, can you provide a list of which classes are found? (Perhaps
with a list of which classes are not found - so we could see if
we find similarities)

Carsten

RE: how to list all sitemap components

[Carsten Ziegeler]

David Crossley wrote:
> Thanks, that will be suitable. Fiddling with the SitemapTask.java i 
> > can also getting a listing.
> > So i will be able to work out a solution. Thanks.
> 
> Hmmm, no joy so far.
> 
> Using the grep javadocs method does not find any serializers, 
> actions, matchers, selectors.
> 
> Using the SitemapTask finds components only if their package 
> name is "o.a.c.transformation.Transformer" etc.
> 
Hmmm, are you sure? The SitemapTaks is able (should be able to)
to generate docs for all sitemap components. It does so by using qdox
and introspecting the classes (if a class implements the
corresponding interface). 
For example, the task creates an xml document for a sitemap
component if the javadoc containes the corresponding javadoc tags.
I think the only sources that have this tag right now are transformers
in the o.a.c.transformation package, so this might be the reason.
But changing the SitemapTask to just spit out a list of all sitemap
components should be fairly easy. I can't help you with this today -
I'm now awake for more than 36 hours, but later this week should work.

Carsten

Re: how to list all sitemap components

[Upayavira]

David Crossley wrote:
Bertrand Delacretaz wrote:
 

David Crossley a ?crit :
   

...Using the grep javadocs method does not find any
serializers, actions, matchers, selectors.
 

Why, can't you grep their base interfaces like:
 for i in $(egrep -rl 'SitemapModelComponent|OtherBaseInterface|Other)
?
   

Oh, i haven't tried that. I expected all sitemap components to have
SitemapModelComponent, but evidently not.
 

I just used "SitemapModelComponent" as something of a throwaway comment, 
actually, if you search for
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/Generator.html, 

http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/Transformer.html, 
etc, in the Javadoc files, you _will_ get everything!

Also, how about defining a marker interface for components that need to 
be documented in this way? AutoDocumentedComponent extends Component or 
something like this.
   

At the moment i am trying to get a list of all possible
sitemap components, so that we know which components should
be documented.
When we know that, then we can add such a marker to the
relevant components. Actually the SitemapTask will handle that
because it searches for the javadoc-like comments, e.g.
@cocoon.sitemap.component.name
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html#Introduction
 

Yup, once marked up, we'll be there. But a simple script we can run 
everyso often to ensure that we haven't added new ones without markup 
would be useful.

Regards, Upayavira

Re: how to list all sitemap components

[David Crossley]

Bertrand Delacretaz wrote:
> David Crossley a ?crit :
> >...Using the grep javadocs method does not find any
> >serializers, actions, matchers, selectors.
> 
> Why, can't you grep their base interfaces like:
>   for i in $(egrep -rl 'SitemapModelComponent|OtherBaseInterface|Other)
> ?

Oh, i haven't tried that. I expected all sitemap components to have
SitemapModelComponent, but evidently not.

> Also, how about defining a marker interface for components that need to 
> be documented in this way? AutoDocumentedComponent extends Component or 
> something like this.

At the moment i am trying to get a list of all possible
sitemap components, so that we know which components should
be documented.

When we know that, then we can add such a marker to the
relevant components. Actually the SitemapTask will handle that
because it searches for the javadoc-like comments, e.g.
@cocoon.sitemap.component.name
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html#Introduction

--David

Re: how to list all sitemap components

[Bertrand Delacretaz]

Le 13 déc. 04, à 09:20, David Crossley a écrit :
...Using the grep javadocs method does not find any
serializers, actions, matchers, selectors.
Why, can't you grep their base interfaces like:
  for i in $(egrep -rl 'SitemapModelComponent|OtherBaseInterface|Other)
?
Also, how about defining a marker interface for components that need to 
be documented in this way? AutoDocumentedComponent extends Component or 
something like this.

-Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: how to list all sitemap components

[David Crossley]

David Crossley wrote:
Bertrand Delacretaz wrote:
Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
  echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a bit of junk left (package-frame etc) but it's a good 
start.
Thanks, that will be suitable. Fiddling with the
SitemapTask.java i can also getting a listing.
So i will be able to work out a solution. Thanks.
Hmmm, no joy so far.
Using the grep javadocs method does not find any
serializers, actions, matchers, selectors.
Using the SitemapTask finds components only if their
package name is "o.a.c.transformation.Transformer" etc.
--David

Re: how to list all sitemap components

[J.Pietschmann]

David Crossley wrote:
Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?

Thanks Geoff. However, command-line tools only
because i need to script it. Sorry, i forgot
to specify that.
A bit of BCEL should do the trick.
J.Pietschmann

Re: how to list all sitemap components

[David Crossley]

Bertrand Delacretaz wrote:
Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
  echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a bit of junk left (package-frame etc) but it's a good start.
Thanks, that will be suitable. Fiddling with the
SitemapTask.java i can also getting a listing.
So i will be able to work out a solution. Thanks.
--David

Re: how to list all sitemap components

[David Crossley]

Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?
Thanks Geoff. However, command-line tools only
because i need to script it. Sorry, i forgot
to specify that.
--David

Re: how to list all sitemap components

[Bertrand Delacretaz]

Le 9 déc. 04, à 16:56, Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
  echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a bit of junk left (package-frame etc) but it's a good 
start.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: how to list all sitemap components

[Upayavira]

Bertrand Delacretaz wrote:
Le 9 déc. 04, à 00:46, David Crossley a écrit :
I am trying to create a list of all sitemap
components in the Cocoon core and blocks...

Doesn't qdox list the interfaces that a class implements?
If it's the case, it should be possible to create a pipeline (using 
the qdox block) or use the qdox ant task to generate the list, by 
finding all classes which implement the Generator interface.

Is there a way to uniquely identify the
sitemap components by grepping the *.java
e.g. perhaps a unique method name?

Probably not, as the method could be implemented in a base class and 
as such not be visible in the derived class's source code.

I'd go the qdox route, assuming it finds the inherited interfaces.
-Bertrand
cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
That's pretty easy, isn't it?
Regards, Upayavira

Re: how to list all sitemap components

[Bertrand Delacretaz]

Le 9 déc. 04, à 00:46, David Crossley a écrit :
I am trying to create a list of all sitemap
components in the Cocoon core and blocks...
Doesn't qdox list the interfaces that a class implements?
If it's the case, it should be possible to create a pipeline (using the 
qdox block) or use the qdox ant task to generate the list, by finding 
all classes which implement the Generator interface.

Is there a way to uniquely identify the
sitemap components by grepping the *.java
e.g. perhaps a unique method name?
Probably not, as the method could be implemented in a base class and as 
such not be visible in the derived class's source code.

I'd go the qdox route, assuming it finds the inherited interfaces.
-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: how to list all sitemap components

[Upayavira]

Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?
 

Or, what we need is a tool that lists all the interfaces that a class 
implements. Hmm. Javadoc. For the CastorTransformer, you get a line saying:

*All Implemented Interfaces:*
   Component
   
,
   Configurable
   
,
   ContentHandler
   
,
   LexicalHandler
   
,
   LogEnabled
   
,
   Poolable
   
,
   Recyclable
   
,
   SitemapModelComponent
   
,
   Transformer
   
,
   XMLConsumer
   
,
   XMLConsumer
   
,
   XMLPipe
   ,
   XMLProducer
   
The word Transformer is in there, as is SitemapModelComponent, each of 
which tell you what you want to know.

Am I correct?
Regards, Upayavira
Geoff
On Thu, 09 Dec 2004 10:46:36 +1100, David Crossley <[EMAIL PROTECTED]> wrote:
 

I am trying to create a list of all sitemap
components in the Cocoon core and blocks.
So far i have tried to use 'find and grep'
by looking for well-known filenames,
e.g. *Transformer.java and also searching in
well-known directories, e.g. /transformation/
However, that misses some components and gets
too much extra stuff.
Using the "package" name inside the *.java
also misses some components.
Is there a way to uniquely identify the
sitemap components by grepping the *.java
e.g. perhaps a unique method name?
--David
   

 

Re: how to list all sitemap components

[Geoff Howard]

I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?

Geoff

On Thu, 09 Dec 2004 10:46:36 +1100, David Crossley <[EMAIL PROTECTED]> wrote:
> I am trying to create a list of all sitemap
> components in the Cocoon core and blocks.
> 
> So far i have tried to use 'find and grep'
> by looking for well-known filenames,
> e.g. *Transformer.java and also searching in
> well-known directories, e.g. /transformation/
> However, that misses some components and gets
> too much extra stuff.
> 
> Using the "package" name inside the *.java
> also misses some components.
> 
> Is there a way to uniquely identify the
> sitemap components by grepping the *.java
> e.g. perhaps a unique method name?
> 
> --David
> 
>

how to list all sitemap components

[David Crossley]

I am trying to create a list of all sitemap
components in the Cocoon core and blocks.
So far i have tried to use 'find and grep'
by looking for well-known filenames,
e.g. *Transformer.java and also searching in
well-known directories, e.g. /transformation/
However, that misses some components and gets
too much extra stuff.
Using the "package" name inside the *.java
also misses some components.
Is there a way to uniquely identify the
sitemap components by grepping the *.java
e.g. perhaps a unique method name?
--David