You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2003/09/17 12:02:16 UTC
Should cause an error when used inside a ?
or at least a warning?
If you nest <import> into a target, it won't be evaluated at parser
time (or will it?) and thus not work as expected - even if the
resulting build file was valid (i.e. the imported file doesn't contain
targets).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
On Wed, 17 Sep 2003 09:17 pm, Stefan Bodewig wrote:
>
> OK, if I nest <import> into a target, something like
>
> <target name="define-paths" depends="detect-platform">
> <import file="${platform.specific.paths}"/>
> </target>
>
I'm not keen on <import>s within targets. The use-case seems too narrow to me
and it seems to confuse the target and top level scopes (which are sort of
confused anyway because we don't have target-scope properties - but that is a
separate issue)
I think we should check for this and explicitly disallow this behaviour.
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 18 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> So will we allow <import> inside a <target>?
If it was a pure include, I'd say yes. If we don't allow it, <import>
can't replace entity includes completely.
Given the side effect of target overriding, I'm not sure. At least we
have to ensure that the imported file doesn't contain targets at all,
if it lives inside a target.
+0.75 to <import> inside <target>.
If we were to split <import> into multiple tasks and there was a pure
<include>, I'd be +1 ... (no, I won't beat that dead horse again 8-).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by peter reilly <pe...@corvil.com>.
On Thursday 18 September 2003 10:03, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > This implementation does handle your use-case (I think)
>
> The unit tests I've just committed confirm that. ;-)
So will we allow <import> inside a <target>?
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> This implementation does handle your use-case (I think)
The unit tests I've just committed confirm that. ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: Should cause an error when used inside a ?
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Sounds good,
Antoine
-----Ursprüngliche Nachricht-----
Von: peter reilly [mailto:peter.reilly@corvil.com]
Gesendet: Mittwoch, 17. September 2003 16:21
An: Ant Developers List
Betreff: Re: Should <import> cause an error when used inside a <target>?
On Wednesday 17 September 2003 13:24, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > I think that the use-case is valid.
>
> Hmm, maybe - given the timing of Antoine's release plan - we should
> limit <import> to top-level right now and revisit nesteing import into
> targets later?
The original implementation was a bit hachy (modifing the vector
of tasks in target while reading it). I have made a new
implementation that makes a new target for top level tasks
of imported files and executes them in the same way as normal
top level tasks.
This implementation does handle your use-case (I think) and
sequential.
<parallel> may be a problem - need to think about protecting
access to the antcontext object in PH2.
Peter
>
> > One should also think about an <import> inside a sequential.
>
> Aaargh. <import> inside <parallel> will be even more fun.
>
> Stefan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 13:24, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > I think that the use-case is valid.
>
> Hmm, maybe - given the timing of Antoine's release plan - we should
> limit <import> to top-level right now and revisit nesteing import into
> targets later?
The original implementation was a bit hachy (modifing the vector
of tasks in target while reading it). I have made a new
implementation that makes a new target for top level tasks
of imported files and executes them in the same way as normal
top level tasks.
This implementation does handle your use-case (I think) and
sequential.
<parallel> may be a problem - need to think about protecting
access to the antcontext object in PH2.
Peter
>
> > One should also think about an <import> inside a sequential.
>
> Aaargh. <import> inside <parallel> will be even more fun.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> I think that the use-case is valid.
Hmm, maybe - given the timing of Antoine's release plan - we should
limit <import> to top-level right now and revisit nesteing import into
targets later?
> One should also think about an <import> inside a sequential.
Aaargh. <import> inside <parallel> will be even more fun.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 13:06, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote:
> >> OK, if I nest <import> into a target, something like
> >>
> >> <target name="define-paths" depends="detect-platform">
> >> <import file="${platform.specific.paths}"/>
> >> </target>
> >>
> >> and this would import a file that had only <path> definitions - the
> >> definitions are platform specific - will it work as expected?
> >
> > using <import> within a target does not work as the code
> > that was placed in to handle top-level tasks/types does
> > not work in this case (it assumes the pre-condition).
>
> OK, this is an issue with the current implementation.
>
> Shall we make this ("Thou Shalt Not Use <import> Inside <target>s") a
> rule for <import> in general and enforce it? Or is my use-case above
> a valid one and we change the implementation to deal with it?
>
> Note that I'm not sure how I'd answer that myself. 8-)
I think that the use-case is valid.
One should also think about an <import> inside a sequential.
The implementation I used to handle top-level tasks most likely needs to
be changed.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote:
>> OK, if I nest <import> into a target, something like
>>
>> <target name="define-paths" depends="detect-platform">
>> <import file="${platform.specific.paths}"/>
>> </target>
>>
>> and this would import a file that had only <path> definitions - the
>> definitions are platform specific - will it work as expected?
> using <import> within a target does not work as the code
> that was placed in to handle top-level tasks/types does
> not work in this case (it assumes the pre-condition).
OK, this is an issue with the current implementation.
Shall we make this ("Thou Shalt Not Use <import> Inside <target>s") a
rule for <import> in general and enforce it? Or is my use-case above
a valid one and we change the implementation to deal with it?
Note that I'm not sure how I'd answer that myself. 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > The javadoc on the import task says that <import> should only
> > be used at the top-level.
>
> OK.
>
> > This statement is not in the manual.
>
> Let's fix it ;-)
Yes...
>
> > The code does not check the precondition.
>
> Maybe it should?
Yes - see below.
>
> > so it could be said that the top-level tasks (including import) do
> > not get evaluated at parser time.
>
> OK, if I nest <import> into a target, something like
>
> <target name="define-paths" depends="detect-platform">
> <import file="${platform.specific.paths}"/>
> </target>
>
> and this would import a file that had only <path> definitions - the
> definitions are platform specific - will it work as expected?
>
> With "expected" I mean it would include the <path> defitions for my
> platform (based on a property set by a task in target
> detect-platform). And certainly make those <path>s usable for
> subsequent targets.
using <import> within a target does not work as the code
that was placed in to handle top-level tasks/types does
not work in this case (it assumes the pre-condition).
(This is revision 1.21 of ProjectHelper2).
We get a crash and burn ;-)
build.xml
<project name="test">
<target name="use2">
<import file="echo.xml"/>
</target>
</project>
echo.xml
<project>
<echo>Hello world</echo>
</project>
ant use2
BUILD FAILED
java.lang.IndexOutOfBoundsException: Index: 8, Size: 7
at java.util.ArrayList.addAll(ArrayList.java:460)
at org.apache.tools.ant.Target.endImportedTasks(Target.java:201)
at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:159)
at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:188)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:309)
at org.apache.tools.ant.Task.perform(Task.java:401)
at org.apache.tools.ant.Target.execute(Target.java:363)
at org.apache.tools.ant.Target.performTasks(Target.java:390)
at org.apache.tools.ant.Project.executeTarget(Project.java:1237)
at org.apache.tools.ant.Project.executeTargets(Project.java:1094)
at org.apache.tools.ant.Main.runBuild(Main.java:667)
at org.apache.tools.ant.Main.startAnt(Main.java:220)
at org.apache.tools.ant.Main.start(Main.java:184)
at org.apache.tools.ant.Main.main(Main.java:267)
Peter.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> The javadoc on the import task says that <import> should only
> be used at the top-level.
OK.
> This statement is not in the manual.
Let's fix it ;-)
> The code does not check the precondition.
Maybe it should?
> so it could be said that the top-level tasks (including import) do
> not get evaluated at parser time.
OK, if I nest <import> into a target, something like
<target name="define-paths" depends="detect-platform">
<import file="${platform.specific.paths}"/>
</target>
and this would import a file that had only <path> definitions - the
definitions are platform specific - will it work as expected?
With "expected" I mean it would include the <path> defitions for my
platform (based on a property set by a task in target
detect-platform). And certainly make those <path>s usable for
subsequent targets.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Should cause an error when used inside a ?
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 11:02, Stefan Bodewig wrote:
> or at least a warning?
>
> If you nest <import> into a target, it won't be evaluated at parser
> time (or will it?) and thus not work as expected - even if the
> resulting build file was valid (i.e. the imported file doesn't contain
> targets).
The javadoc on the import task says that <import> should only
be used at the top-level.
This statement is not in the manual.
The code does not check the precondition.
The toplevel tasks get executed in PH2#parse(Project project, Object source)
but only after the full source/file has been parsed in
PH2#parse(Project project, Object source, RootHandler handler),
so it could be said that the top-level tasks (including import)
do not get evaluated at parser time.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org