You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2011/06/06 14:57:35 UTC

Re: metabuild on any module

Hi,

Sorry for the long delay i had a lot of mails late.

2011/4/4 Alexander Turcan <id...@gmail.com>

> Hi,
> My name is Sandu Turcan, and I've been following the progress of
>
> easyant for a while.
>
>
>
> I've worked on something similar at some point, so it's interesting to
>
> see how other people are approaching it.
>
> I like the modularity of easyant builds much better then what I had,
>
> and that's just the first thing I noticed.
>
>
>
> Like with any product there are things I miss, like metabuild
>
> functionality from anywhere.
>
> Our project had close to 50 source modules, and we could go to any one
>
> of them and treat it as a starting point for a metabuild.
>

Interesting usecase



>
> I wrote a module for easyant that does the same thing.
>
>
>
> Here is how it works:
>
> It can be imported as a plugin (but should work as a regular module as
> well):
>
>        &lt;plugin mrid="idlsoft.easyant.plugins#metabuildsupport;1.0"
> as="mm"/&gt;
>
> You will not see any additional targets, but you can do something like:
>
> eant mm:all:doit  - invokes doit on all, including the current one
>
> eant mm:all:clean - invokes clean on all
>
> eant mm:deps:doit - invokes doit only on dependencies
>
> eant mm:deps:clean+doit - invokes clean and doit on dependencies
>
>
>
> I had to implement my own ant Executor, but I made sure to avoid
>
> conflict with the bundled meta-build.
>
> The code is on https://bitbucket.org/idlsoft/easyant-modules
>

Looks good but it would probably be better to merge this feature in
MetaBuildExecutor. I guess current implementation delegates to the
ivy:buildlist task to compute an ordered list of submodules, this should be
done outside of the executor making it much more reusable and extandable.

Could we use a property instead of "target prefix" to specify the execution
scope ("all","needed","dependencies","dependents") something like easyant
-Dmeta.mode=needed clean package  ?

What do you think ?



>
>
> This covers most of what I need but it would be really helpful to have
>
> a few additional features in SubModule, I described them at
>
> https://issues.apache.org/jira/browse/EASYANT-24
>

I'll have a look to see what could be done here.



>
>
>
> I'm also working on another module - configuring easyant depending on
>
> basedir. The idea is to walk the directory structure from the current
>
> directory up, look for easyant.properties files, and load them.
>
> Ideally this could be supported by standard easyant configuration, because
>
> then it could kick in before the plugin repository is initialized.
>

I'm not sure i understand the real objective of this plugin could you give a
concrete example ?
I assume this should be usefull when you need to share properties across
subprojects  isn't it ?
Easyant has an undocumented feature to inherited properties / plugins  :
http://incubator.apache.org/easyant/history/trunk/howto/multimodules.html#module-inheritance
You can create module.ivy files with your shared configuration it can be
properties / plugins / dependencies etc...
Then  you can reference it in your own module.ivy using <extends> tag.

Let's take a concrete example :
Imagine this is the "parent.ivy" where all configurations are shared

<ivy-module version="2.0">
    <info organisation="org.apache.easyant" module="example-parent"
revision="0.1" status="integration" >
        <ea:plugin module="emma" revision="0.1"/>
        <ea:property module="myproperty" revision="i would love to be
inherited"/>
    </info>
    ...
</ivy-module>

And in submodules requiring this configuration we would have something like

<ivy-module version="2.0">
    <info organisation="org.apache.easyant" module="example-submodule"
status="integration" >
        <!-- Inherit all meta data (plugins, properties, dependencies)
from org.apache.easyant#example-parent in revision 0.1 -->
        <extends organisation="org.apache.easyant"
name="example-parent" revision="0.1" />
        <ea:build module="build-webapp-java" revision="0.1"/>
    </info>
    ...
</ivy-module>


Then emma plugin and my property will be accessible in my submodule. I can
give you more detail on this if you want, i'll update the documentation
soon.
Combining meta-build feature with module-inheritance could be really
powerful.




I also noticed that you've created a plugin to generate IDE's configuration
files. I haven't tested it yet but looks like promosing.
Is eclipse with IvyDE supported ?

Thanks for your interest
-- 
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org

Re: metabuild on any module

Posted by Alexander Turcan <id...@gmail.com>.
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;jeanlouis.boudart@gmail.com&gt; wrote: 

2011/6/7 Sandu Turcan &lt;idlsoft@gmail.com&gt;



&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;

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

&gt;

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.

&gt;

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; &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;

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

&gt;

Oki interesting.







&gt;

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

&gt;

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.

&gt;

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



&gt;

&gt;

Cheers,

-- 

Jean Louis Boudart

