[DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Xavier Hanin]

On Jan 10, 2008 10:21 PM, kermitt <herve.bourzeix@...> wrote:

>
> I had a look, I share the same goal but I don't like the need to compile
> class especially just to setup a task with default value. It also had a
> bit
> of black magic as you can look quickly in source as a reference.

Exactly, this is drawbacks that should be addressed IMO.

>
>
> I read your idea about interceptor I think it could be a good idea but as
> you said it requires a new ant build.
>
> To move forward quickly, the hack of the merevaik project could be reused
> to
> implement Gilles idea ( having build file in a jar) and inject ivy as I
> suggest.
>
> What do you think?

I think I share your opinion: keep things simple to get something working
pretty quickly.

But first we'd need to know where to further discuss ideas about the
project. I've started the discussion here to get feedback, and I would like
to gather more feedback here and ideas before moving forward. But then we
will need to know if this should be an Ant subproject which could be
discussed here. Or if it would better to start outside the ASF. Let's take
some time before going into too low level details.

Xavier

>
>
>
>
>
>
> Xavier Hanin wrote:
> >
> > On Jan 10, 2008 8:16 PM, kermitt <herve.bourzeix@...> wrote:
> >
> >>
> >> I wish we could find a way to bundle common tasks : I have more than 9
> >> templates :
> >>
> >> build-common.xml
> >> build-j2ee.xml
> >> build-war.xml
> >> build-ejb.xml
> >> build-ws.xml
> >> build-client-ws.xml
> >> build-ear.xml
> >> ...
> >>
> >> These builds just formalize my build system based on Ivy.
> >> For each project I need to sync those files which is a pain within a
> >> team.
> >> How to enforce team to use your  build process, how do you easly patch,
> >> add
> >> feature. It's puzzling me. Today I need to copy paste all these files
> all
> >> over my projects.
> >>
> >> I think Ivy dictate somehow the build process as you always need to
> >> perform
> >> some tasks configure/resolve/cachepath...
> >>
> >> My common-build.xml has 9 visible targets:
> >>
> >> all -> clean , build , package , publish
> >> build -> init ivy -> resolve -> compute classpath -> do I have
> something
> >> to
> >> build ? (has dependencies  changed? files ?)  -> find what is the next
> >> release -> compile
> >> clean -> clean any generated files
> >> doc -> build any doc
> >> package -> make a jar
> >> publish -> get current ivy version -> publish jar on local repo
> >> share -> publish jar on integration repo
> >> release -> publish jar in test/prod repo
> >> test -> lauch unit tests
> >>
> >>
> >> I wish Ant import would support URL + jar like that :
> >>
> >> <project ...>
> >>   <import
> >> url="http://repo/build.jar!common-build.xml<http://repo/build.jar%21common-build.xml>
> <http://repo/build.jar%21common-build.xml>
> >> "/>
> >> </project>
> >>
> >> As ivy became a sub project, it would make sense to have a closer
> >> integration like :
> >>
> >> <project ...>
> >>   <import url="ivy://settings.xml:org/module/artifact@MyResolver" />
> >> <!--
> >> would locate the settings.xml file and seek a build-common.xml file
> using
> >> MyResolver resolver.
> >> -->
> >> </project>
> >>
> >> we could imagine deeper integration :
> >>
> >> <project ...>
> >>   <import url="ivy://settings.xml:org/module/artifact@MyResolver"
> >> ivyFile="${basedir]/ivy.xml"/>
> >> <!--
> >> configure ivy / read the ivy file
> >> would map each ivy configuration to a path ( path could use a lazy
> >> resolve
> >> proxy: resolve only when it get used)
> >> would import resolved artifcat as an ant build file
> >>
> >> -->
> >> </project>
> >
> >
> > Improving the import mechanism to leverage Ivy is indeed a good idea and
> a
> > good solution to package the build system parts. I also like what has
> been
> > done in merevaik, leveraging directly the xmlns support in Ant (see the
> > comment on my blog).
> >
> > Xavier
> >
> >
> >>
> >>
> >> I think is not easy to not like maven ... but Xavier is right it's time
> >> to
> >> go a step beyond with ant+ivy
> >>
> >>
> >> So any comments on that ?
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
> >> Sent from the Ant - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14744234.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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/

[Matt Benson]

--- Xavier Hanin <xavier.hanin@...> wrote:

> On Jan 10, 2008 9:33 PM, Dominique Devienne
> <ddevienne@...> wrote:
>
> > On Jan 10, 2008 2:13 PM, Xavier Hanin
> <xavier.hanin@...> wrote:
> > > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht
> <peter.arrenbrecht@...>
> > > > Providing
> > > > override hooks is all well and good, but that
> is still basically the
> > > > very controlled and rigit maven approach, I
> think.
> > >
> > > It depends on what you accept to do in your
> override. If the build
> > system
> > > somewhat relies on Ant import mechanism, you are
> able to override  any
> > > target defined by the build system. In the end
> if you have something
> > very
> > > specific the worst that could happen is override
> everything, making the
> > > build system useless except it first provided a
> structure. But at least
> > you
> > > are always free, which is not the case with
> maven.
> >
> > Maven's override hooks are a good thing IMHO. The
> problem with Ant is
> > that you have to provide them explicitly in the
> ''abstract'' build
> > file so that the ''concrete'' build can override
> them, as opposed to
> > Maven's hooks, where you simply define in pre-goal
> in the concrete
> > build without any need to modify the abstract
> build.
> >
> > It's the C++ where all class methods are
> non-virtual by default, and
> > and Java where there's virtual by default. Unless
> the class is
> > specifically designed not to be extended, the Java
> way is more
> > flexible because you can often intercept the
> virtual call and make
> > your pre and post processing there. (let's not go
> into philosophical
> > flame about the good or bad of this please)
> >
> > Having the ability to say in Ant <target
> before="compile"/> or <target
> > after="deploy"/> with no need to add explicit
> -pre-compile or
> > -post-deploy hooks in the base build would already
> simplify things
> > when customizing a base build, and make it more
> ''hackable''.
>
> I was thinking about something even more flexible
> based on events: <target
> on="before:compile" />. Then all you need is trigger
> events at the beginning
> and the end of each target. The problem is that
> either solutions require
> changes in Ant.
>
> Similarly, an explicit <target override="compile"/>
> to explicitly
> > completely replace a base target is better IMHO to
> the implicit
> > override that currently happens, and makes the
> build file more
> > readable/explicit about the intent. --DD
>
> True, pretty much like the @Override introduced in
> Java 5.
>
>
> > PS: The before/after target would be moot is
> <target override>
> > supported a nested <super/> element. That's a
> syntax that would flow
> > better IHMO.
>
> Yes, would be a nice improvement too. But in my mind
> I was more thinking
> about a build system based on current Ant feature
> set and syntax, at least
> for a first version. Unless several Ant committers
> would like to get
> involved and target a new Ant version to support the
> new build system.
>
> Opinions?
>

1.  You yourself are an Ant committer now.  ;)
2.  Usually it seems we are able to do new things
without precluding the old; as long as this is the
case I don't see why you, I, we, or somebody else
can't do reasonable things to make Any more
extensible.

$0.02

-Matt


> Xavier
>
> >
> >
> >
>
---------------------------------------------------------------------

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

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

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

[Stefan Bodewig]

"Xavier Hanin" <xavier.hanin@...> writes:

> On Jan 10, 2008 10:20 PM, Bruce Atherton <bruce@...> wrote:
>
>> There used to be a project called Centipede that built Ant scripts
>> into something called "cents", which were attempts to capture best
>> practices for various parts of builds.

> It seems at least that it was done before ant 1.6, so before the
> import feature which is a key foundation of modular builds with Ant
> IMO.

One of Centipede's developers - Nikola Ken Barozzi - used to be
subscribed to this list.  He contributed a lot to the Ant 1.6 feature
set, in particular import and PropertyHelpers IIRC.

> Hence I'm not sure if anything could be reused from this effort,
> except maybe some ideas, and feedback if we could get some members
> of the project on this discussion.

Like Bruce I think the project has died and it will be difficult to
get the old developers involved here.

Stefan

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

[Stefan Bodewig]

"Xavier Hanin" <xavier.hanin@...> writes:

> But in my mind I was more thinking about a build system based on
> current Ant feature set and syntax,

Which probably would lead to a more complex system than it needed to
be without such a restriction.

Dominique's <super/> or something similar was among the features the
Centipede folks wanted us to do, but that never happened.  With more
Ant committers directly involved the project you envision would have
way more chances to succeed in influencing Ant.

> at least for a first version.

If you want to have a first release quickly, I agree.

> Unless several Ant committers would like to get involved and target
> a new Ant version to support the new build system.

I would like to get involved, but can't promise to not disapear for
weeks like I've been doing over the past years.

