You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Richard Doust <rd...@comcast.net> on 2003/06/21 19:45:24 UTC
I may be wrong but...
I'm not certain I'm right, but I have the sneaking suspicion that the build
the way it's written right now cannot possibly work. As far as I know,
there's no way to unset a property in ant. The "unless" attribute of a
target will not build the target if the property is "set". As far as I can
see, this means if it has any value at all. The only way to overcome this is
to modify build.properties to remove the setting of those property values.
It cannot be overridden by copying build.properties to
local.build.properties and modifying that as suggested because it's not
possible to define them to a non-value.
I have commented those properties out of build.properties (and
local.build.properties) and this has solved my problem.
That's my two cents worth.
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Geoff Howard <co...@leverageweb.com>.
Well, the book was written long before the cvs move was even
thought of - in fact IIRC it was written fairly early even
in the life of 2.0.x (around 2.0.2?) so it is even out of
date with that branch in places. But that is in no way
a knock against the book. It does an excellent job of
explaining the core concepts. I think the authors (who
are all very involved in cocoon and on these lists) do
maintain an errata page somewhere but don't know if it
was mentioned in the book.
Based on your interest in learning the framework, it sounds
like you are best off using 2.1, studying the book but stay
on the lookout for differences. Ultimately, you'll need to
check against the code, the current docs (at the site, or built
locally), the wiki (http://wiki.cocoondev.org) and these lists
when you suspect a conflict or change. Regrettably, the official
documentation in some places will be the least reliable at the
moment. Let us know any problems you spot.
If something doesn't work as expected you should be suspicious
of your information before cocoon. It of course is not
perfect but it is actively worked on by a lot of people and
something obvious like huge sections of the samples not working
would not go 24 hours without notice. The 2.1 branch is being
prepared for beta stage, so it should be very stable right now.
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 5:36 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> Thanks Geoff,
> The book says to get xml-cocoon2 from cvs (if you want to compile it
> yourself).
> I didn't notice any advice in the book notifying me that I ought to look
> on-line at any errata page. That might have helped. Do you have
> any input to
> the authors and or publisher?
> Do you know, are there any huge differences between 2.0 and 2.1 that would
> make it better for me to use 2.0? I'm more interested in learning the
> framework and using than learning the book. I always buy the books to
> support the open source projects and because I like to read at other
> locations than sitting at my computer.
> Thanks again.
>
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Saturday, June 21, 2003 5:52 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> You are working with the wrong repository. They were switched
> around a few
> months ago and the soft links between them do not function as they were
> supposed to - as a result that repository is stuck in time (and had the
> exact build problem you noticed which cropped up right before the name
> migration and was fixed soon after). The correct repository names are:
>
> cocoon-2.1 (build.properties is at version 1.21 or so)
> cocoon-2.0
>
> If you're trying to work with the latest work, you want
> cocoon-2.1. If you
> want a version that will be closer to what you see in the book, use
> cocoon-2.0. The current release of 2.0 is 2.0.4 but there are some bug
> fixes in head that make it worth getting 2.0.5 if you don't have a problem
> with cvs.
>
> Where did you find the instructions to use xml-cocoon2 so we can
> work to fix
> them.
> I think though having been through this with unsuspecting users a
> few times
> now,
> we need to take a second look at ways to more agressively point people in
> the right
> place.
>
> Though it was painful the name change helped a lot - cvs was
> really bogging
> down
> on two active branches with a lot of changes. Sorry it's burned you.
>
> Geoff
>
> > -----Original Message-----
> > From: Richard Doust [mailto:rdoust@comcast.net]
> > Sent: Saturday, June 21, 2003 3:32 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > I downloaded xml-cocoon2 from cvs to my local file system today. The tip
> > revision of build.properties that came to my system, (rev 1.15) reads as
> > follows:
> >
> > #----------------------------------------------
> > # Cocoon Build Properties
> > #----------------------------------------------
> >
> > # NOTE: don't modify this file directly but copy the properties you need
> > # to modify over to a file named 'local.build.properties' and
> modify that.
> > # The build system will overwrite these properties with the ones in the
> > # 'local.build.properties' file.
> >
> > # ----
> > Webapp
> ------------------------------------------------------------------
> >
> > exclude.webapp.documentation=true
> > exclude.webapp.javadocs=true
> > exclude.webapp.scratchpad=true
> > exclude.webapp.samples=true
> >
> > exclude.scratchpad=true
> > exclude.deprecated=true
> > .
> > .
> > .
> > .
> >
> > Notice that the exclude.webapp.documentation and exclude.webapp.samples
> > etal. are _not_ commented out. In order to build these targets
> > build.properties has to be modified.
> >
> > But that's okay because really the result of the build doesn't
> > work in many
> > more ways than that. I got rid of that code and went with the stable (?)
> > 2.1m2 release that's made available as a zip from somewhere and
> > built it and
> > it works fine. I'll just go with that.
> >
> > Thanks for your help.
> >
> >
> >
> > -----Original Message-----
> > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > Sent: Saturday, June 21, 2003 3:39 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > We're either looking at different files or you are misunderstanding
> > something
> > you're seeing. Which property are you looking at specifically?
> >
> > Geoff
> >
> > > -----Original Message-----
> > > From: Richard Doust [mailto:rdoust@comcast.net]
> > > Sent: Saturday, June 21, 2003 2:52 PM
> > > To: cocoon-users@xml.apache.org
> > > Subject: RE: I may be wrong but...
> > >
> > >
> > > In the latest code (tip) that I brought down from cvs today,
> the exclude
> > > properties are _not_ commented out in the build.properties
> file. It was
> > > necessary for me to edit this file and comment them out.
> > > Is it the case that I shouldn't be bringing down the tip?
> > >
> > > -----Original Message-----
> > > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > > Sent: Saturday, June 21, 2003 2:58 PM
> > > To: cocoon-users@xml.apache.org
> > > Subject: RE: I may be wrong but...
> > >
> > >
> > > You are right that properties in ant once set are not
> modified. If you
> > > look carefully the values that depend on any value are
> commented out in
> > > build.properties - uncommenting them in your local copy will
> accomplish
> > > exactly what is meant.
> > >
> > > Also notice the order in which the properties are read:
> > >
> > > <!-- Allow users a chance to override without editing the
> > > main file -->
> > > <property file="${user.home}/cocoon.build.properties"/>
> > > <property file="local.build.properties"/>
> > >
> > > <!-- Get the build properties from an external file -->
> > > <property file="build.properties"/>
> > >
> > > <!-- Allow users a chance to override without editing the
> > > main file -->
> > > <property file="${user.home}/cocoon.blocks.properties"/>
> > > <property file="local.blocks.properties"/>
> > >
> > > <!-- Get the block properties from an external file -->
> > > <property file="blocks.properties"/>
> > >
> > > So, the cocoon.build.properties in your homedirectory is loaded first,
> > > then the local.build.properties, then build.properties. The first one
> > > to set the value wins, and Cocoon gives you two shots at them before
> > > the default apply.
> > >
> > > HTH,
> > > Geoff
> > >
> > > > -----Original Message-----
> > > > From: Richard Doust [mailto:rdoust@comcast.net]
> > > > Sent: Saturday, June 21, 2003 1:45 PM
> > > > To: cocoon-users@xml.apache.org
> > > > Subject: I may be wrong but...
> > > >
> > > >
> > > > I'm not certain I'm right, but I have the sneaking suspicion that
> > > > the build
> > > > the way it's written right now cannot possibly work. As far
> as I know,
> > > > there's no way to unset a property in ant. The "unless"
> attribute of a
> > > > target will not build the target if the property is "set". As
> > > far as I can
> > > > see, this means if it has any value at all. The only way to
> > > > overcome this is
> > > > to modify build.properties to remove the setting of those
> > > property values.
> > > > It cannot be overridden by copying build.properties to
> > > > local.build.properties and modifying that as suggested
> > because it's not
> > > > possible to define them to a non-value.
> > > > I have commented those properties out of build.properties (and
> > > > local.build.properties) and this has solved my problem.
> > > > That's my two cents worth.
> > > > Rich
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Richard Doust <rd...@comcast.net>.
Thanks Geoff,
The book says to get xml-cocoon2 from cvs (if you want to compile it
yourself).
I didn't notice any advice in the book notifying me that I ought to look
on-line at any errata page. That might have helped. Do you have any input to
the authors and or publisher?
Do you know, are there any huge differences between 2.0 and 2.1 that would
make it better for me to use 2.0? I'm more interested in learning the
framework and using than learning the book. I always buy the books to
support the open source projects and because I like to read at other
locations than sitting at my computer.
Thanks again.
-----Original Message-----
From: Geoff Howard [mailto:cocoon@leverageweb.com]
Sent: Saturday, June 21, 2003 5:52 PM
To: cocoon-users@xml.apache.org
Subject: RE: I may be wrong but...
You are working with the wrong repository. They were switched around a few
months ago and the soft links between them do not function as they were
supposed to - as a result that repository is stuck in time (and had the
exact build problem you noticed which cropped up right before the name
migration and was fixed soon after). The correct repository names are:
cocoon-2.1 (build.properties is at version 1.21 or so)
cocoon-2.0
If you're trying to work with the latest work, you want cocoon-2.1. If you
want a version that will be closer to what you see in the book, use
cocoon-2.0. The current release of 2.0 is 2.0.4 but there are some bug
fixes in head that make it worth getting 2.0.5 if you don't have a problem
with cvs.
Where did you find the instructions to use xml-cocoon2 so we can work to fix
them.
I think though having been through this with unsuspecting users a few times
now,
we need to take a second look at ways to more agressively point people in
the right
place.
Though it was painful the name change helped a lot - cvs was really bogging
down
on two active branches with a lot of changes. Sorry it's burned you.
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 3:32 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> I downloaded xml-cocoon2 from cvs to my local file system today. The tip
> revision of build.properties that came to my system, (rev 1.15) reads as
> follows:
>
> #----------------------------------------------
> # Cocoon Build Properties
> #----------------------------------------------
>
> # NOTE: don't modify this file directly but copy the properties you need
> # to modify over to a file named 'local.build.properties' and modify that.
> # The build system will overwrite these properties with the ones in the
> # 'local.build.properties' file.
>
> # ----
> Webapp ------------------------------------------------------------------
>
> exclude.webapp.documentation=true
> exclude.webapp.javadocs=true
> exclude.webapp.scratchpad=true
> exclude.webapp.samples=true
>
> exclude.scratchpad=true
> exclude.deprecated=true
> .
> .
> .
> .
>
> Notice that the exclude.webapp.documentation and exclude.webapp.samples
> etal. are _not_ commented out. In order to build these targets
> build.properties has to be modified.
>
> But that's okay because really the result of the build doesn't
> work in many
> more ways than that. I got rid of that code and went with the stable (?)
> 2.1m2 release that's made available as a zip from somewhere and
> built it and
> it works fine. I'll just go with that.
>
> Thanks for your help.
>
>
>
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Saturday, June 21, 2003 3:39 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> We're either looking at different files or you are misunderstanding
> something
> you're seeing. Which property are you looking at specifically?
>
> Geoff
>
> > -----Original Message-----
> > From: Richard Doust [mailto:rdoust@comcast.net]
> > Sent: Saturday, June 21, 2003 2:52 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > In the latest code (tip) that I brought down from cvs today, the exclude
> > properties are _not_ commented out in the build.properties file. It was
> > necessary for me to edit this file and comment them out.
> > Is it the case that I shouldn't be bringing down the tip?
> >
> > -----Original Message-----
> > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > Sent: Saturday, June 21, 2003 2:58 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > You are right that properties in ant once set are not modified. If you
> > look carefully the values that depend on any value are commented out in
> > build.properties - uncommenting them in your local copy will accomplish
> > exactly what is meant.
> >
> > Also notice the order in which the properties are read:
> >
> > <!-- Allow users a chance to override without editing the
> > main file -->
> > <property file="${user.home}/cocoon.build.properties"/>
> > <property file="local.build.properties"/>
> >
> > <!-- Get the build properties from an external file -->
> > <property file="build.properties"/>
> >
> > <!-- Allow users a chance to override without editing the
> > main file -->
> > <property file="${user.home}/cocoon.blocks.properties"/>
> > <property file="local.blocks.properties"/>
> >
> > <!-- Get the block properties from an external file -->
> > <property file="blocks.properties"/>
> >
> > So, the cocoon.build.properties in your homedirectory is loaded first,
> > then the local.build.properties, then build.properties. The first one
> > to set the value wins, and Cocoon gives you two shots at them before
> > the default apply.
> >
> > HTH,
> > Geoff
> >
> > > -----Original Message-----
> > > From: Richard Doust [mailto:rdoust@comcast.net]
> > > Sent: Saturday, June 21, 2003 1:45 PM
> > > To: cocoon-users@xml.apache.org
> > > Subject: I may be wrong but...
> > >
> > >
> > > I'm not certain I'm right, but I have the sneaking suspicion that
> > > the build
> > > the way it's written right now cannot possibly work. As far as I know,
> > > there's no way to unset a property in ant. The "unless" attribute of a
> > > target will not build the target if the property is "set". As
> > far as I can
> > > see, this means if it has any value at all. The only way to
> > > overcome this is
> > > to modify build.properties to remove the setting of those
> > property values.
> > > It cannot be overridden by copying build.properties to
> > > local.build.properties and modifying that as suggested
> because it's not
> > > possible to define them to a non-value.
> > > I have commented those properties out of build.properties (and
> > > local.build.properties) and this has solved my problem.
> > > That's my two cents worth.
> > > Rich
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Geoff Howard <co...@leverageweb.com>.
You are working with the wrong repository. They were switched around a few
months ago and the soft links between them do not function as they were
supposed to - as a result that repository is stuck in time (and had the
exact build problem you noticed which cropped up right before the name
migration and was fixed soon after). The correct repository names are:
cocoon-2.1 (build.properties is at version 1.21 or so)
cocoon-2.0
If you're trying to work with the latest work, you want cocoon-2.1. If you
want a version that will be closer to what you see in the book, use
cocoon-2.0. The current release of 2.0 is 2.0.4 but there are some bug
fixes in head that make it worth getting 2.0.5 if you don't have a problem
with cvs.
Where did you find the instructions to use xml-cocoon2 so we can work to fix
them.
I think though having been through this with unsuspecting users a few times
now,
we need to take a second look at ways to more agressively point people in
the right
place.
Though it was painful the name change helped a lot - cvs was really bogging
down
on two active branches with a lot of changes. Sorry it's burned you.
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 3:32 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> I downloaded xml-cocoon2 from cvs to my local file system today. The tip
> revision of build.properties that came to my system, (rev 1.15) reads as
> follows:
>
> #----------------------------------------------
> # Cocoon Build Properties
> #----------------------------------------------
>
> # NOTE: don't modify this file directly but copy the properties you need
> # to modify over to a file named 'local.build.properties' and modify that.
> # The build system will overwrite these properties with the ones in the
> # 'local.build.properties' file.
>
> # ----
> Webapp ------------------------------------------------------------------
>
> exclude.webapp.documentation=true
> exclude.webapp.javadocs=true
> exclude.webapp.scratchpad=true
> exclude.webapp.samples=true
>
> exclude.scratchpad=true
> exclude.deprecated=true
> .
> .
> .
> .
>
> Notice that the exclude.webapp.documentation and exclude.webapp.samples
> etal. are _not_ commented out. In order to build these targets
> build.properties has to be modified.
>
> But that's okay because really the result of the build doesn't
> work in many
> more ways than that. I got rid of that code and went with the stable (?)
> 2.1m2 release that's made available as a zip from somewhere and
> built it and
> it works fine. I'll just go with that.
>
> Thanks for your help.
>
>
>
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Saturday, June 21, 2003 3:39 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> We're either looking at different files or you are misunderstanding
> something
> you're seeing. Which property are you looking at specifically?
>
> Geoff
>
> > -----Original Message-----
> > From: Richard Doust [mailto:rdoust@comcast.net]
> > Sent: Saturday, June 21, 2003 2:52 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > In the latest code (tip) that I brought down from cvs today, the exclude
> > properties are _not_ commented out in the build.properties file. It was
> > necessary for me to edit this file and comment them out.
> > Is it the case that I shouldn't be bringing down the tip?
> >
> > -----Original Message-----
> > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > Sent: Saturday, June 21, 2003 2:58 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: I may be wrong but...
> >
> >
> > You are right that properties in ant once set are not modified. If you
> > look carefully the values that depend on any value are commented out in
> > build.properties - uncommenting them in your local copy will accomplish
> > exactly what is meant.
> >
> > Also notice the order in which the properties are read:
> >
> > <!-- Allow users a chance to override without editing the
> > main file -->
> > <property file="${user.home}/cocoon.build.properties"/>
> > <property file="local.build.properties"/>
> >
> > <!-- Get the build properties from an external file -->
> > <property file="build.properties"/>
> >
> > <!-- Allow users a chance to override without editing the
> > main file -->
> > <property file="${user.home}/cocoon.blocks.properties"/>
> > <property file="local.blocks.properties"/>
> >
> > <!-- Get the block properties from an external file -->
> > <property file="blocks.properties"/>
> >
> > So, the cocoon.build.properties in your homedirectory is loaded first,
> > then the local.build.properties, then build.properties. The first one
> > to set the value wins, and Cocoon gives you two shots at them before
> > the default apply.
> >
> > HTH,
> > Geoff
> >
> > > -----Original Message-----
> > > From: Richard Doust [mailto:rdoust@comcast.net]
> > > Sent: Saturday, June 21, 2003 1:45 PM
> > > To: cocoon-users@xml.apache.org
> > > Subject: I may be wrong but...
> > >
> > >
> > > I'm not certain I'm right, but I have the sneaking suspicion that
> > > the build
> > > the way it's written right now cannot possibly work. As far as I know,
> > > there's no way to unset a property in ant. The "unless" attribute of a
> > > target will not build the target if the property is "set". As
> > far as I can
> > > see, this means if it has any value at all. The only way to
> > > overcome this is
> > > to modify build.properties to remove the setting of those
> > property values.
> > > It cannot be overridden by copying build.properties to
> > > local.build.properties and modifying that as suggested
> because it's not
> > > possible to define them to a non-value.
> > > I have commented those properties out of build.properties (and
> > > local.build.properties) and this has solved my problem.
> > > That's my two cents worth.
> > > Rich
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Richard Doust <rd...@comcast.net>.
I downloaded xml-cocoon2 from cvs to my local file system today. The tip
revision of build.properties that came to my system, (rev 1.15) reads as
follows:
#----------------------------------------------
# Cocoon Build Properties
#----------------------------------------------
# NOTE: don't modify this file directly but copy the properties you need
# to modify over to a file named 'local.build.properties' and modify that.
# The build system will overwrite these properties with the ones in the
# 'local.build.properties' file.
# ----
Webapp ------------------------------------------------------------------
exclude.webapp.documentation=true
exclude.webapp.javadocs=true
exclude.webapp.scratchpad=true
exclude.webapp.samples=true
exclude.scratchpad=true
exclude.deprecated=true
.
.
.
.
Notice that the exclude.webapp.documentation and exclude.webapp.samples
etal. are _not_ commented out. In order to build these targets
build.properties has to be modified.
But that's okay because really the result of the build doesn't work in many
more ways than that. I got rid of that code and went with the stable (?)
2.1m2 release that's made available as a zip from somewhere and built it and
it works fine. I'll just go with that.
Thanks for your help.
-----Original Message-----
From: Geoff Howard [mailto:cocoon@leverageweb.com]
Sent: Saturday, June 21, 2003 3:39 PM
To: cocoon-users@xml.apache.org
Subject: RE: I may be wrong but...
We're either looking at different files or you are misunderstanding
something
you're seeing. Which property are you looking at specifically?
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 2:52 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> In the latest code (tip) that I brought down from cvs today, the exclude
> properties are _not_ commented out in the build.properties file. It was
> necessary for me to edit this file and comment them out.
> Is it the case that I shouldn't be bringing down the tip?
>
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Saturday, June 21, 2003 2:58 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> You are right that properties in ant once set are not modified. If you
> look carefully the values that depend on any value are commented out in
> build.properties - uncommenting them in your local copy will accomplish
> exactly what is meant.
>
> Also notice the order in which the properties are read:
>
> <!-- Allow users a chance to override without editing the
> main file -->
> <property file="${user.home}/cocoon.build.properties"/>
> <property file="local.build.properties"/>
>
> <!-- Get the build properties from an external file -->
> <property file="build.properties"/>
>
> <!-- Allow users a chance to override without editing the
> main file -->
> <property file="${user.home}/cocoon.blocks.properties"/>
> <property file="local.blocks.properties"/>
>
> <!-- Get the block properties from an external file -->
> <property file="blocks.properties"/>
>
> So, the cocoon.build.properties in your homedirectory is loaded first,
> then the local.build.properties, then build.properties. The first one
> to set the value wins, and Cocoon gives you two shots at them before
> the default apply.
>
> HTH,
> Geoff
>
> > -----Original Message-----
> > From: Richard Doust [mailto:rdoust@comcast.net]
> > Sent: Saturday, June 21, 2003 1:45 PM
> > To: cocoon-users@xml.apache.org
> > Subject: I may be wrong but...
> >
> >
> > I'm not certain I'm right, but I have the sneaking suspicion that
> > the build
> > the way it's written right now cannot possibly work. As far as I know,
> > there's no way to unset a property in ant. The "unless" attribute of a
> > target will not build the target if the property is "set". As
> far as I can
> > see, this means if it has any value at all. The only way to
> > overcome this is
> > to modify build.properties to remove the setting of those
> property values.
> > It cannot be overridden by copying build.properties to
> > local.build.properties and modifying that as suggested because it's not
> > possible to define them to a non-value.
> > I have commented those properties out of build.properties (and
> > local.build.properties) and this has solved my problem.
> > That's my two cents worth.
> > Rich
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Geoff Howard <co...@leverageweb.com>.
We're either looking at different files or you are misunderstanding
something
you're seeing. Which property are you looking at specifically?
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 2:52 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> In the latest code (tip) that I brought down from cvs today, the exclude
> properties are _not_ commented out in the build.properties file. It was
> necessary for me to edit this file and comment them out.
> Is it the case that I shouldn't be bringing down the tip?
>
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Saturday, June 21, 2003 2:58 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: I may be wrong but...
>
>
> You are right that properties in ant once set are not modified. If you
> look carefully the values that depend on any value are commented out in
> build.properties - uncommenting them in your local copy will accomplish
> exactly what is meant.
>
> Also notice the order in which the properties are read:
>
> <!-- Allow users a chance to override without editing the
> main file -->
> <property file="${user.home}/cocoon.build.properties"/>
> <property file="local.build.properties"/>
>
> <!-- Get the build properties from an external file -->
> <property file="build.properties"/>
>
> <!-- Allow users a chance to override without editing the
> main file -->
> <property file="${user.home}/cocoon.blocks.properties"/>
> <property file="local.blocks.properties"/>
>
> <!-- Get the block properties from an external file -->
> <property file="blocks.properties"/>
>
> So, the cocoon.build.properties in your homedirectory is loaded first,
> then the local.build.properties, then build.properties. The first one
> to set the value wins, and Cocoon gives you two shots at them before
> the default apply.
>
> HTH,
> Geoff
>
> > -----Original Message-----
> > From: Richard Doust [mailto:rdoust@comcast.net]
> > Sent: Saturday, June 21, 2003 1:45 PM
> > To: cocoon-users@xml.apache.org
> > Subject: I may be wrong but...
> >
> >
> > I'm not certain I'm right, but I have the sneaking suspicion that
> > the build
> > the way it's written right now cannot possibly work. As far as I know,
> > there's no way to unset a property in ant. The "unless" attribute of a
> > target will not build the target if the property is "set". As
> far as I can
> > see, this means if it has any value at all. The only way to
> > overcome this is
> > to modify build.properties to remove the setting of those
> property values.
> > It cannot be overridden by copying build.properties to
> > local.build.properties and modifying that as suggested because it's not
> > possible to define them to a non-value.
> > I have commented those properties out of build.properties (and
> > local.build.properties) and this has solved my problem.
> > That's my two cents worth.
> > Rich
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Richard Doust <rd...@comcast.net>.
In the latest code (tip) that I brought down from cvs today, the exclude
properties are _not_ commented out in the build.properties file. It was
necessary for me to edit this file and comment them out.
Is it the case that I shouldn't be bringing down the tip?
-----Original Message-----
From: Geoff Howard [mailto:cocoon@leverageweb.com]
Sent: Saturday, June 21, 2003 2:58 PM
To: cocoon-users@xml.apache.org
Subject: RE: I may be wrong but...
You are right that properties in ant once set are not modified. If you
look carefully the values that depend on any value are commented out in
build.properties - uncommenting them in your local copy will accomplish
exactly what is meant.
Also notice the order in which the properties are read:
<!-- Allow users a chance to override without editing the main file -->
<property file="${user.home}/cocoon.build.properties"/>
<property file="local.build.properties"/>
<!-- Get the build properties from an external file -->
<property file="build.properties"/>
<!-- Allow users a chance to override without editing the main file -->
<property file="${user.home}/cocoon.blocks.properties"/>
<property file="local.blocks.properties"/>
<!-- Get the block properties from an external file -->
<property file="blocks.properties"/>
So, the cocoon.build.properties in your homedirectory is loaded first,
then the local.build.properties, then build.properties. The first one
to set the value wins, and Cocoon gives you two shots at them before
the default apply.
HTH,
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 1:45 PM
> To: cocoon-users@xml.apache.org
> Subject: I may be wrong but...
>
>
> I'm not certain I'm right, but I have the sneaking suspicion that
> the build
> the way it's written right now cannot possibly work. As far as I know,
> there's no way to unset a property in ant. The "unless" attribute of a
> target will not build the target if the property is "set". As far as I can
> see, this means if it has any value at all. The only way to
> overcome this is
> to modify build.properties to remove the setting of those property values.
> It cannot be overridden by copying build.properties to
> local.build.properties and modifying that as suggested because it's not
> possible to define them to a non-value.
> I have commented those properties out of build.properties (and
> local.build.properties) and this has solved my problem.
> That's my two cents worth.
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: I may be wrong but...
Posted by Geoff Howard <co...@leverageweb.com>.
You are right that properties in ant once set are not modified. If you
look carefully the values that depend on any value are commented out in
build.properties - uncommenting them in your local copy will accomplish
exactly what is meant.
Also notice the order in which the properties are read:
<!-- Allow users a chance to override without editing the main file -->
<property file="${user.home}/cocoon.build.properties"/>
<property file="local.build.properties"/>
<!-- Get the build properties from an external file -->
<property file="build.properties"/>
<!-- Allow users a chance to override without editing the main file -->
<property file="${user.home}/cocoon.blocks.properties"/>
<property file="local.blocks.properties"/>
<!-- Get the block properties from an external file -->
<property file="blocks.properties"/>
So, the cocoon.build.properties in your homedirectory is loaded first,
then the local.build.properties, then build.properties. The first one
to set the value wins, and Cocoon gives you two shots at them before
the default apply.
HTH,
Geoff
> -----Original Message-----
> From: Richard Doust [mailto:rdoust@comcast.net]
> Sent: Saturday, June 21, 2003 1:45 PM
> To: cocoon-users@xml.apache.org
> Subject: I may be wrong but...
>
>
> I'm not certain I'm right, but I have the sneaking suspicion that
> the build
> the way it's written right now cannot possibly work. As far as I know,
> there's no way to unset a property in ant. The "unless" attribute of a
> target will not build the target if the property is "set". As far as I can
> see, this means if it has any value at all. The only way to
> overcome this is
> to modify build.properties to remove the setting of those property values.
> It cannot be overridden by copying build.properties to
> local.build.properties and modifying that as suggested because it's not
> possible to define them to a non-value.
> I have commented those properties out of build.properties (and
> local.build.properties) and this has solved my problem.
> That's my two cents worth.
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org