incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Turcan" <>
Subject Re: metabuild on any module
Date Fri, 10 Jun 2011 12:57:11 GMT
I'll be more than happy to see this feature integrated, but I'm not sure it would merge nicely
with the current approach. I did make an effort for them to coexist but they seem mutually
exclusive to me. The existing metabuild implementation requires a dedicated metamodule and
translates every target into a metatarget. Mine complements regular modules with meta-functionality.
I don't mean to insist, but in my experience I never needed a dedicated metamodule, I found
"implicit" metatargets to be sufficient, and more flexible, since you get to be explicit about
the scope - all,dependencies, etc.

As for targets depending on implicit metatargets, I myself try not to abuse it, simply because
I don't want to assume that my metaexecutor is there to help me. So I add the extra 3 lines
for the iteration. I believe I do that in&nbsp;ideprojects.ant.

On Jun 10, 2011 5:52 AM, Jean-Louis Boudart &lt;; wrote:

2011/6/7 Sandu Turcan &lt;;

&gt; &gt; Looks good but it would probably be better to merge this feature in

&gt; &gt; MetaBuildExecutor. I guess current implementation delegates to the

&gt; &gt; ivy:buildlist task to compute an ordered list of submodules, this should

&gt; be

&gt; &gt; done outside of the executor making it much more reusable and extandable.

&gt; &gt;

&gt; &gt; Could we use a property instead of "target prefix" to specify the

&gt; execution

&gt; &gt; scope ("all","needed","dependencies","dependents") something like easyant

&gt; &gt; -Dmeta.mode=needed clean package  ?

&gt; &gt;

&gt; &gt; What do you think ?


&gt; Funny you should mention that, the code has changed since then, and it

&gt; now supports these exact prefixes.

&gt; You can type

&gt; easyant needed:clean+publish-local test   # run 'clean' and

&gt; 'publish-local' on needed and 'test' on the current module

&gt; or easyant dependents:publish-local

&gt; etc., all 4 of them.


Does this mean you agreed that we should merge the feature in

MetaBuildExecutor itself ?:p

&gt; It allows you to have a target in your build dependent on a "prefixed"

&gt; target and it will work, the executor will handle both cases. This

&gt; wouldn't work with -Dmeta.mode, because it assumes picking one mode

&gt; over the other, no interoperability.

&gt; It's also a shorter and more intuitive syntax, I think.


It seems really powerful feature and implementation, but in the same times

it can be "dangerous" in terms of build maintenance as &lt;ivy:buildlist&gt; will

evaluate the build order of submodules. Debuging a project having lots of

submodules and cross referencing metatarget can be like debuging a spaghetti

code application. Any thoughts on this ?

I'm not tellilng the idea is bad or we shouldn't implement it, i just

chalenge your original idea.


&gt; &gt; Then emma plugin and my property will be accessible in my submodule. I

&gt; can

&gt; &gt; give you more detail on this if you want, i'll update the documentation

&gt; &gt; soon.

&gt; &gt; Combining meta-build feature with module-inheritance could be really

&gt; &gt; powerful.


&gt; localconfig is mostly to configure easyant itself. I use it to specify

&gt; where my eclipse workspace and intellij config is (project generation

&gt; uses that). Also depending on the project I can choose a different

&gt; location of ivysettings.xml.

&gt; In other words we're talking about machine/developer specific settings

&gt; that don't belong in the source repository.

&gt; You don't ever have to use a different command for the build tool, the

&gt; configuration gets picked up based on where you are.


Oki interesting.


&gt; &gt; I also noticed that you've created a plugin to generate IDE's

&gt; configuration

&gt; &gt; files. I haven't tested it yet but looks like promosing.

&gt; &gt; Is eclipse with IvyDE supported ?

&gt; No, it generates regular projects for eclipse and intellij, I didn't

&gt; want to require additional plugins in either.

&gt; It does a slightly better job in intellij because it takes advantage

&gt; of native support for test sources, runtime dependencies, and

&gt; libraries.


But people would still be able to extends it as you provide an interface,

isn't it?

&gt; It needs EASYANT-24 to work though, so I can only use it with my own

&gt; tool for now.


Right, so then we definitively need to have a look at this issue.





Jean Louis Boudart

Independent consultant

Project Lead

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message