At least three other Ant committers (apart from you and me) have been
involved in this thread so I'd say chances aren't that bad.

Stefan

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

[Peter Arrenbrecht]

On Jan 10, 2008 9:33 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 10, 2008 2:13 PM, Xavier Hanin <xavier.hanin@...> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
> > > very controlled and rigit maven approach, I think.
> >
> > It depends on what you accept to do in your override. If the build system
> > somewhat relies on Ant import mechanism, you are able to override  any
> > target defined by the build system. In the end if you have something very
> > specific the worst that could happen is override everything, making the
> > build system useless except it first provided a structure. But at least you
> > are always free, which is not the case with maven.
>
> Maven's override hooks are a good thing IMHO. The problem with Ant is
> that you have to provide them explicitly in the ''abstract'' build
> file so that the ''concrete'' build can override them, as opposed to
> Maven's hooks, where you simply define in pre-goal in the concrete
> build without any need to modify the abstract build.
>
> It's the C++ where all class methods are non-virtual by default, and
> and Java where there's virtual by default. Unless the class is
> specifically designed not to be extended, the Java way is more
> flexible because you can often intercept the virtual call and make
> your pre and post processing there. (let's not go into philosophical
> flame about the good or bad of this please)

Hmm. I was expecting the abstract build to be well designed in this
case (and yes, I believe in carefully designed overridability). But,
more importantly, if it does not suit your needs, in Ant you can just
override the import with the exact code you copy from the template,
and then tweak it. Advantages of that have been discussed further
above in this thread.

-peo

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

[Peter Arrenbrecht]

On Jan 10, 2008 9:13 PM, Xavier Hanin <xavier.hanin@...> wrote:

> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
> wrote:
>
> > Providing
> > override hooks is all well and good, but that is still basically the
> > very controlled and rigit maven approach, I think.
> It depends on what you accept to do in your override. If the build system
> somewhat relies on Ant import mechanism, you are able to override  any
> target defined by the build system. In the end if you have something very
> specific the worst that could happen is override everything, making the
> build system useless except it first provided a structure. But at least you
> are always free, which is not the case with maven.

Then by all means let's use import. This is exactly what I meant.

> > It's like the
> > difference between an interpreter and a code generator. IIRC, in Rails
> > you normally get interpretation (on the fly code generation, in fact),
> > but you can always switch to full blown code generation which you can
> > then inspect and tweak. I think that is part of the reason for its
> > success. It makes the whole thing transparent, but let's people stick
> > to the standard where that suffices.
> Interesting comparison, not sure how it could be applied to the build system
> though.

IIRC, custom Maven steps are written in Java. You cannot look at the
provided build logic in the language you are working in to describe
your build. So Maven is an interpreter.

The envisioned Ant build template would feel more like on-the-fly code
generation (import could be thought of as inlining its stuff), with
the option of truly inling the code for tweaking.

Background on this way of looking at it:
http://peomeint.blogspot.com/2005/10/debugging-domain-specific-languages.html

-peo

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

[Gilles Scokart]

2008/1/10, Dominique Devienne <ddevienne@...>:
>
>
> it was successful enough to still be in use today more than 2 years
> after I'm gone, mostly untouched.
>
>
I think this is very usual.  Once a build system is ok, no-one want to take
the risk to change it, and often no-one can change it anymore.

This is why black magic should be avoided.  And this is why good
documentation techniques are required.

If you have ever maintained a generic build script written by someone else
you probably understand what I mean.

I think this is the major challenge in the build managment today.  And that
will be the challenge for such a project.

--
Gilles Scokart

[Gilles Scokart]

I never thought to overwrite macro to customize a generic build script.  Can
macro be overwritten?



2008/1/10, Wolfgang Häfelinger <whaefelinger@...>:

>
> >> it is certainly something that already exists in the wild.  Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO  in The Hague. Ca. 90% of our Java
> projects are using AntEpoline, the remaining mainly Maven I.
>
> Here's how a typical build file looks like:
>
> <project name="helloworld" xmlns:c="antlib:ant.epoline">
>   <c:import />
>
>   <dependencies>
>     <dependency groupid="log4j" artefactid="log4j" version="1.2.13" />
>   </dependencies>
>
>   <macrodef name="package">
>     <sequential>
>       <!-- "original" packaging" -->
>       <c:package />
>       <!-- so something else -->
>     </sequential>
>   </macrodef>
> </project>
>
>

