On Mon, 7 Apr 2008, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> Antlets
>> =======
>>
>> I like the idea. We should probably add ~/.ant/antlets to the
>> search path as well.
>>
>> What is the reason you put each module into a separate directory?
>> Couldn't we get away with a single build file per Antlet as well?
>
> I thought it might be useful if an antlet wants to have properties,
> or even a custom task defined with a taskdef. A directory per antlet
> makes this cleaner IMO.
Looking through your example modules I see how this might be useful, I
agree now.
>> Extends and Use
>> ===============
>>
>> I'm not sure I fully grasp the difference. Currently we prefix
>> target names as well, just in addition, don't we?
>
> Yes, but this is not enough. Imagine you have two files like this:
> moduleA.xml:
> <target name="init" />
> <target name="run" depends="init" />
>
> moduleB.xml:
> <target name="init" />
> <target name="test" depends="init" />
>
> Then if you import both, and execute the "test" target, you can't be
> sure the init target of the same build file will be executed. It
> depends on the order in which the files are included.
in moduleB.xml you'd rather say <target name="test" depends="moduleB:init"/>
should work with import today.
>> I must admit that I don't like the explicit ":" used in your
>> examples to create a prefix delimiter. I'd rather have a standard
>> delimeter and apply that automatically.
>
> Yes, I wasn't really happy with it anyway.
Great.
>> Phase
>> =====
>>
>> Should we enforce that the special targets created as phases are
>> empty?
>
> Well, I'm not sure. The problem is who is responsible for defining
> the phase content? By enforcing they are empty, we can be sure they
> are used as placeholders to organize the build, and that's all.
OK, let me rephrase my question to make sense: "I think we should
enforce phase targets to be empty but don't see any code that does it.
Do you agree that we should?" Your answer looks as if you would 8-)
>> Does phase mapping come from a specific use-case?
>
> Not really, it's inspired by configuration mapping in Ivy, which is
> a key of integration of modules developped by different people at
> different time.
Right now it is confusing me and I'd rather want to understand when it
would be useful.
> The same can apply to build modules development, and phase mapping
> can help to integrate pretty different build modules.
Do you have an example for dumb me 8-)
> It's also useful if you want to execute some targets at a different
> than what they were designed to be, giving more control to the build
> integrating the build modules.
Where do you expect this flexibility to be required?
>> You talk about "before" targets but I don't seem them implemented,
>> yet. Am I missing something?
>
> I don't remember, but you're probably right. I haven't implemented
> everything that I first though about, just what I need for the first
> POC.
OK, I didn't expect a POC to be anything complete. I just wanted to
be sure I wasn't overlooking anything.
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
