You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by de...@canoo.com on 2003/02/05 16:31:54 UTC
unset a property of a project.
Hi,
is there a way to easily unset a property within a project ?
As with Ant1.5 the getProperties() returns a copy of the hashtable I cannot
see a elegant way to do this.
any suggestions `?
thanks,
detlef
Re: unset a property of a project.
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Friday, February 07, 2003 00:44
Subject: Re: unset a property of a project.
> > 3. Depending on which set of unit tests fail, I want to send e-mail to
> > a particular individual or group. I cannot do <property name="mail.to"
> > value="firstgroup@somewhere.com"/>, <antcall target="sendMessage"/>
> > followed by <property name="mail.to"
> > value="secondgroup@somewhere.com"/>, <antcall target"sendMessage"/>.
> > Instead I have to do something like <property
> > name="mail.to.firstgroup" value="..."/> etc. Same logic applies to
> > subject, message body, and mail server.
>
> This could be handled by some clever use of the ant-contrib
> <propertycopy> task. (In fact, I'd like to see this task migrated to
> Ant's codebase)
What is wrong with setting the mail.to property *inside the <antcall>
declaration using a <param> declaration, rather than outside in <property>.
The property will be immutable during its life, but its life will be
somewhat shorter than usual.
Re: unset a property of a project.
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
On Friday, February 7, 2003, at 02:25 AM, Dale Anson wrote:
> I can think of several cases for unsetting or resetting a property:
>
> 1. <timestamp/> cannot be called repeatedly with the same property.
You mean <tstamp>, I presume. This is why there is a 'prefix'
attribute on that task, allowing you to set timestamps within different
"namespaces".
> 2. Ditto for <input/>
I've not had a need to use <input> but why not just have different
property names for each input item?
> 3. Depending on which set of unit tests fail, I want to send e-mail to
> a particular individual or group. I cannot do <property name="mail.to"
> value="firstgroup@somewhere.com"/>, <antcall target="sendMessage"/>
> followed by <property name="mail.to"
> value="secondgroup@somewhere.com"/>, <antcall target"sendMessage"/>.
> Instead I have to do something like <property
> name="mail.to.firstgroup" value="..."/> etc. Same logic applies to
> subject, message body, and mail server.
This could be handled by some clever use of the ant-contrib
<propertycopy> task. (In fact, I'd like to see this task migrated to
Ant's codebase)
> I've written a number of tasks that address these "problems". I
> realize they are not necessarily the "Ant way" of doing things, but
> are a natural way for many developers. In particular, I've written a
> <var> task that is a mutable property. This is a flat out misuse of
> Ant properties, but is very handy. Basically, it uses the publicly
> accessible user properties hashtable in org.apache.ant.Project to read
> and write properties. As the user property hashtable takes precedence
> over the other properties hashtable, it is also possible to override a
> regular property. So constructs like this are possible:
Hmmmm..... I thought we changed the API to return a copy of the
Hashtable rather than the one used by Project. I haven't gone to the
code to re-verify though.
> <property name="doit" value="false"/>
> <target name="dosomething" if="doit">
> ...
> </target>
>
> It is counter-intuitive to think that the "dosomething" target would
> execute since "doit" is false. This is much more intuitive:
> <property name="doit" value="false"/>
> <target name="dosomething">
> <if name="doit" value="true">
> <!-- now do it -->
> </if>
> </target>
No argument about the if/unless constructs in Ant. They are a bit
confusing, no question.
> Anyway, I've rambled and ranted enough. The tasks I mentioned are
> available at antelope.sourceforge.net. Just this morning I finished
> <antcallback>, which is identical to <antcall> except it supports a
> "return" parameter, so you can do something like this:
> <target...>
> <antcallback target="setAValue" return="a"/>
> <echo>${a}</echo> <!-- will print out got it -->
> </target>
>
> <target name="setAValue">
> <property name="a" value="got it"/>
> </target>
Very interesting.
> I'll probably post this task on sourceforge tomorrow. There is already
> an <antfetch> which does almost the same thing for <ant>.
You're definitely pushing the limits of Ant's intent and design, but it
looks like you've found enough extensibility options to satisfy your
needs, and that is a good thing, even if Ant itself will not
incorporate these features.
I personally use ant-contrib's <propertycopy> task in all my builds now.
Erik
Re: unset a property of a project.
Posted by Dale Anson <da...@germane-software.com>.
I can think of several cases for unsetting or resetting a property:
1. <timestamp/> cannot be called repeatedly with the same property.
2. Ditto for <input/>
3. Depending on which set of unit tests fail, I want to send e-mail to a
particular individual or group. I cannot do <property name="mail.to"
value="firstgroup@somewhere.com"/>, <antcall target="sendMessage"/>
followed by <property name="mail.to"
value="secondgroup@somewhere.com"/>, <antcall target"sendMessage"/>.
Instead I have to do something like <property name="mail.to.firstgroup"
value="..."/> etc. Same logic applies to subject, message body, and mail
server.
4. Building a list of modules for the <foreach/> task. I know this isn't
an official task, but it is handy in certain situations. It would be
nice to be able to append to a property depending on what modules are
available.
There are many more, these are just off the top of my head. I realize
that the original intent of Ant was to NOT be a scripting language, but
in day to day use, that is exactly what it has become. Getting
properties set from calling <ant> or <antcall> is a common question on
the user list. Many Ant users are Java programmers, and are looking for
similar constructs in Ant that they are used to in Java.
I've written a number of tasks that address these "problems". I realize
they are not necessarily the "Ant way" of doing things, but are a
natural way for many developers. In particular, I've written a <var>
task that is a mutable property. This is a flat out misuse of Ant
properties, but is very handy. Basically, it uses the publicly
accessible user properties hashtable in org.apache.ant.Project to read
and write properties. As the user property hashtable takes precedence
over the other properties hashtable, it is also possible to override a
regular property. So constructs like this are possible:
<property name="a" value="a"/>
<echo>${a}</echo> <!-- will print out a -->
<var name="a" value="b"/>
<echo>${a}</echo> <!-- will print out b -->
<property name="a" value="c"/>
<echo>${a}</echo> <!-- property can't override, will print out b -->
There are a couple ofother constructs that I've written tasks for that
turn out to be very intuitive for Java developers to use:
try/catch/finally and if/else. One of the hardest parts I had in
learning about Ant was this:
<property name="doit" value="false"/>
<target name="dosomething" if="doit">
...
</target>
It is counter-intuitive to think that the "dosomething" target would
execute since "doit" is false. This is much more intuitive:
<property name="doit" value="false"/>
<target name="dosomething">
<if name="doit" value="true">
<!-- now do it -->
</if>
</target>
Anyway, I've rambled and ranted enough. The tasks I mentioned are
available at antelope.sourceforge.net. Just this morning I finished
<antcallback>, which is identical to <antcall> except it supports a
"return" parameter, so you can do something like this:
<target...>
<antcallback target="setAValue" return="a"/>
<echo>${a}</echo> <!-- will print out got it -->
</target>
<target name="setAValue">
<property name="a" value="got it"/>
</target>
I'll probably post this task on sourceforge tomorrow. There is already
an <antfetch> which does almost the same thing for <ant>.
Dale Anson
danson@germane-software.com
Erik Hatcher wrote:
> No, you cannot unset a property.
>
> Do you have a reasonable use-case that explains why you'd need such a
> thing? To date, I've yet to see a scenario that could not be
> accomplished some other (usually cleaner) way.
>
> Erik
>
> On Wednesday, February 5, 2003, at 10:31 AM, detlef.brendle@canoo.com
> wrote:
>
>> Hi,
>>
>>
>> is there a way to easily unset a property within a project ?
>>
>>
>>
>>
>> As with Ant1.5 the getProperties() returns a copy of the hashtable I
>> cannot
>>
>>
>> see a elegant way to do this.
>>
>>
>>
>>
>>
>>
>> any suggestions `?
>>
>>
>>
>>
>>
>>
>> thanks,
>>
>>
>> detlef
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: CORBA IDL uptodate checking
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Erik Putrycz" <er...@ieee.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, February 05, 2003 07:53
Subject: CORBA IDL uptodate checking
> I wrote an Ant task for the IDL compiler from OpenORB project.
> I would like to add an uptodate check for compiling only the necessary IDL
> files.
> I looked in the current sources and the main challenge stays in figuring
out
> the java files that will be generated out of an IDL file.
> I wonder if anyone has done that before ?
ahh, Axis's Wsdl2java has the same problem; you need to know too much about
what is going on before you can do dependencies. In the axis case I'm
debating integrating the dependency checking *into* the implementation code,
rather than just a task wrapper;
Re: CORBA IDL uptodate checking
Posted by Sebastien BLANC <Se...@alcatel.com>.
do u confirm wat u're trying to do is not re-generate the java files from the
idl if there was no modifs since the last cross compil ?
if so, here a previous answer I got on the same concern for xdoclet generated
files:
The first step is done using either <vailable> or <dependset>. The latter is
more generic, but doesn't set a property when doing something (deleting the
targets when it found they are out-of-date vs. the sources). The former set the
property you need, but supports only 1-to-1 (using a mapper) or many-to-1
relationship, and doesn't delete the out-of-date target files. If you go for
<dependset>, you need an additional <available> usually 2 find out a-posteriori
if it did something. If you do with <available>, you may need 2 delete the
target files.
The second step is done in a separate target executed conditionally based on
the target that check whether the target files are up-to-date or not, which
sets a property accordingly. All this needs 2 be wrapped in yet another target
that depends on the 2 previous one.
<target name="gen" depends="gen-needed?, do-gen" />
<target name="gen-needed?">
...
<!-- set property gen-targetfiles-up2date only when target files
are really up-todate. Do nothing if they're not.
-->
<property name="gen-targetfiles-up2date" value="whatever" />
</target>
<target name="do-gen"
unless="gen-targetfiles-up2date">
<xdoclet ... />
</target>
all targets are detailed in ANT doc.
seb.
Erik Putrycz wrote:
> Thanks for help !
>
> > u mean the name of the generated files or the location of the generated
> files ?
>
> I would like to have a way to know the name of the generated files from an
> idl file.
> So that I could use the Ant classes for uptodate checking.
>
> > if this is the name of the files u are wondering about, then it is ORB
> dependant
> > but why not launch ur test for **/** under generated ? otherwise for a
> fixed ORB
> > and depending of the CORBA standard level, the name of the files will
> always be
> > the same (since they are generated).
> >
> > does it help ?
>
> Is there any classes already there that does the uptodate check for **/** ?
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: CORBA IDL uptodate checking
Posted by Erik Putrycz <er...@ieee.org>.
Thanks for help !
> u mean the name of the generated files or the location of the generated
files ?
I would like to have a way to know the name of the generated files from an
idl file.
So that I could use the Ant classes for uptodate checking.
> if this is the name of the files u are wondering about, then it is ORB
dependant
> but why not launch ur test for **/** under generated ? otherwise for a
fixed ORB
> and depending of the CORBA standard level, the name of the files will
always be
> the same (since they are generated).
>
> does it help ?
Is there any classes already there that does the uptodate check for **/** ?
Erik.
Re: CORBA IDL uptodate checking
Posted by Sebastien BLANC <Se...@alcatel.com>.
Hi !
u mean the name of the generated files or the location of the generated files ?
wat I did on a previous project was to use the cross compiler option to generate
all java files derived from IDL to a common directory (like $top/generated). I
think all IDL c-compiler have the option (I've only worked on ORBaccus and
jacorb though but this is this is a standard option to be able to control the
output directory).
if this is the name of the files u are wondering about, then it is ORB dependant
but why not launch ur test for **/** under generated ? otherwise for a fixed ORB
and depending of the CORBA standard level, the name of the files will always be
the same (since they are generated).
does it help ?
seb.
Erik Putrycz wrote:
> I wrote an Ant task for the IDL compiler from OpenORB project.
> I would like to add an uptodate check for compiling only the necessary IDL
> files.
> I looked in the current sources and the main challenge stays in figuring out
> the java files that will be generated out of an IDL file.
> I wonder if anyone has done that before ?
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
CORBA IDL uptodate checking
Posted by Erik Putrycz <er...@ieee.org>.
I wrote an Ant task for the IDL compiler from OpenORB project.
I would like to add an uptodate check for compiling only the necessary IDL
files.
I looked in the current sources and the main challenge stays in figuring out
the java files that will be generated out of an IDL file.
I wonder if anyone has done that before ?
Erik.
Re: unset a property of a project.
Posted by Martin <mg...@hotmail.com>.
Detlef-
Have you looked at setting a property using <condition> or <available>?
The property can be set to true/false based on conditions or availability to
underlying resource..
-Martin
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, February 05, 2003 11:43 AM
Subject: Re: unset a property of a project.
> No, you cannot unset a property.
>
> Do you have a reasonable use-case that explains why you'd need such a
> thing? To date, I've yet to see a scenario that could not be
> accomplished some other (usually cleaner) way.
>
> Erik
>
> On Wednesday, February 5, 2003, at 10:31 AM, detlef.brendle@canoo.com
> wrote:
>
> > Hi,
> >
> >
> > is there a way to easily unset a property within a project ?
> >
> >
> >
> >
> > As with Ant1.5 the getProperties() returns a copy of the hashtable I
> > cannot
> >
> >
> > see a elegant way to do this.
> >
> >
> >
> >
> >
> >
> > any suggestions `?
> >
> >
> >
> >
> >
> >
> > thanks,
> >
> >
> > detlef
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: unset a property of a project.
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
No, you cannot unset a property.
Do you have a reasonable use-case that explains why you'd need such a
thing? To date, I've yet to see a scenario that could not be
accomplished some other (usually cleaner) way.
Erik
On Wednesday, February 5, 2003, at 10:31 AM, detlef.brendle@canoo.com
wrote:
> Hi,
>
>
> is there a way to easily unset a property within a project ?
>
>
>
>
> As with Ant1.5 the getProperties() returns a copy of the hashtable I
> cannot
>
>
> see a elegant way to do this.
>
>
>
>
>
>
> any suggestions `?
>
>
>
>
>
>
> thanks,
>
>
> detlef
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
>