--
Gilles Scokart

[Stefan Bodewig]

"Gilles Scokart" <gscokart@...> writes:

> I never thought to overwrite macro to customize a generic build script.  Can
> macro be overwritten?

Sure, it's just another Ant task that has been defined.

Stefan

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

[ddevienne]

On Jan 11, 2008 8:11 AM, Stefan Bodewig <bodewig@...> wrote:
> "Gilles Scokart" <gscokart@...> writes:
>
> > I never thought to overwrite macro to customize a generic build script.  Can
> > macro be overwritten?
>
> Sure, it's just another Ant task that has been defined.

But my point is that most of the time, you never want to override
things (macros or target), but augment them with some kind of pre or
post processing. Peo's point of simply copy-pasting the "abstract"
build code to fully override the target duplicates that code, and
makes build maintenance all the more difficult. That's the well known
issue with code generator and code wizards when it's done in a one-of
way. Copy-pasting a target content shows failure of the generic build
to be flexible, and should be the exception rather than the rule, and
actually frowned upon IMHO. --DD

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

[Peter Arrenbrecht]

On Jan 11, 2008 5:14 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bodewig@...> wrote:
> > "Gilles Scokart" <gscokart@...> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script.  Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD

That is correct. However, being able to do it still beats not being
able to. It allows for a better balancing of accommodating yet another
esoteric hook request and making the template yet more complex vs.
just telling someone to inline and tweak the template for their
esoteric case.

And being able to learn from looking at the imported script is also
very valuable.

But I think we understand each other, basically. ;)

-peo

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

[Niamath Khan]

Please unsubscribe me from the following list.
 


----- Original Message ----
From: Peter Arrenbrecht <peter.arrenbrecht@...>
To: Ant Developers List <dev@...>
Sent: Friday, January 11, 2008 10:40:40 AM
Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

On Jan 11, 2008 5:14 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bodewig@...> wrote:
> > "Gilles Scokart" <gscokart@...> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script.  Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD

That is correct. However, being able to do it still beats not being
able to. It allows for a better balancing of accommodating yet another
esoteric hook request and making the template yet more complex vs.
just telling someone to inline and tweak the template for their
esoteric case.

And being able to learn from looking at the imported script is also
very valuable.

But I think we understand each other, basically. ;)

-peo

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

[Xavier Hanin]

On Jan 11, 2008 5:14 PM, Dominique Devienne <ddevienne@...> wrote:

> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bodewig@...> wrote:
> > "Gilles Scokart" <gscokart@...> writes:
> >
> > > I never thought to overwrite macro to customize a generic build
> script.  Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD

+1

Xavier

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

[Xavier Hanin]

On Jan 11, 2008 5:40 PM, Peter Arrenbrecht <peter.arrenbrecht@...>
wrote:

> [...]
> That is correct. However, being able to do it still beats not being
> able to. It allows for a better balancing of accommodating yet another
> esoteric hook request and making the template yet more complex vs.
> just telling someone to inline and tweak the template for their
> esoteric case.
>
> And being able to learn from looking at the imported script is also
> very valuable.

+1 too. This is a key foundation of the flexibility IMO. Trying to deliver a
build system which address everything is impossible, but it can always be a
good basis, at least to learn from. Leveraging the knowledge people have
from Ant syntax will help them to get value from the build system, even when
their problem is very specific.

Xavier

>
> But I think we understand each other, basically. ;)
>
> -peo
>
> ---------------------------------------------------------------------
> 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/

[Xavier Hanin]

On Jan 11, 2008 9:55 AM, Gilles Scokart <gscokart@...> wrote:

> 2008/1/10, Dominique Devienne <ddevienne@...>:
> >
> >
> > it was successful enough to still be in use today more than 2 years
> > after I'm gone, mostly untouched.
> >
> >
> I think this is very usual.  Once a build system is ok, no-one want to
> take
> the risk to change it, and often no-one can change it anymore.
>
> This is why black magic should be avoided.  And this is why good
> documentation techniques are required.
>
> If you have ever maintained a generic build script written by someone else
> you probably understand what I mean.
>
> I think this is the major challenge in the build managment today.  And
> that
> will be the challenge for such a project.

Agreed. IMO this is a challenge for any system. A good answer to this tough
problem is usually documentation and modularity. Modularity let divide the
tough problem is smaller parts, easier to understand and to maintain. I see
many Ant based build systems which are unmaintainable just because they
aren't modular and have a lot of duplicate code. So I think we should try to
make the build system modular, and the Ant import system already help, even
though some limitations make some things difficult as Dominique pointed out.

