EasyAnt POC

[Stefan Bodewig]

Hi all,

this is just from going through the docs and looking at the patches to
Ant.

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?

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?  Given that, would <use>
prevent me from invoking the non-prefixed targets or where exactly is
the difference between use and current import?

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.

Phase
=====

Should we enforce that the special targets created as phases are
empty?

Does phase mapping come from a specific use-case?

Is

  <phase mapping="foo => baz" />

easier to approach than

  <phasemap from="foo" to="bar"/>

- I don't really know.

You talk about "before" targets but I don't seem them implemented,
yet.  Am I missing something?

Modules
=======

Looking through the examples I see there is a lot more going on than
the docs say (versioning seems to be implied by the version number
being part of the directories.  Need to look through the examples
before I can say more.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <bodewig@...> wrote:

> Hi all,

Hi Stefan,

>
>
> this is just from going through the docs and looking at the patches to
> Ant.
>
> 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.


>
>
> 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.

Given that, would <use>
> prevent me from invoking the non-prefixed targets or where exactly is
> the difference between use and current import?
>
> 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.

>
>
> 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.

>
>
> 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. The
same can apply to build modules development, and phase mapping can help to
integrate pretty different build modules. 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.

>
>
> Is
>
>  <phase mapping="foo => baz" />
>
> easier to approach than
>
>  <phasemap from="foo" to="bar"/>
>
> - I don't really know.

Maybe the latter approach is better. The first one is inspired by Ivy
configuration mapping syntax, but it's reversed (in Ivy the arrow means
"depends on". So I guess I finally prefer the latter approach.


>
>
> 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.

Xavier

>
>
> Modules
> =======
>
> Looking through the examples I see there is a lot more going on than
> the docs say (versioning seems to be implied by the version number
> being part of the directories.  Need to look through the examples
> before I can say more.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Stefan Bodewig]

On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:

> On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <bodewig@...> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Mon, Apr 7, 2008 at 4:48 PM, Stefan Bodewig <bodewig@...> wrote:

> On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:
>
> > On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <bodewig@...>
> wrote:
>
> >> 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.

Yes, but then you have to always think about prefixing your target
dependencies in B. And if you want to avoid collisions, you need to use
fully qualified names for your modules, so your target would be <target
name="test" depends="org.foo.bar.moduleB:init"/>. With several target
dependencies, it becomes quickly ugly:
<target name="test" depends="org.foo.bar.moduleB:init,
org.foo.bar.moduleB:prepare, org.foo.bar.moduleB:assert"/>

>
>
> >> 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-)

Indeed :-)

>
>
> >> 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-)

Let's say that I have a module A which has been designed to be used with 2
phases: generate, compile
module B from another organization has been designed to be used with 5
phases: generate-src, compile-src, generate-test, compile-test and test

If I want to integrate both modules in one build, I may choose to define 5
phases (the same as for module B), and map generate to generate-src and
compile to compile-src when using module A.

Does it make sense?

>
>
> > 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?

I think one of the key aspect of the build system I'm thinking about is
flexibility. If you don't need something flexible, you should better use
maven, because it exists. In a system where you let people define their own
phases, you need to let control to the people who assemble the build
modules.

Xavier

>
>
> >> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Stefan Bodewig]

Xavier,

I'll sleep over it and just want to make sure that you know that I
really just want to find out why you are doing/adding some stuff.  I'm
not questioning their utility at all.  I really appreciate your
persistence and the way you are pushing us a bit out of stagnation.

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Mon, Apr 7, 2008 at 5:39 PM, Stefan Bodewig <bodewig@...> wrote:

> Xavier,
>
> I'll sleep over it and just want to make sure that you know that I
> really just want to find out why you are doing/adding some stuff.  I'm
> not questioning their utility at all.

It's fine, I don't pretend to have THE solution.


> I really appreciate your
> persistence and the way you are pushing us a bit out of stagnation.

And I really appreciate your feedback :-)

Xavier

>
>
> Cheers
>
>        Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Stefan Bodewig]

On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:

>On Mon, Apr 7, 2008 at 4:48 PM, Stefan Bodewig <bodewig@...> wrote:
>
>> On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:
>>
>> > On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <bodewig@...>
>> wrote:
>>
>> >> 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.
>
> Yes, but then you have to always think about prefixing your target
> dependencies in B.

Well, sometimes you really need to be sure that it is "your" target
that gets executed and in other cases you really want others to be
able to override that target.

OK, I think I now start to see where you are heading.  <use> would
preclude the "I want to allow overriding" completely, you'd have to
use <extend> in that case.  Makes sense.

>> >> 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-)
>
> Let's say that I have a module A which has been designed to be used
> with 2 phases: generate, compile module B from another organization
> has been designed to be used with 5 phases: generate-src,
> compile-src, generate-test, compile-test and test
>
> If I want to integrate both modules in one build, I may choose to define 5
> phases (the same as for module B), and map generate to generate-src and
> compile to compile-src when using module A.
>
> Does it make sense?

It does, thanks.

>> > 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?
>
> I think one of the key aspect of the build system I'm thinking about
> is flexibility.  If you don't need something flexible, you should
> better use maven, because it exists.

Ouch, point taken 8-)

There certainly are two sides to that coin, though.  If it is too
flexible it becomes unusable.  As long as our defaults are OK that
might work.  I'm just a bit careful of flexibility for flexibilties
sake.  If you can explain to me why it is needed (and you did), I'll
no longer challenge it.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Tue, Apr 8, 2008 at 9:51 AM, Stefan Bodewig <bodewig@...> wrote:

> On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:
> >
> > I think one of the key aspect of the build system I'm thinking about
> > is flexibility.  If you don't need something flexible, you should
> > better use maven, because it exists.
>
> Ouch, point taken 8-)
>
> There certainly are two sides to that coin, though.  If it is too
> flexible it becomes unusable.

I agree.


> As long as our defaults are OK that
> might work.  I'm just a bit careful of flexibility for flexibilties
> sake.

You're right, sometimes I'm not careful enough, it's good to have people
challenging this :-)

Xavier

> If you can explain to me why it is needed (and you did), I'll
> no longer challenge it.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/