Independent consultant

Project Lead http://www.easyant.org

Re: metabuild on any module

Posted by Jean-Louis Boudart <je...@gmail.com>.
2011/6/7 Sandu Turcan <id...@gmail.com>

> > Looks good but it would probably be better to merge this feature in
> > MetaBuildExecutor. I guess current implementation delegates to the
> > ivy:buildlist task to compute an ordered list of submodules, this should
> be
> > done outside of the executor making it much more reusable and extandable.
> >
> > Could we use a property instead of "target prefix" to specify the
> execution
> > scope ("all","needed","dependencies","dependents") something like easyant
> > -Dmeta.mode=needed clean package  ?
> >
> > What do you think ?
>
> Funny you should mention that, the code has changed since then, and it
> now supports these exact prefixes.
> You can type
> easyant needed:clean+publish-local test   # run 'clean' and
> 'publish-local' on needed and 'test' on the current module
> or easyant dependents:publish-local
> etc., all 4 of them.
>
Does this mean you agreed that we should merge the feature in
MetaBuildExecutor itself ?:p


> It allows you to have a target in your build dependent on a "prefixed"
> target and it will work, the executor will handle both cases. This
> wouldn't work with -Dmeta.mode, because it assumes picking one mode
> over the other, no interoperability.
> 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 <ivy:buildlist> 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.




>
> > Then emma plugin and my property will be accessible in my submodule. I
> can
> > give you more detail on this if you want, i'll update the documentation
> > soon.
> > Combining meta-build feature with module-inheritance could be really
> > powerful.
>
> localconfig is mostly to configure easyant itself. I use it to specify
> where my eclipse workspace and intellij config is (project generation
> uses that). Also depending on the project I can choose a different
> location of ivysettings.xml.
> In other words we're talking about machine/developer specific settings
> that don't belong in the source repository.
> You don't ever have to use a different command for the build tool, the
> configuration gets picked up based on where you are.
>
Oki interesting.



>
> > I also noticed that you've created a plugin to generate IDE's
> configuration
> > files. I haven't tested it yet but looks like promosing.
> > Is eclipse with IvyDE supported ?
> No, it generates regular projects for eclipse and intellij, I didn't
> want to require additional plugins in either.
> It does a slightly better job in intellij because it takes advantage
> of native support for test sources, runtime dependencies, and
> libraries.
>
But people would still be able to extends it as you provide an interface,
isn't it?



> It needs EASYANT-24 to work though, so I can only use it with my own
> tool for now.
>
Right, so then we definitively need to have a look at this issue.

>
>
Cheers,
-- 
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org

Re: metabuild on any module

Posted by Sandu Turcan <id...@gmail.com>.
> Looks good but it would probably be better to merge this feature in
> MetaBuildExecutor. I guess current implementation delegates to the
> ivy:buildlist task to compute an ordered list of submodules, this should be
> done outside of the executor making it much more reusable and extandable.
>
> Could we use a property instead of "target prefix" to specify the execution
> scope ("all","needed","dependencies","dependents") something like easyant
> -Dmeta.mode=needed clean package  ?
>
> What do you think ?

Funny you should mention that, the code has changed since then, and it
now supports these exact prefixes.
You can type
easyant needed:clean+publish-local test   # run 'clean' and
'publish-local' on needed and 'test' on the current module
or easyant dependents:publish-local
etc., all 4 of them.
It allows you to have a target in your build dependent on a "prefixed"
target and it will work, the executor will handle both cases. This
wouldn't work with -Dmeta.mode, because it assumes picking one mode
over the other, no interoperability.
It's also a shorter and more intuitive syntax, I think.

> Then emma plugin and my property will be accessible in my submodule. I can
> give you more detail on this if you want, i'll update the documentation
> soon.
> Combining meta-build feature with module-inheritance could be really
> powerful.

localconfig is mostly to configure easyant itself. I use it to specify
where my eclipse workspace and intellij config is (project generation
uses that). Also depending on the project I can choose a different
location of ivysettings.xml.
In other words we're talking about machine/developer specific settings
that don't belong in the source repository.
You don't ever have to use a different command for the build tool, the
configuration gets picked up based on where you are.

> I also noticed that you've created a plugin to generate IDE's configuration
> files. I haven't tested it yet but looks like promosing.
> Is eclipse with IvyDE supported ?
No, it generates regular projects for eclipse and intellij, I didn't
want to require additional plugins in either.
It does a slightly better job in intellij because it takes advantage
of native support for test sources, runtime dependencies, and
libraries.
It needs EASYANT-24 to work though, so I can only use it with my own
tool for now.

>
> Thanks for your interest
> --
Thank you for your effort.

Sandu