ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 53550] New: [PATCH] extensionOf settings applied when task is discarded because of previous declaration
Date Sat, 14 Jul 2012 10:22:33 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=53550

          Priority: P2
            Bug ID: 53550
          Assignee: notifications@ant.apache.org
           Summary: [PATCH] extensionOf settings applied when task is
                    discarded because of previous declaration
          Severity: normal
    Classification: Unclassified
                OS: Mac OS X 10.4
          Reporter: tpokorny@gmail.com
          Hardware: PC
            Status: NEW
           Version: unspecified
         Component: Core
           Product: Ant

Created attachment 29061
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29061&action=edit
master build file that replicates the problem when invoking the compile target

OK, bare with me, it took a couple of attempts to try and write this so it
comes out correct :P

=== Brief ===
When an imported file contains a target that has the same name as an existing
target from the importing build file, the extensionOf="" settings on the target
are applied even though the target is ignored. The result is that Ant complains
that the target has a circular dependency:

BUILD FAILED
Circular dependency: compile <- all.compile <- compile

Two build files (master and module) are attached that reproduce this problem.

=== Full Story ===
I have a master build file that has a bunch of high-level targets (clean,
compile, release, etc...). I also have a number of "module" build files that
contain targets of the same name. In the master, these are imported (not
included) with a prefix to ensure the targets don't double up.

So in the master, I have a target declared as below, where "all.compile" is an
extension point that also resides in the master:

<target name="compile" depends="all.compile"/>

In the module build file I have a target declared like this:

<target name="compile" extensionOf="all.compile">

The intention is that calling compile on the master will cause all the module
compiles to run. Doing this results in the build failing with a circular
dependency as per the error in the brief description. Running "ant -v" shows
that when importing like this, ant will actually try and create two targets,
one with the prefix as defined in the import statement, and the other without.
The target without the prefix clashes with the one from the master, and results
in the following output:

"Already defined in main or a previous import, ignore compile"

That all makes sense and seems logical. The target is imported under the
prefixed name anyway, so life is all good. However, it seems that even though
the non-prefixed target is ignored, the "extensionOf" settings from the module
are still being applied. 

I checked out the latest trunk from SVN and it looks (in ProjectHelper2) as if
the check to see if there is a target name clash results in the target not
being added to the context and thus ignored. However, failing that check does
not stop the code at that point, and it proceeds on further. When it comes to
extensionOf processing, there is not a similar check to see if the target was
ignored, so the values of the attribute are applied, only they get attached by
the target name, thus linking them to the target from the MASTER file.

Apologies, it's a bit difficult to explain concisely in text.

To me, it seems like there are two options to solve this (patch for one
attached):
  1. If the target is found to clash, stop processing it at that point
  2. Further down, when the extensionOf attribute is processed, skip it if the
target was meant to be discarded.

I have attached a patch for the second option, as I wasn't sure if the decision
not to end processing when finding a clash was deliberate or not and would have
other flow on effects.

Cheers,
Tim

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

Mime
View raw message