On 2008-11-13, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> Conceptually I agree with you, but I think we need to recognize why
> people would want this and to validate their concerns.
I wasn't advocating we change the current behavior, Ant's own build
file relies on it in much the same way as
>
Here is some additional information on EasyAnt phase concept
http://easyant.abrm.info/trac/wiki/tasks/phase
On Thu, Nov 13, 2008 at 1:44 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> A second level (maybe I go too far) might be to put it deeper up to
> the event notification. A build that use phase might have
> phaseStarted and phaseFinished event sent around targetStarted and
> targetFinished.
Makes
I'm +1 to put the concept in Ant's core, marked as experimental.
A question that I have is how deep we want to push this concept?
A first level would be that a phase or a target-group is a "normal"
tartget for which the depends is build based on the other target that
are found. (with that view, I
On Thu, Nov 13, 2008 at 1:08 PM, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> Conceptually I agree with you, but I think we need to recognize why people
> would want this and to validate their concerns.
>
> Consider these targets:
>
> ...
> ...
>
> Whether or not "clean" is a dependency of "compil
2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]>:
> On 2008-11-12, Remie Bolte <[EMAIL PROTECTED]> wrote:
>
>> Thanks for the explanation, it indeed seems to be a nice feature, however my
>> first concern would be the order of execution.
>
> If you need a specific order of execution, you should ensure
Conceptually I agree with you, but I think we need to recognize why
people would want this and to validate their concerns.
Consider these targets:
...
...
Whether or not "clean" is a dependency of "compile" depends on the
context "compile" is executed in. Now, it is possible to work around
Swich done, everything works perfectly
I like how you've documented it :)
I've updated the patch (now it contains only phases features)
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713748-easyant-patch.diff
Thanks again for this integration
2008/11/13 Stefan Bodewig <[EMAIL
>> should help your caae. It isn's a complete fix since the prefix for
>> included files without "as" doesn't get set before the first target
>> (if any) is encountered.
The "complete fix" should be revision 713745.
Stefan
-
T
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 2008-11-11, Matt Benson <[EMAIL PROTECTED]>
> wrote:
>
> > Personally I would prefer supporting arbitrary
> > attributes on targets.
>
> That would be easy to do.
>
> > This would be less specific to EasyAnt and could
> have mileage for
> > ot
> >> by typing ant -p i can see
> >> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
> i
> >> like to compile java classes :)
> >> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> > This is what I get with Ant trunk:
>
> > $ ./build.sh -f ../../Temp/u.xml -p
>
On 2008-11-13, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
>> I'll try to give you details
> [snip - removed > by typing ant -p i can see
>> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
>> like to compile j
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> Here it is i'm ing a file that has no explicit "as" prefix.
> So calling to (prefix = getTargetPrefix(context)) will return the imported
> project's name.
For the file's targets and only as an additional name, they
should have been a
> > It seems to be related to this test
> > if (!isInIncludeMode && context.isIgnoringProjectTag()
>
> means ProjectHelper is currently ing a file
>
> > && (prefix = getTargetPrefix(context)) != null
>
> and there is a prefix defined for the imported file (either an
> explicit "as"
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> Refering to the comment
> // In an imported file (and not completely ignoring the project tag
> *OR*having a preconfigured prefix)
> this test should be like this instead
> if (!isInIncludeMode && !isPhase && (context.isIgnoringProject
Refering to the comment
// In an imported file (and not completely ignoring the project tag
*OR*having a preconfigured prefix)
this test should be like this instead
if (!isInIncludeMode && !isPhase && (context.isIgnoringProjectTag()
|| (prefix = getTargetPrefix(context)) != null)) {
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> It seems to be related to this test
> if (!isInIncludeMode && context.isIgnoringProjectTag()
means ProjectHelper is currently ing a file
> && (prefix = getTargetPrefix(context)) != null
and there is a prefix defined
It seems to be related to this test
if (!isInIncludeMode && context.isIgnoringProjectTag()
&& (prefix = getTargetPrefix(context)) != null && !isPhase)
{
But i don't understand why yet :(
Any idea?
2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]>
> On 2008-11-13, Jean-Louis BOUDART
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> I'll try to give you details
[snip - removed by typing ant -p i can see
> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
> like to compile java classes :)
> org.apache.easyant#build-std-java.myPrefix.plop -
19 matches
Mail list logo
