Bug 22901 - [Patch] -only option to execute target(s) without dependencies
Summary: [Patch] -only option to execute target(s) without dependencies
Status: REOPENED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2003-09-02 22:25 UTC by Alexey Solofnenko
Modified: 2009-07-31 03:22 UTC (History)
0 users



Attachments
patch file (7.18 KB, patch)
2003-09-02 22:26 UTC, Alexey Solofnenko
Details | Diff
proposed patch (6.02 KB, patch)
2005-01-06 05:47 UTC, Alexey Solofnenko
Details | Diff
OnlyExecutor.java (1.42 KB, text/plain)
2005-01-06 05:48 UTC, Alexey Solofnenko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Solofnenko 2003-09-02 22:25:34 UTC
The patch adds '-only' option to be able to execute target(s) without their dependencies.
Comment 1 Alexey Solofnenko 2003-09-02 22:26:11 UTC
Created attachment 8043 [details]
patch file
Comment 2 Matt Benson 2004-11-19 18:29:36 UTC
Solution:  implement org.apache.tools.ant.Executor:

    public void executeTargets(Project project, String[] targetNames)
        throws BuildException {
        Hashtable targets = project.getTargets();
        for (int i = 0; i < targetNames.length; i++) {
            ((Target)(targets.get(targetNames[i])).performTasks();
        }
    }
Comment 3 Alexey Solofnenko 2005-01-03 10:21:09 UTC
While trying to port old feature into new ANT I found that one cannot set "only" executor during ANT startup - 
"only" executor cannot be inherited, because inner <ant>, <antcall>, and Co 
should work with full dependencies execution. This still requires a special mode
of execution. The patch is obsolete, but I can produce a new one.
Comment 4 Matt Benson 2005-01-03 17:24:08 UTC
The Ant task and its derivatives use the SingleCheckExecutor for simplicity's
sake because it gives all the behavior they need.  Adding the ability to specify
a particular Executor would not be that difficult but it doesn't seem like much
more than clutter, really.  In this particular instance, it strikes me as odd
that you want/need to execute a target without its dependencies.  If so, why do
you have the dependencies?  Ordinarily you declare dependencies and the tasks
decide whether they have any work to do, so that your build incurs as little
work as possible.  If you have two tasks and sometimes you want to execute one
based on the other you could impose that structure with helper targets.  It
sounds as though restructuring your buildfiles could be immensely helpful.
Comment 5 Alexey Solofnenko 2005-01-03 18:34:50 UTC
Executors should be inherited from the parent ANT by default. If one wants
to use a parallel executor, subants should use it too. Plus they should use
the same executor instance to have a single thread pool to enforce thread number
limitation across all subants.
Comment 6 Matt Benson 2005-01-03 19:13:44 UTC
Interesting argument.  I will have a look at that.
Comment 7 Matt Benson 2005-01-03 19:32:56 UTC
A big problem here, again, is the fact the sensible way to process multiple
targets specified via nested elements on a single ant(call) invocation is with
single-check execution; otherwise multiple tasks could be used.  Ordinarily,
then, you have default target execution for the main Project and single-check
execution for ant(call)-based Project instances.  The parallel case and its
threadcount limitations is a good one; executor inheritance would definitely be
useful here, but we end up with this conflict.  At this point the only
compromise I see is to inherit the executor, with the rule being that nested
targets will cause a single-check executor to be used in place of a default
executor; or a new keep-going/single-check executor to be used in place of a
keep-going executor; but no other combination of circumstances will result in
such a substitution.
Comment 8 Alexey Solofnenko 2005-01-04 05:42:38 UTC
I think something like

Executor getChildExecutor()

will solve this problem.
Comment 9 Alexey Solofnenko 2005-01-06 05:47:21 UTC
Created attachment 13904 [details]
proposed patch
Comment 10 Alexey Solofnenko 2005-01-06 05:48:57 UTC
Created attachment 13905 [details]
OnlyExecutor.java
Comment 11 Alexey Solofnenko 2005-01-06 05:49:36 UTC
This is the patch that uses Executor.getChildExecutor() method.
Comment 12 Matt Benson 2005-03-08 23:53:44 UTC
Hmm.. I didn't see where you were going with the childExecutor before, but I
just looked at this again and I don't hate it.  After 1.6.3 comes out I don't
want to alter the Executor interface unless I have to so I will be thinking
about this.

Maybe when (if) we start doing Ant libraries there could be an executor library;
otherwise I don't necessarily want to get into adding a million of them to core.
 But would OnlyExecutor not want to return itself as a child?  If I add the
child I will probably do an AbstractExecutor with a default getChildExecutor()
{return this;} and make all existing Executors inherit from that.  Then I'd
probably add an executor attribute to the Ant task as well.
Comment 13 Alexey Solofnenko 2005-03-09 00:54:40 UTC
I would expect inner <ant>s to be executed fully, only the first level targets should be executed without dependencies.