Re: Maybe we should open up depends for all targets [again]
On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
How about:
target-inteface name=foo/
target name=bar implements=foo/
/me run and hides!
2009/12/12 Nicolas Lalevée nicolas.lale...@hibnet.org
On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne
ddevie...@gmail.com wrote:
On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin
xavier.ha...@gmail.com
wrote:
2009/12/10 Stefan Bodewig bode...@apache.org
and would do away with any notion of target composition people way
expect from the name target-*group*.
I also think the name target-group is confusing for something that
doesn't
provide any composition. [...] What do you think this:
target name=foo dependencies=open/
target name=bar join-depends=foo/
Like in a SQL join you mean? ;)
But I'm not good at finding names, so maybe I should just go back to
my
work :-)
Frankly I think the Maven terminology of a goal is appropriate
here.
The fact that a goal is implemented as a target that has no tasks is
an impl detail. I think it easier that a goal is a higher level
abstraction that the target, and that target can choose to
participate
into one and only one goal. Whether goals themselves should only
depend on goals might be a good idea. Goals would define the
abstract
interface to the build system and logic, and targets become its
implementation. As I wrote, a target can belong to only a single
goal,
but can depend on targets or goals, as long as the DAG is acyclic.
I think that abstract interface target and implementation target
seems
to fit very well into my use case I presented earlier. It was about a
build
script expecting some target implementation to be run before some
other;
expecting build-jar, build-flex to be run before ivy-install. And
then the abstract target is dist.
Then about the term goal, I don't find it self explaining, but if in
Maven there is the same exact notion, I am good with not spreading new
terms for the same ideas. On the other hand if there would be non
trivial
difference, we shouldn't choose goal. I cannot say thought, I don't
know
Maven enought.
I have found the interesting part in the Maven book [1]. So in Maven,
there are some defined lifecycles. A lifecycle defines a sequence of
phases. And there are goals that get attached to phases. It doesn't
seems there is a particular build graph, goals doesn't seem to declare any
particular dependencies. On the other hand the phases are ordered in the
lifecycle.
The end user usually launch phases ('install'), but he can also launch
goals ('jar:jar': if nothing have been explicitely build, then that jar
will be empty, no dependency on some 'compile').
So as far as I understand Ant targets could be then compared to maven
goals for their implementation part, and maven phases for their
dependencies among them. Target groups in the current implementation are
then just phases (and if I remember correctly I was named phases when they
were initially suggested).
Finally as targets already decribe the build graph, I see no real need to
add another element for that, further more knowing that I am not sure we
have a clear view of what it should actually be. And it might be confusing
for build writers how and when to use target groups rather than simple
targets. I think we should focus on the real feature which is needed here:
be able to _append/hook_ some nodes to an external build graph without
_modifying_ it. Then I would be quite pragmatic and suggest to just add
this feature to the actual Ant model, here the targets.
In EasyAnt there is already this notion of phase. But I see no real
conflict with not supporting target groups in Ant. EasyAnt could just
implement phases as targets, it would be just an implementation detail.
Nicolas
[1] http://www.sonatype.com/books/maven-book/reference/lifecycle.html
Nicolas
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
On Mon, 14 Dec 2009 13:19:55 +0100, Stefan Bodewig bode...@apache.org wrote: before we get carried away with naming discussions ... Currently I don't feel there is consensus of what we'd like to see with target-group (if anything at all). The options I see are * have some sort of composite of targets that other targets can add themselves to * have some special construct that has a depends list similar to target. targets can depend on such a construct and add themselves to the depends list (the current code base). * allow targets to add themselves to the depends lists of any other target As I explained in the other thread, I finally think this is the simpler solution. * allow targets to add themselves to the depends lists of targets that in some way mark themselves as being open for such extensions I tend to prefer to keep it open by default, but I won't make any veto against it. For instance I have not the experience described by Bruce about finding backwards chaining [being an] often (usually) surprising behaviour to the first time user, but once learned quickly becom[ing] second nature. Nicolas * no target-group like construct at all * something completely different? What is your preference? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: deep-if/deep-unless
Bruce Atherton wrote: I think that would be very confusing at this point. If most people in the ant community, especially committers, think that this idea breaks the philosophy of ant, then it should not be developed. Maybe this kind of needs will be better addressed using the new groovy front-end. What I have in mind is the use of ant to drive deployments. I think that although we state on the home page of ant that ant is a build tool, because all batch processes, such as cooking or chemistry or assembling a robot are also build processes in essence, ant can be used to drive any process which is a sequence of tasks. If the process is highly configurable, there can be several blocks of tasks which are optionally executed. For better or worse, Ant was designed from the beginning to build its dependencies through backwards chaining. It is often (usually) surprising behaviour to the first time user, but once learned quickly becomes second nature. Introducing a new construct that does the reverse seems likely only to cause massive confusion, especially one with such a similar name. What I propose does not set backward chaining in question. Another name could be found. Instead of using a different attribute name deep-if deep-unless one could use another element name such as block, target-block, ..., for instance block name=foo depends=bar if=someproperty/. The fact that often an init method is the lowest level dependency and sets many of the properties used in if and unless attributes higher in the dependency tree is, I think, a good way to introduce people to the Ant way of designing builds as lists of target dependencies. Besides, as Jesse points out, there is a very simple workaround. Using ant/ or antcall/ is not a perfect workaround. ant and antcall create an ant subcontext. Properties and references set by targets invoked through ant and antcall do not return to the calling context. also, targets which have already been executed when you reach ant/ can be executed a second time, and the targets which are executed during the ant/ invocation can be reexecuted later by the calling context. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
Dominique Devienne wrote: On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton br...@callenish.com wrote: Can anyone give a concrete example where there would be a problem treating a target-group as if it were a target? Can't. But my thinking is that we should ere on the conservative side when we introduce such a feature, and that it's easier to open it up later on to all targets with no BC issues, than closing it up because real world issues crop up, with BC issues. I really do believe that having target-group (or whatever the final name) purely abstract encourages better reusable build design by forcing to think in terms of the build's public API that provides clean hooks for reusable implementation-specific pieces to tack on. But as usual I seem to be in the minority and I certainly won't be casting any blocking votes on the matter. --DD I also prefer to keep the target-group as they currently are to keep them simple. This is mostly a gut's feeling. I am also interested to see soon a release of ant 1.8.0, so that the community can enjoy the hundreds of bug fixes and improvements which are contained in our current codebase. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
On Wed, 16 Dec 2009 08:51:27 -0600, Dominique Devienne ddevie...@gmail.com wrote: On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton br...@callenish.com wrote: Can anyone give a concrete example where there would be a problem treating a target-group as if it were a target? Can't. But my thinking is that we should ere on the conservative side when we introduce such a feature, and that it's easier to open it up later on to all targets with no BC issues, than closing it up because real world issues crop up, with BC issues. I really do believe that having target-group (or whatever the final name) purely abstract encourages better reusable build design by forcing to think in terms of the build's public API that provides clean hooks for reusable implementation-specific pieces to tack on. But as usual I seem to be in the minority and I certainly won't be casting any blocking votes on the matter. That's what I thought too, it would help defining what is public and part of the API, which is one of my worry while maintaining the build system I presented earlier. But targets are all public, properties are global too. So it seemed to me quite useless to try to restrict anything. Or perhaps we could say it is a first step towards enabling proper API specification in build scripts ? Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
2009/12/16 Nicolas Lalevée nicolas.lale...@hibnet.org: [...] But targets are all public Except for the tradition of having non-public targets' names start with a dash. So it seemed to me quite useless to try to restrict anything. Restrict? More like caution, that's all. Lets not open Pandora's box just yet on target dependencies, and provide a useful yet limited extensible target (target-group), along with all the fixes Antoine mentions. Lets see how it fairs in the wild and what users are claiming for to make it more useful. This allows to release sooner (1.7.1 is 18 months old), without rushing what is admittedly a more radical change to Ant's target dependency handling. Sorry to hijack your POLL thread Stefan ;) --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: deep-if/deep-unless
On Wed, Dec 16, 2009 at 9:32 AM, Antoine Levy Lambert anto...@gmx.de wrote: is a sequence of tasks. If the process is highly configurable, there can be several blocks of tasks which are optionally executed. Maybe a custom executor that blocks some targets would work for you? Depends how these properties that prevent a target from executing (including their dependencies) are set or computed, but from the command line you could say ant deploy /block:war to launch the deploy target, completely forcing the removal of the war target from the target dependency graph. I guess the issue with your proposed deep if/unless is when that condition is evaluated. IMHO, once the DAG has been resolved and targets start running, it's too late. If you decide to block from the command line, that's OK, because you in effect edit the script on the fly before it started, to remove a dependency occurring anywhere in the DAG, overriding the build author's intention on purpose. But once it's started, the effect of removing a dependency in the middle could reorder the build in such a way that it's now incompatible with the targets already executed so far, and this to me makes it brittle and undesirable. My $0.02. --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Accept Groovy-Front Donation
Hi a +1 from me Martijn Stefan Bodewig wrote: Hi, Nicolas wants to donate his ProjectHelper implementation that allows build files to be written in Groovy. It can be found attached to https://issues.apache.org/bugzilla/show_bug.cgi?id=48347 It would start life at Ant inside the sandbox. Since this is more than just a small patch, following the IP-Clearance process[1] which involves the incubator seems in order. I volunteer to see this through the Incubator process. But before I start doing this: do we want to accept the donation? Stefan [1] http://incubator.apache.org/ip-clearance/index.html http://incubator.apache.org/ip-clearance/ip-clearance-template.html - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Lexicon vs. grammar (was: [POLL] target-groups)
Dominique Devienne wrote: This allows to release sooner (1.7.1 is 18 months old), without rushing what is admittedly a more radical change to Ant's target dependency handling. Agreed. More broadly, I would like to deflate discussions of this kind a bit. How many users are really clamoring for what I would refer to as grammatical changes in Ant - interpretation of targets, property evaluation, and so on - and can also agree on what they want? Ant's grammar is awkward and often counterintuitive (IMHO), but with experience it is possible to write what you need to write. If you need more flexibility and clarity, you can use script, or one of the ever-growing number of Ant-based builder tools written in various JVM scripting languages. Changes to the existing grammar are relatively expensive in terms of design and implementation, and pose a high risk of regressions, yet still cannot match the generality of true scripting languages. In the meantime, the unique value of Ant does not lie in its grammar, but in its library of tasks, which have been tuned over the years to simplify access to a broad variety of Java development tools and other file-manipulation utilities. The reason so many alternative build tools expose Ant tasks as their primary vocabulary is that it would be impractical to offer anything as convenient and comprehensive starting from scratch. I think it is best to be very conservative about the grammar. Focus energy on making standard tasks reliable, fast, and flexible (in that order). - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
You've convinced me. Just because we can't think of a problem doesn't mean that one doesn't exist, and it is a little late in the day to start monkeying around if we want to get a new release out the door. So Stefan, as far as your poll is concerned, count me a +1 for the current code base. Dominique Devienne wrote: On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton br...@callenish.com wrote: Can anyone give a concrete example where there would be a problem treating a target-group as if it were a target? Can't. But my thinking is that we should ere on the conservative side when we introduce such a feature, and that it's easier to open it up later on to all targets with no BC issues, than closing it up because real world issues crop up, with BC issues. I really do believe that having target-group (or whatever the final name) purely abstract encourages better reusable build design by forcing to think in terms of the build's public API that provides clean hooks for reusable implementation-specific pieces to tack on. But as usual I seem to be in the minority and I certainly won't be casting any blocking votes on the matter. --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Maybe we should open up depends for all targets [again]
On 2009-12-16, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: In EasyAnt there is already this notion of phase. But I see no real conflict with not supporting target groups in Ant. EasyAnt could just implement phases as targets, it would be just an implementation detail. AFAIU EasyAnt uses a ProjectHelper of their own, so it is not really that affected by what we decide. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] target-groups
On 2009-12-16, Bruce Atherton br...@callenish.com wrote: Sorry if the previous thread was hijacked by naming issues, but I'm not sure I'm ready to vote in a poll yet. That's why it only is a poll and not a vote 8-) To be honest I was hoping to get away from the naming issue and to a discussion of the feature itself - looks as if I had been successfull. So far I don't feel that we are all on the same page and would feel uncomfortable going forward with the release process before we took the time to resolve the issue. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
