Martin, and others,
I've had a few queries as to what I mean by trying to do this, and what
I would use it for, so I thought it worthwhile to respond to the list.
Apologies in advance for the length of this mail.
To set the context: I have created a utility build file with a few
targets that are property driven, to perform common functions
(Specifically, to create streams and views in ClearCase... the work you
have to do to simulate a CVS export!). The trick is, these functions in
part determie behaviour by the *existence* of properties, not just their
value.
To bring this back to an example... let's say I have a (simplified)
target in my utility file called 'clearcase.export'. It takes a few
parameters, of particular note are the stream we are exporting, the
baseline (tag) for the version we want to export, and the folder we want
to export into. If the baseline property is set, then we will export
files with versions corresponding to that baseline. If the baseline
property is *not* set, then we will export the latest version of all
files.
Now, I would like to call this like:
<nant buildfile="clearcase.utility.xml" target="export"
inheritall="false">
<properties>
<property name="stream" value="${project.stream}" />
<property name="baseline" value="${stable.baseline}" />
<property name="destination" value="${project.src}" />
</properties>
</nant>
If, in the course of the build, you only need to export a single
project, then it is good enough to rely on command-line properties being
passed through regardless of inheritall... but you are also forcing the
user to pass all of these parameters on the command-line every time the
build is invoked. Even worse, it is now impossible to export two
different projects in one build!
Okay, then. A first-look simple fix is to include the utility build
file and use the <call> task, rather than the <nant> task.
Unfortunately, this also doesn't work. Because you can't unset a
property, it is now impossible to perform an export of the latest
version of a project *after* performing an export at a baseline (The
baseline property has been set for the first export, and can't be unset
to say 'get the latest version') We could of course fix this by
introducing a new property 'useheadversion' (or similar) which is always
set true or false and overrides the baseline property, but that's
modifying the interface because of issues in the implementation, which
is rarely a good idea.
The most intuitive (and "correct"?) interface was the original, and
luckily a bugfix since the latest release has enabled this to work as
expected, so this all becomes (part of the) justification to my
higher-ups for using the latest nightly version of NAnt instead of 0.84,
and I get to clean up my build files with functions instead of tests as
a side-effect :-) The design stays clean, and everyone's hapy.
I hope this clears things up!
I hope you're all well,
-- Troy
________________________________
From: Martin Gainty [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 16 June 2004 8:14 PM
To: Troy Laurin; [EMAIL PROTECTED]
Subject: Re: [Nant-users] Scoping issues with <nant> task,
passing properties with inheritall="false"
Troy
How would your nant project Inherit a subset of properties from
parent project?
Are you proposing access modifiers for properties of the parent?
Right now you get all (inheritall="true") or nothing
(inheritall="false") with the exception of user properties passed in
here is the relevant text from ANT
Alternatively, you can set the inheritAll attribute to false and
only "user" properties (i.e., those passed on the command-line) will be
passed to the new project. In either case, the set of properties passed
to the new project will override the properties that are set in the new
project
Please explain the property inheritance that you are speaking of
-Martin
Disclaimer Message:
This message contains confidential information and is intended only for the
individual(s) named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please immediately delete it and all copies of it from
your system, destroy any hard copies of it, and notify the sender. E-mail transmission
cannot be guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the
maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept
liability for any errors or omissions in the contents of this message which arise as a
result of e-mail transmission.
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
