You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2014/04/01 21:33:35 UTC

[Bug 56337] New: Extension point target rewriting

https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

            Bug ID: 56337
           Summary: Extension point target rewriting
           Product: Ant
           Version: 1.9.3
          Hardware: PC
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Core
          Assignee: notifications@ant.apache.org
          Reporter: rich@steelezone.net

Created attachment 31464
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31464&action=edit
Sample build scripts

I have two build files, the main one called build.xml:

<project name="build">
    <import file="hello.xml" />
    <target name="hi">
        <echo message="Hello" />
    </target>
</project>

and hello.xml that it imports:

<project name="hello">
    <extension-point name="greeting" />
    <target name="hi" extensionOf="greeting">
        <echo message="Hi!!!" />
    </target>
</project>

With Ant 1.8.4 when I run the "greeting" target I get:

λ ant greeting
Buildfile: C:\Development\projects\ant-playground\override-target\build.xml

hi:
     [echo] Hello

greeting:

BUILD SUCCESSFUL
Total time: 0 seconds

However, with Ant 1.9.3 I get:

λ ant greeting
Buildfile: C:\Development\projects\ant-playground\override-target\build.xml

hello.hi:
     [echo] Hi!!!

greeting:

BUILD SUCCESSFUL

This change in behavior is obviously wrecking havoc with our build scripts that
depend on some amount of target overriding.  Is the new behavior considered the
correct way and, if so, is there a way to revert back to the old behavior?

I suspect this is related to bug 54940.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

Antoine Levy-Lambert <an...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #6 from Antoine Levy-Lambert <an...@apache.org> ---
marking as resolved.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

--- Comment #1 from Antoine Levy-Lambert <an...@apache.org> ---
A bug 53405 "ExtensionPoint doesn't work with nested import/include" was fixed
between 1.8.4 and 1.9.0. That's likely the reason for the change of behavior.

In your sample, the target hi in the main build file does not have the
attribute extensionOf="greeting". hi in the main build file overrides hi in the
imported build file but does not override the extension point greeting. 

I feel that the behavior of Ant 1.9.3 is correct.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

--- Comment #2 from Jean-Louis Boudart <jl...@apache.org> ---
I agree with Antoine current behavior is the expected one.
I guess, you found an expected side effect of 1.8.4 implementation :). There is
no kind of inheritance here. 

I think it would be really dangerous when overriding a target to be attached to
an extensionPoint you haven't declared by yourself.

If you add the extensionOf on the specific "hi" target like :
<project name="build">
    <import file="hello.xml" />
    <target name="hi" extensionOf="greeting">
        <echo message="Hello" />
    </target>
</project>

You would then results both "hi" targets injected in greeting extension-point.
I think this is not what you expect.

It's difficult to understand your use case but you probably "misused"
extensionpoint. Wiring target to an extension point in your generic build file
and then override this target in specifics build.xml seems not optimal.

I would then recommend you to keep to not wire your target to extension point
in your generic build file and give this job to specific build file with either
:
 * a target like this <target name="specific" extensionOf="myExtensionPoint"/>
 * or using bind target task (see
https://ant.apache.org/manual/Tasks/bindtargets.html).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

--- Comment #3 from rich@steelezone.net ---
My use case:

Imagine a java.xml that, among many other things, hooks into a compile
extension point:

<project name="java">
        <import file="compile.xml" />
    <target name="java:compile" extensionOf="compile">
        <javac ... />
    </target>
        .
        .
        .
</project>

from compile.xml:

<project name="compile">
    <extension-point name="compile" />
</project>

Most projects would find using the default implementation of the java:compile
target provided by the compile extension point, but sometimes we'd like to
override its behavior:

<project name="build">
    <import file="java.xml" />
    <target name="java:compile">
        <javac ... />
    </target>
</project>

This is usually needed when the default implementation doesn't do what is
needed by this particular build and the generic scripts aren't quite flexible
enough.

While I do see the logic of the change: while I overrode the target--calling
the java:compile target directly does work--the extension point is preserving
its dependencies like regular dependencies do, I'm a little stuck.  Without the
override, how would I allow a build script author to do what they need without
resorting to copying and pasting the entirety of the original java.xml?  (It
does more than just compile: javadoc, zipping up the source, etc.)  I'm failing
to see how <bindtargets> helps in this case...unless I ditched using
extensionOf entirely, using <bindtargets> with unless:true attributes and a
while bunch of properties for each?  That seems complicated and error prone.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

--- Comment #4 from Antoine Levy-Lambert <an...@apache.org> ---
I understand that you want to tie a target to an extension point and also have
the possibility to override a default implementation

does the below solve your problem ?

<project name="build">


    <import file="hello.xml" />

    <target name="hi-impl">
        <echo message="Hello" />
    </target>

</project>

<project name="hello">

    <extension-point name="greeting" />
    <target name="hi" extensionOf="greeting" depends="hi-impl">
    </target>
        <target name="hi-impl">
        <echo message="Hi!!!" />
        </target>

</project>

the output is this :

bash-3.2$ ant greeting
Buildfile: /Users/antoine/dev/asf/56337/build.xml

hi-impl:
     [echo] Hello

hi:

greeting:

BUILD SUCCESSFUL
Total time: 0 seconds

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

ht <ht...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |htaneja@gmail.com
                 OS|                            |All

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56337] Extension point target rewriting

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56337

--- Comment #5 from rich@steelezone.net ---
Yes it does even though it takes more forethought to implement.  That might be
a good thing because I can establish a naming pattern for those targets that
are intended to be overridden, rather than having the current "anything goes"
mechanism today.

Thanks for taking the time to look into this.

-- 
You are receiving this mail because:
You are the assignee for the bug.