You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2003/03/15 04:26:18 UTC
exclusion of certain blocks from build is busted
About 4 days ago the build was changed to differently
handle the way blocks are excluded. Now it looks like
those properties are ignored.
Today one of the blocks is broken. I tried to get around
it as usual by un-commenting the line in local.blocks.properties
to no avail.
Would people please test before committing changes to
the build. This sort of thing just kills the productivity
of everyone else.
--David
Re: exclusion of certain blocks from build is busted
Posted by Stefano Mazzocchi <st...@apache.org>.
Bernhard Huber wrote:
> hi,
>
>> Today one of the blocks is broken. I tried to get around
>> it as usual by un-commenting the line in local.blocks.properties
>> to no avail.
>>
>>
> i made a CVS update, and had no problem running "build webapp",
> i even tried setting in local.block.properties all
> entries from
> #exclude.block.XXX=true to
> exclude.block.XXX=true
> and no block compilation was performed.
> which block is broken?
Same behavior experienced here.
In fact, before committing, I *DID* test the build exactly to avoid
potential issues.
Stefano.
Re: exclusion of certain blocks from build is busted
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> David Crossley wrote, On 18/03/2003 3.37:
>
>> Stefano Mazzocchi wrote:
>>
>>> David Crossley wrote:
>>
>>
>> <snip/>
>>
>>>> Found it - there is extra whitespace at the end of these
>>>> three lines in block.properties, i.e. after the =true
>>>>
>>>> Thank the lord, i am not going mad. Sounds like we
>>>> need normalize-space() whenever properties are read.
>>>> Call in the XSL/build experts.
>>>
>>>
>>> Oh, gosh, ant is *very* picky. Fixed in CVS.
>>
>>
>> Gee, i could have easily committed such a simple fix to
>> remove the extra whitespace. However, i left it because as
>> discussed above, it needs a more robust solution, like using
>> normalize-space() in the blocks-build.xsl, but i could not
>> see where to do this. Quick hacks just leave the way open for
>> the build to be busted again like this and causing someone
>> else three days of grief.
>
>
> I had moved the properties in xml files, so that the whitespace there is
> really easy to see. Why did we resort back to property files for it?
Because flat properties are much less verbose and much more friendly to
edit.
you have a point on whitespace, though, but I still think this is an ant
problem, not ours.
Stefano.
Re: exclusion of certain blocks from build is busted
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote, On 18/03/2003 3.37:
> Stefano Mazzocchi wrote:
>
>>David Crossley wrote:
>
> <snip/>
>
>>>Found it - there is extra whitespace at the end of these
>>>three lines in block.properties, i.e. after the =true
>>>
>>>Thank the lord, i am not going mad. Sounds like we
>>>need normalize-space() whenever properties are read.
>>>Call in the XSL/build experts.
>>
>>Oh, gosh, ant is *very* picky. Fixed in CVS.
>
> Gee, i could have easily committed such a simple fix to
> remove the extra whitespace. However, i left it because as
> discussed above, it needs a more robust solution, like using
> normalize-space() in the blocks-build.xsl, but i could not
> see where to do this. Quick hacks just leave the way open for
> the build to be busted again like this and causing someone
> else three days of grief.
I had moved the properties in xml files, so that the whitespace there is
really easy to see. Why did we resort back to property files for it?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: exclusion of certain blocks from build is busted
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
> Stefano Mazzocchi wrote:
>
>>David Crossley wrote:
>
> <snip/>
>
>>>Found it - there is extra whitespace at the end of these
>>>three lines in block.properties, i.e. after the =true
>>>
>>>Thank the lord, i am not going mad. Sounds like we
>>>need normalize-space() whenever properties are read.
>>>Call in the XSL/build experts.
>>
>>Oh, gosh, ant is *very* picky. Fixed in CVS.
>
>
> Gee, i could have easily committed such a simple fix to
> remove the extra whitespace. However, i left it because as
> discussed above, it needs a more robust solution, like using
> normalize-space() in the blocks-build.xsl, but i could not
> see where to do this. Quick hacks just leave the way open for
> the build to be busted again like this and causing someone
> else three days of grief.
David, I'm not trying to be abnoxious, I just fix it *now* but I didn't
want to rule out better solutions.
Now, since the properties are *NOT* loaded by xslt, we can't use any
normalized-space() thing.
I think it's the <istrue> <condition> in ant that needs to strip
whitespace before avaluating. Maybe we could submit a bug report there.
Stefano.
Re: exclusion of certain blocks from build is busted
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> David Crossley wrote:
<snip/>
> > Found it - there is extra whitespace at the end of these
> > three lines in block.properties, i.e. after the =true
> >
> > Thank the lord, i am not going mad. Sounds like we
> > need normalize-space() whenever properties are read.
> > Call in the XSL/build experts.
>
> Oh, gosh, ant is *very* picky. Fixed in CVS.
Gee, i could have easily committed such a simple fix to
remove the extra whitespace. However, i left it because as
discussed above, it needs a more robust solution, like using
normalize-space() in the blocks-build.xsl, but i could not
see where to do this. Quick hacks just leave the way open for
the build to be busted again like this and causing someone
else three days of grief.
--David
Re: exclusion of certain blocks from build is busted
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
>
>>David Crossley wrote:
>>
>>>Stefano Mazzocchi wrote:
>>><snip/>
>>>
>>>>try to do a clean checkout, maybe there is something wrong in
>>>>your local CVS metadata.
>>>>
>>>>ah, no, wait, what settings are you using for cvs update?
>>>
>>>cvs -q -z3 update -d -P cocoon-2.1
>>>
>>>Okay, i will try the full clean checkout.
>>
>>That fixed it, whatever it was. I do not know if
>>this had anything to do with it, but i did rename
>>my local working copy rather than do a fresh checkout.
>>Everything worked okay for a few days after that, then
>>started misbehaving recently.
>
>
> Erk. I spoke too soon. I got past the building of the
> Lucene block (no errors now with the clean checkout).
>
> However, i still cannot exclude the Lucene block from the build.
>
> I investigated a bit further and tried to exclude *all* blocks.
> All blocks are excluded except three: lucene, poi, profiler.
>
> Strangeness.
>
> Found it - there is extra whitespace at the end of these
> three lines in block.properties, i.e. after the =true
>
> Thank the lord, i am not going mad. Sounds like we
> need normalize-space() whenever properties are read.
> Call in the XSL/build experts.
Oh, gosh, ant is *very* picky. Fixed in CVS.
Stefano.
Re: exclusion of certain blocks from build is busted
Posted by David Crossley <cr...@indexgeo.com.au>.
David Crossley wrote:
> David Crossley wrote:
> > Stefano Mazzocchi wrote:
> > <snip/>
> > > try to do a clean checkout, maybe there is something wrong in
> > > your local CVS metadata.
> > >
> > > ah, no, wait, what settings are you using for cvs update?
> >
> > cvs -q -z3 update -d -P cocoon-2.1
> >
> > Okay, i will try the full clean checkout.
>
> That fixed it, whatever it was. I do not know if
> this had anything to do with it, but i did rename
> my local working copy rather than do a fresh checkout.
> Everything worked okay for a few days after that, then
> started misbehaving recently.
Erk. I spoke too soon. I got past the building of the
Lucene block (no errors now with the clean checkout).
However, i still cannot exclude the Lucene block from the build.
I investigated a bit further and tried to exclude *all* blocks.
All blocks are excluded except three: lucene, poi, profiler.
Strangeness.
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need normalize-space() whenever properties are read.
Call in the XSL/build experts.
--David
Re: exclusion of certain blocks from build is busted
Posted by David Crossley <cr...@indexgeo.com.au>.
David Crossley wrote:
> Stefano Mazzocchi wrote:
> <snip/>
> > try to do a clean checkout, maybe there is something wrong in
> > your local CVS metadata.
> >
> > ah, no, wait, what settings are you using for cvs update?
>
> cvs -q -z3 update -d -P cocoon-2.1
>
> Okay, i will try the full clean checkout.
That fixed it, whatever it was. I do not know if
this had anything to do with it, but i did rename
my local working copy rather than do a fresh checkout.
Everything worked okay for a few days after that, then
started misbehaving recently.
--David
Re: exclusion of certain blocks from build is busted
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
<snip/>
> try to do a clean checkout, maybe there is something wrong in
> your local CVS metadata.
>
> ah, no, wait, what settings are you using for cvs update?
cvs -q -z3 update -d -P cocoon-2.1
Okay, i will try the full clean checkout.
--David
Re: exclusion of certain blocks from build is busted
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
> Bernhard Huber wrote:
>
>>David Crossley wrote:
>>
>>>Today one of the blocks is broken. I tried to get around
>>>it as usual by un-commenting the line in local.blocks.properties
>>>to no avail.
>>
>>i made a CVS update, and had no problem running "build webapp",
>>i even tried setting in local.block.properties all
>>entries from
>>#exclude.block.XXX=true to
>>exclude.block.XXX=true
>>and no block compilation was performed.
>>which block is broken?
>
>
> Thanks to Bernhard and Stefano for following up.
>
> However, i still get the same problem with today's CVS.
> The Lucene block is broken and i cannot get around it.
>
> cvs update cocoon-2.1 ... no issues
> ./build.sh clean
> ./build.sh webapp
> --------------------------
> ...
> .../cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/
> LuceneIndexTransformer.java:75: cannot resolve symbol
> symbol : class NOPCacheValidity
> location: package caching
> import org.apache.cocoon.caching.NOPCacheValidity;
> ^
> .../cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/
> LuceneIndexTransformer.java:212: cannot resolve symbol
> symbol : variable NOPCacheValidity
> location: class org.apache.cocoon.transformation.LuceneIndexTransformer
> return NOPCacheValidity.CACHE_VALIDITY;
> ^
> 2 errors
> ...
> --------------------------
>
> vi local.blocks.properties
> un-comment the lucene block to exclude it
> ./build.sh clean
> ./build.sh webapp
> ... same problem.
>
> So i am confused.
I'm sorry, David, but everything works fine here. Lucene compiles, with
and without the deprecated classes. All blocks can be commented out from
local.block.properties and all doing just as it's supposed to be.
try to do a clean checkout, maybe there is something wrong in your local
CVS metadata.
ah, no, wait, what settings are you using for cvs update?
Re: exclusion of certain blocks from build is busted
Posted by David Crossley <cr...@indexgeo.com.au>.
Bernhard Huber wrote:
> David Crossley wrote:
> >Today one of the blocks is broken. I tried to get around
> >it as usual by un-commenting the line in local.blocks.properties
> >to no avail.
>
> i made a CVS update, and had no problem running "build webapp",
> i even tried setting in local.block.properties all
> entries from
> #exclude.block.XXX=true to
> exclude.block.XXX=true
> and no block compilation was performed.
> which block is broken?
Thanks to Bernhard and Stefano for following up.
However, i still get the same problem with today's CVS.
The Lucene block is broken and i cannot get around it.
cvs update cocoon-2.1 ... no issues
./build.sh clean
./build.sh webapp
--------------------------
...
.../cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/
LuceneIndexTransformer.java:75: cannot resolve symbol
symbol : class NOPCacheValidity
location: package caching
import org.apache.cocoon.caching.NOPCacheValidity;
^
.../cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/
LuceneIndexTransformer.java:212: cannot resolve symbol
symbol : variable NOPCacheValidity
location: class org.apache.cocoon.transformation.LuceneIndexTransformer
return NOPCacheValidity.CACHE_VALIDITY;
^
2 errors
...
--------------------------
vi local.blocks.properties
un-comment the lucene block to exclude it
./build.sh clean
./build.sh webapp
... same problem.
So i am confused.
--David
Re: exclusion of certain blocks from build is busted
Posted by Bernhard Huber <be...@a1.net>.
hi,
>Today one of the blocks is broken. I tried to get around
>it as usual by un-commenting the line in local.blocks.properties
>to no avail.
>
>
i made a CVS update, and had no problem running "build webapp",
i even tried setting in local.block.properties all
entries from
#exclude.block.XXX=true to
exclude.block.XXX=true
and no block compilation was performed.
which block is broken?
bernhard