Another advantage of such a system over purely home made systems is that you
share knowledge of the system architecture over a community. So even if we
don't manage to make a system easy to understand, it will probably be easier
to maintain for users just because they can ask question about how the
system is built to the community who built it or is maintaining it.

Xavier

>
>
> --
> Gilles Scokart
>



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

[Xavier Hanin]

On Jan 11, 2008 6:35 AM, Stefan Bodewig <bodewig@...> wrote:

> "Xavier Hanin" <xavier.hanin@...> writes:
>
> > But in my mind I was more thinking about a build system based on
> > current Ant feature set and syntax,
>
> Which probably would lead to a more complex system than it needed to
> be without such a restriction.

You're right. I guess I still don't feel like a true Ant committer yet,
that's maybe why I still try to envision things which do not require changes
in Ant.


> Dominique's <super/> or something similar was among the features the
> Centipede folks wanted us to do, but that never happened.  With more
> Ant committers directly involved the project you envision would have
> way more chances to succeed in influencing Ant.

Exactly. That's one of the reason why I started this discussion here :-)

>
>
> > at least for a first version.
>
> If you want to have a first release quickly, I agree.

To be honest I don't really mind about when we get the first release. This
idea does not come from a need I have on any particular project. That being
said I think one of the key of the success of good adoption is to adopt the
"release early, release often" principle. Another reason why I try to see a
very simple solution which does not require changes is that I don't have
much time to involve in the project, so by keeping things simple we get more
chance to get something actually done and working.

>
>
> > Unless several Ant committers would like to get involved and target
> > a new Ant version to support the new build system.
>
> I would like to get involved,

Great!


> but can't promise to not disapear for
> weeks like I've been doing over the past years.

I can't either. I think all of us are doing this work in our spare time, and
we don't always have spare time. But power comes from the community, and the
more people get involved, the more likely to succeed is the project IMHO.


>
> At least three other Ant committers (apart from you and me) have been
> involved in this thread so I'd say chances aren't that bad.

:-)  And the rate of opinions and thoughts given in this thread is a good
sign too.

Xavier


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

"Dominique Devienne" <ddevienne@...> writes:

> On Jan 11, 2008 8:11 AM, Stefan Bodewig <bodewig@...> wrote:
>> "Gilles Scokart" <gscokart@...> writes:
>>
>> > I never thought to overwrite macro to customize a generic build script.  Can
>> > macro be overwritten?
>>
>> Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing.

Hey, I didn't say it was a good thing to do, I just pointed out that
technically you can override a macrodef'ed task just like any other
task.

> Peo's point of simply copy-pasting the "abstract" build code to
> fully override the target duplicates that code, and makes build
> maintenance all the more difficult.

I'm not convinced that we need something like this at the task level,
while I agree we need some better support for it at the target level.

Back during the Ant2 discussions we have been talking about adding AOP
like features to Ant at a well-defined "pointcut"s like target and
task invactions.  This may be overkill, though.

