Ant properties defined in antcall

In current (Pallada) ant implmentation we have a problem. Ant file:
]]>
<echo message="$/>
]]>

The problem: Target 'aTarget' refers to property named 'a' this property
isn't set in build file or Build File Properties dialog, it is set just
before calling 'aTarget' via antcall. In current implementation (not in
Aurora) usage of this property is mark with red - if someone asks ant to run
'aTarget' the 'a' property isn't defined. Property completion won't suggest
'a' for same reason.

Any ideas how IDEA should behave in such cases.

--

Dmitry Peshehonov
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



7 comments
Comment actions Permalink

Tricky one. Maybe there's nothing that IDEA can do about it, and you should just make it configurable if this situation should be marked as an error, a warning or not be marked at all (like the 'Errors' dialog).

0
Comment actions Permalink

It seems to me that if that target is only called when a is set, there's no problem. Oterwise, if there is a case where it's called when a is not set, a warning or error should be given (highlight in yellow or red).

0
Comment actions Permalink

Not covered issue is that the target may be called from command line.
I'd say the target configuration in IDEA should be the driving
information - hidden targets to be assumed NOT to be called from
outside.

r.

Keith Lea wrote:

It seems to me that if that target is only called when a is set, there's no
problem. Oterwise, if there is a case where it's called when a is not set, a
warning or error should be given (highlight in yellow or red).

0
Comment actions Permalink

Why is this any different from the case where properties are defined inside tasks, which may or may not be run before the property in question is being used in another task. The present implementation won't flag an error on such, nor should it for the temporary pseudo-properties defined by antcall. One could imagine an Ant "inspection" that flags properties or params which may be used before defined, but right now you don't have anything like that, and I'm not sure how much value it would be.

Bottom line: treat params as properties, ignoring scoping and lifetime issues. You'll still have the most powerful Ant integration in existence, and while the solution won't be perfect it will be less annoying than the alternative.

--Dave "real build scripts don't use antcall anyway" Griffith

0
Comment actions Permalink

Hello!

I think that target, who can recieve parameters must "declare" it. Becouse, user can see that task have parameters, and IDEA can easy handle this.

For example:
]]>
<echo message="$/> </target> <target name="other"> <antcall target="aTarget"> <param name="a" value="..."/> </antcall> </target> Now, IDEA know that "target" have input parameter a and handle it as defined property in scope of target. After definition paramets in "antcall" IDEA can also easy get list of parameters for calling target (and also get warning, if someone missed). <!-- @param a Message --> <target name="aTarget"> <echo message="$/>
| ]]>
CtrlShiftSpace - Then IDEA show chooser popup:
Define param: a
Hit Enter:

]]>

Thanks!

0
Comment actions Permalink

Totally agree with Dave.


"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:13520642.1079972506761.JavaMail.itn@is.intellij.net...

Why is this any different from the case where properties are defined

inside tasks, which may or may not be run before the property in question is
being used in another task. The present implementation won't flag an error
on such, nor should it for the temporary pseudo-properties defined by
antcall. One could imagine an Ant "inspection" that flags properties or
params which may be used before defined, but right now you don't have
anything like that, and I'm not sure how much value it would be.
>

Bottom line: treat params as properties, ignoring scoping and lifetime

issues. You'll still have the most powerful Ant integration in existence,
and while the solution won't be perfect it will be less annoying than the
alternative.
>

--Dave "real build scripts don't use antcall anyway" Griffith

>


0
Comment actions Permalink

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:13520642.1079972506761.JavaMail.itn@is.intellij.net...

Why is this any different from the case where properties are defined

inside tasks, which may or may not be run before the property in question is
being used in another task. The present implementation won't flag an error
on such, nor should it for the temporary pseudo-properties defined by
antcall. One could imagine an Ant "inspection" that flags properties or
params which may be used before defined, but right now you don't have
anything like that, and I'm not sure how much value it would be.

Right now (in Pallada) we do have "scope". It becomes important to support
presetdef and macrodef - they are like properties defined in build files but
unlike properties they have attributes and inner tags so we have to choose
right definition to complete or check.

Personally I like "a la javadoc" idea suggested by Alexey Efimov. It isn't
easy (for internal reasons) to show warning in antcall but easy to add
intention "Add param" and search for property definition in comments.

>

Bottom line: treat params as properties, ignoring scoping and lifetime

issues. You'll still have the most powerful Ant integration in existence,
and while the solution won't be perfect it will be less annoying than the
alternative.
>

--Dave "real build scripts don't use antcall anyway" Griffith

>


--

Dmitry Peshehonov
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



0

Please sign in to leave a comment.