2009/12/16 Dominique Devienne
>
>ant deploy /block:war
>
>
Sounds very cool !
I often tried to implement such things into my ant script, but I never found
the right ideom to do that. But this gave me an idea I might give a try :
...
...
Hello Stefan,
Stefan Bodewig wrote:
> On 2009-12-16, Antoine Levy Lambert wrote:
>
>
>> 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 phil
On 2009-12-16, Antoine Levy Lambert wrote:
> 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.
It may be confusing to
On Wed, Dec 16, 2009 at 9:32 AM, Antoine Levy Lambert 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 tha
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
I think that would be very confusing at this point. 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
Stefan Bodewig wrote:
On 2009-12-14, Antoine Levy Lambert wrote:
I have never thought about how this could be implemented and how much
work it is. It is probably a non-trivial addition because it means
that the list of targets to execute and their order will change
dynamically during the bu
On 2009-12-14, Antoine Levy Lambert wrote:
> I have never thought about how this could be implemented and how much
> work it is. It is probably a non-trivial addition because it means
> that the list of targets to execute and their order will change
> dynamically during the build depending upon h
Antoine Levy Lambert wrote:
When executing foo, bar will get executed regardless of whether
someproperty is set or not.
I would often see the need for another variation of if, which would
remove bar from the dependency tree if someproperty is not set.
--