Having something like before/after/around advices (where around is the
same as an override that doesn't change the dependencies list) may
suffice and leave overwriting the whole target definition to the worst
case.

Stefan

--
http://stefan.samaflost.de/

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

[ddevienne]

On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> "Dominique Devienne" <ddevienne@...> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target definition to the worst
> case.

Thanks for reminding me of this issue Stefan. Indeed, something I
really didn't like about overriding the whole target, is that you had
to duplicate the dependency list as well...

Which is why I now remember that I now remember I used 4, not 3
targets, in the "abstract" build, the forth one being the target's own
content, separate from its dependency list:

So every concrete simple target like <target name="foo" depends="bar,
baz" /> became

<target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
<target name="-foo" > ... </target>
<target name="-pre-foo" />
<target name="-post-foo" />

in the "abstract" build. Override -foo to replace just the target
content, without it's dependency list. Or override foo to have
complete control, but in my experience it's -foo that needed
overriding, not foo.

Note though that unlike before and after, around isn't as
representative a name. When I thought about this issue a while back, I
thought of using a magic name such as "super" in the depends attribute
to refer to the overridden target's dependency list, similar to using
<super/> in the target's body to refer to the overridden target's task
list/content. --DD

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

[Wolfgang Häfelinger]

> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />

This looks pretty ugly this me!

I believe that this whole discussion focusses too much on targets
instead of macros. Macros are a very powerfull feature and they
deserve much more attention!

Why not simply:

<!-- === framework === -->
<target name="foo" depends="bar,baz" description="public foo target">
  <foo />
</target>

<macrodef name="foo" >
  <sequential>
    <!-- to the foo thing -->
  </sequential>
</macrodef>


If a user then really need to override "foo", he or she would simply
write in build.xml something like


<macrodef name="foo">
  <sequential>
    <echo> before original foo ..</echo>
 
    <c:foo />       <!-- assume framework in NS "c" />

    <echo> after original foo .. </echo>
  </sequential>
</macrodef>


Notice that I'm only using the name "foo" and not "-post-foo" and all
your other names.


Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. [phone]
whaefelinger@...
http://www.epo.org




"Dominique Devienne" <ddevienne@...>
14-01-2008 17:17
Please respond to
"Ant Developers List" <dev@...>


To
"Ant Developers List" <dev@...>
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects






On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> "Dominique Devienne" <ddevienne@...> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target definition to the worst
> case.

Thanks for reminding me of this issue Stefan. Indeed, something I
really didn't like about overriding the whole target, is that you had
to duplicate the dependency list as well...

Which is why I now remember that I now remember I used 4, not 3
targets, in the "abstract" build, the forth one being the target's own
content, separate from its dependency list:

So every concrete simple target like <target name="foo" depends="bar,
baz" /> became

<target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
<target name="-foo" > ... </target>
<target name="-pre-foo" />
<target name="-post-foo" />

in the "abstract" build. Override -foo to replace just the target
content, without it's dependency list. Or override foo to have
complete control, but in my experience it's -foo that needed
overriding, not foo.

Note though that unlike before and after, around isn't as
representative a name. When I thought about this issue a while back, I
thought of using a magic name such as "super" in the depends attribute
to refer to the overridden target's dependency list, similar to using
<super/> in the target's body to refer to the overridden target's task
list/content. --DD

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

[Xavier Hanin]

On Jan 14, 2008 5:35 PM, Wolfgang Häfelinger <whaefelinger@...> wrote:

> > So every concrete simple target like <target name="foo" depends="bar,
> > baz" /> became
> >
> > <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> > <target name="-foo" > ... </target>
> > <target name="-pre-foo" />
> > <target name="-post-foo" />
>
> This looks pretty ugly this me!

If I understand correctly, that's exactly what Dominique complained about
:-)

>
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> <!-- === framework === -->
> <target name="foo" depends="bar,baz" description="public foo target">
>  <foo />
> </target>
>
> <macrodef name="foo" >
>  <sequential>
>    <!-- to the foo thing -->
>  </sequential>
> </macrodef>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> <macrodef name="foo">
>  <sequential>
>    <echo> before original foo ..</echo>
>
>    <c:foo />       <!-- assume framework in NS "c" />
>
>    <echo> after original foo .. </echo>
>  </sequential>
> </macrodef>
>
>
> Notice that I'm only using the name "foo" and not "-post-foo" and all
> your other names.

I'm not familiar with macro overriding, but how the custom foo macro get
called by the original foo target? Do you have to override the foo target to
call your custom foo macro?

Xavier

>
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. [phone]
> whaefelinger@...
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <ddevienne@...>
> 14-01-2008 17:17
> Please respond to
> "Ant Developers List" <dev@...>
>
>
> To
> "Ant Developers List" <dev@...>
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> On 1/14/08, Stefan Bodewig <bodewig@...> wrote:
> > "Dominique Devienne" <ddevienne@...> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies list) may
> > suffice and leave overwriting the whole target definition to the worst
> > case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:
>
> So every concrete simple target like <target name="foo" depends="bar,
> baz" /> became
>
> <target name="foo" depends="bar, baz, -pre-foo, -foo, -post-foo" />
> <target name="-foo" > ... </target>
> <target name="-pre-foo" />
> <target name="-post-foo" />
>
> in the "abstract" build. Override -foo to replace just the target
> content, without it's dependency list. Or override foo to have
> complete control, but in my experience it's -foo that needed
> overriding, not foo.
>
> Note though that unlike before and after, around isn't as
> representative a name. When I thought about this issue a while back, I
> thought of using a magic name such as "super" in the depends attribute
> to refer to the overridden target's dependency list, similar to using
> <super/> in the target's body to refer to the overridden target's task
> list/content. --DD
>
> ---------------------------------------------------------------------
> 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/