You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jh...@virbus.de> on 2003/09/07 13:36:03 UTC
Re: cvs commit: cocoon-2.1 blocks.properties
Back from holidays ... having more than 2200 mails (not only Cocoon) in
11 days ... started with CVS mails, so ignore my question if it sounds
stupid:
Isn't this now handled by the dependency in the gump descriptor? At
least I read something about library dependency on blocks (portal vs.
html). So do we need this comments in the properties files? Especially
for FOP it's only a dependency on the batik library.
Joerg
bdelacretaz@apache.org wrote:
> bdelacretaz 2003/09/05 08:31:36
>
> Modified: . blocks.properties
> Log:
> dependency comments added (from the BlockDescriptions wiki page)
>
> Revision Changes Path
> 1.28 +11 -1 cocoon-2.1/blocks.properties
>
> Index: blocks.properties
> ===================================================================
> RCS file: /home/cvs/cocoon-2.1/blocks.properties,v
> retrieving revision 1.27
> retrieving revision 1.28
> diff -u -r1.27 -r1.28
> --- blocks.properties 4 Sep 2003 12:42:43 -0000 1.27
> +++ blocks.properties 5 Sep 2003 15:31:36 -0000 1.28
> @@ -9,6 +9,10 @@
> # 'local.blocks.properties' and modify that. The build system will override
> # these properties with the ones in the 'local.blocks.properties' file.
>
> +# NOTE: "dependency" indicates blocks that are required by other blocks.
> +# disabling batik, for example, will prevent fop from compiling
> +
> +
> # Stable blocks ----------------------------------------------------------------
>
> # stable blocks are those that can be considered ready for production and
> @@ -17,6 +21,8 @@
> # depend on.
>
> #exclude.block.authentication-fw=true
> +
> +#dependency: fop needs batik
> #exclude.block.batik=true
> #exclude.block.bsf=true
> #exclude.block.chaperon=true
> @@ -37,6 +43,8 @@
> #exclude.block.portal-fw=true
> #exclude.block.profiler=true
> #exclude.block.python=true
> +
> +#dependency: authentication-fw needs session-fw
> #exclude.block.session-fw=true
> #exclude.block.slide=true
> #exclude.block.swf=true
> @@ -58,6 +66,8 @@
> #exclude.block.apples=true
> #exclude.block.asciiart=true
> #exclude.block.axis=true
> +
> +#dependency: scratchpad needs cron
> #exclude.block.cron=true
> #exclude.block.eventcache=true
> #exclude.block.linotype=true
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi Joerg:
I think we need to put the dependencies here too. Because users
(non-developers) need to know what block's dependencies without to go into
the sources of Cocoon. The idea to put the dependencies here started
because me (and maybe other people) waste to much time in undertand why
FOP does not work properly even if I dont use Batik. Then it takes 2 days
in discover the error. Interesting enoug is that for example, FOP without
Batik can be compiled without any error but when you try to use it just
generate blank pages. Looking at catalina.out there is an error that said
something about batik but it is not totally clear.
In order to avoid other people waste time in this we decided to write the
dependencies into this file. I think this is good.
Best Regards,
Antonio Gallardo.
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bertrand Delacretaz dijo:
>
> Le Lundi, 8 sep 2003, à 22:44 Europe/Zurich, Antonio Gallardo a écrit :
>
>> Bertrand Delacretaz dijo:
>>> Le Lundi, 8 sep 2003, à 22:36 Europe/Zurich, Antonio Gallardo a écrit
>>> :
>>>> ...jfor requires FOP. Is this true? Please comments about that.
>>>
>>> It shouldn't - do you see anything that shows a dependency?
>>
>> I read about that here:
>> http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions
>> This is why I asked about that.
>
> It is not so - I have corrected the wiki page.
Thanks!
Antonio Gallardo
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Tony Collen <co...@umn.edu>.
Antonio Gallardo wrote:
> Bertrand Delacretaz dijo:
>
>>Le Lundi, 8 sep 2003, à 22:36 Europe/Zurich, Antonio Gallardo a écrit :
>>
>>>...jfor requires FOP. Is this true? Please comments about that.
>>
>>It shouldn't - do you see anything that shows a dependency?
>
>
> I read about that here:
> http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions
> This is why I asked about that.
Looking back at the wiki version history, Hugo Burm added the line about
the FOP requirement. I'm not placing blame on anybody (At first I
thought I was the person to mess up the requirements), so perhaps he
would be inclined to explain :)
Regards,
Tony
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 8 sep 2003, à 22:44 Europe/Zurich, Antonio Gallardo a écrit :
> Bertrand Delacretaz dijo:
>> Le Lundi, 8 sep 2003, à 22:36 Europe/Zurich, Antonio Gallardo a écrit
>> :
>>> ...jfor requires FOP. Is this true? Please comments about that.
>>
>> It shouldn't - do you see anything that shows a dependency?
>
> I read about that here:
> http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions
> This is why I asked about that.
It is not so - I have corrected the wiki page.
-Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bertrand Delacretaz dijo:
> Le Lundi, 8 sep 2003, à 22:36 Europe/Zurich, Antonio Gallardo a écrit :
>> ...jfor requires FOP. Is this true? Please comments about that.
>
> It shouldn't - do you see anything that shows a dependency?
I read about that here:
http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions
This is why I asked about that.
Antonio Gallardo.
>
> -Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 8 sep 2003, à 22:36 Europe/Zurich, Antonio Gallardo a écrit :
> ...jfor requires FOP. Is this true? Please comments about that.
It shouldn't - do you see anything that shows a dependency?
-Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Joerg Heinicke dijo:
> Hmm, I'm not satisfied with the answer :-)
>
> Carsten has added a depend functionality to the gump descriptor and
> blocks-build.xsl. I.e. the user does not need to care and to know about
> the dependencies.
I will not be sure of that. What can I think if I know I need FOP and no
Batik and I saw that the build system is including Batik? Is this a bug or
a feature?
I think this is just a matter to inform the users about dependecies. We
have already commented many other files (cocoon.xconf, web.xml, etc) and
the comments has not other purpose that try to help users. The same apply
here, including dependencies into the build.properties.
We tell people: "Copy the build.properties to local.buld.properties and
changes this file as your needs." Then I saw fair tell them about block
dependencies.
BTW, I recommended the change because it takes me a day to understand why
my code that used FOP was not working (I set to exclude batik block) I did
it and the build system allow me to do that! Then my PDF stoped working
(blank pages) and nowhere was info about why this failed. I dont changed
the code at all! What happen here? Then I started a bug hunting and see
that somewhere in the catalina.out was the answer I was looking for. I
already have 1 year in the list and nowhere I saw nothing about the
dependecies between blocks.
Then I thinked that in order to avoid other people waste time (as I did),
we can improve a little by commenting about block dependencies the
block.properties file and write in wiki info about that.
But if you think all in all this is a non-sense issue, we go back.
> The dependencies are handled completely automatically
> - at least I hope so;
Hopping is fine, but the cruel reality is that this is currenlty not
working, remove cron and allow scratchpad block and you will see if this
is automatically. :)
Also I am not sure, but it seems there is another dependency (not tested
by me):
jfor requires FOP. Is this true? Please comments about that.
Best Regards,
Antonio Gallardo
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Joerg Heinicke <jh...@virbus.de>.
Ok, I tested it - it does not work. But it's /only/ a bug in the build
scripts, we should fix it and not be forced to maintain the dependencies
twice. A common message about dependencies should be enough for the
users IMO. (Couldn't we generate local.blocks.properties from gump.xml
and kick blocks.properties completely?)
The problem now is: With the block exclude set to true you can call the
dependency as often as you want - the excluded block is not build of
course and missed for the compiling of the dependent block.
Joerg
Bertrand Delacretaz wrote:
> Le Lundi, 8 sep 2003, à 22:10 Europe/Zurich, Joerg Heinicke a écrit :
>
>> Hmm, I'm not satisfied with the answer :-)
>>
>> Carsten has added a depend functionality to the gump descriptor and
>> blocks-build.xsl. I.e. the user does not need to care and to know
>> about the dependencies...
>
>
> In theory - but today I just tried to disable the cron block, leave the
> scratchpad block enabled and after a "build clean" scratchpad didn't
> compile. Do you see different results?
>
> -Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 8 sep 2003, à 22:10 Europe/Zurich, Joerg Heinicke a écrit :
> Hmm, I'm not satisfied with the answer :-)
>
> Carsten has added a depend functionality to the gump descriptor and
> blocks-build.xsl. I.e. the user does not need to care and to know
> about the dependencies...
In theory - but today I just tried to disable the cron block, leave the
scratchpad block enabled and after a "build clean" scratchpad didn't
compile. Do you see different results?
-Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Joerg Heinicke <jh...@virbus.de>.
Hmm, I'm not satisfied with the answer :-)
Carsten has added a depend functionality to the gump descriptor and
blocks-build.xsl. I.e. the user does not need to care and to know about
the dependencies. The dependencies are handled completely automatically
- at least I hope so; from a short look on the changes to
blocks-build.xsl I also think it does this. There is for example
following entry in the gump.xml:
<project name="cocoon-block-scratchpad">
<package>org.apache.cocoon</package>
<ant target="gump-block">
<property name="block-name" value="scratchpad"/>
<property name="version" value="@@DATE@@"/>
</ant>
<depend project="cocoon" inherit="all"/>
<depend project="castor"/>
<depend project="commons-jexl" inherit="all"/>
<depend project="jakarta-velocity" inherit="all"/>
<depend project="jakarta-servletapi-4"/>
<depend project="cocoon-block-velocity"/>
<depend project="cocoon-block-cron"/>
<work nested="tools/anttasks"/>
<home nested="build/cocoon-@@DATE@@"/>
<jar name="blocks/scratchpad-block.jar"/>
<nag from="Gump" to="dev@cocoon.apache.org"/>
</project>
and so the dependency on the cron block. The same is true for portal
block depending on the html block (because of JTidy).
Joerg
Bertrand Delacretaz wrote:
> Le Dimanche, 7 sep 2003, à 13:36 Europe/Zurich, Joerg Heinicke a écrit :
>
>> ...Isn't this now handled by the dependency in the gump descriptor? At
>> least I read something about library dependency on blocks (portal vs.
>> html). So do we need this comments in the properties files? Especially
>> for FOP it's only a dependency on the batik library....
>
>
> There are indeed dependencies between blocks at compile time - disabling
> the cron block, for example, prevents the scratchpad block from compiling.
>
> -Bertrand
Re: cvs commit: cocoon-2.1 blocks.properties
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Dimanche, 7 sep 2003, à 13:36 Europe/Zurich, Joerg Heinicke a écrit :
> ...Isn't this now handled by the dependency in the gump descriptor? At
> least I read something about library dependency on blocks (portal vs.
> html). So do we need this comments in the properties files? Especially
> for FOP it's only a dependency on the batik library....
There are indeed dependencies between blocks at compile time -
disabling the cron block, for example, prevents the scratchpad block
from compiling.
-Bertrand