You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2008/11/05 16:59:53 UTC
EasyAnt
Hi,
Jean-Louis or Xavier may correct me if I'm wrong.
IIUC EasyAnt solits the two use-cases found for <import> into two
logical tasks.
* you never want to override a target, you just want to reuse them:
<use>
* you may want to override some/most targets: <extends>
Technically <extends> is what <import> is today. <import>ed targets
that haven't been overwritten in the main build are known under two
names (prefixed and not prefixed) and the depends lists of the targets
in the <extends>-imported file are not rewritten.
Targets coming from a <use>d file only exist in their prefixed form
and their dependencies are rewritten to include prefixes as well.
I.e. you can not override the <use>d target's dependencies.
There has been some confusion from time to time on the user list as to
how you can ensure you get "your" target and not an overwritten one in
an imported file, so I think <use> is useful outside of EasyAnt as
well.
EasyAnt also adds an as-attribute to <use> where the writer of the
importing build file can control the prefix of the <use>d targets and
overrules the <use>d project's name. This makes sense IMHO.
I'm not totally sure whether the as-attribute would make sense for
<extends> as well, EasyAnt currently silently ignores it in that case.
Changes would be required to the import task as well as to
ProjectHelper2 (the specific patch also patches AntXMLContext and
ProjectHelper, but that may turn out to be not necessary. It's an
implementation detail).
Opinions?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
> <je...@gmail.com> wrote:
> > I'm not sure that adding an as-attribute make sense for <extends>.
> > In our POC you can "import" with <use> mode the same file with different
> > prefix. exemple :
> > <project name="Abstract-Module">
> > ...
> > </project>
> >
> > <project name="Concret-Module1">
> > <use file="Abstract-Module" as "AbstractModuleConcret1"/>
> > ...
> > </project>
> >
> > <project name="Concret-Module2">
> > <use file="Abstract-Module" as "AbstractModuleConcret2"/>
> > ...
> > </project>
> >
> > <project name="genericBuild">
> > <extends file="Concret-Module1"/>
> > <extends file="Concret-Module2"/>
> > </project>
>
> What I've argued before is that the 'as' attribute used by a build
> should only be visible to that build. Any other build that uses it
> (English meaning of use :) should not be aware of this attribute. This
> way both Concrete-Model1 and 2 can use the same as, and it's
> genericBuild that's then forced to use two different 'as' attributes
> for them to be able to distinguish them.
>
> It's analogs to Java's inheritance, where a derived class can only
> refer explicitly to its direct parent's methods, and not any of its
> ancestors (like in C++). In other words, you can only bypass the
> normal virtual dispatch of method if it's a method of your parent.
>
> There's no reason for genericBuild to directly reference
> Abstract-Module. Abstract-Module basically became "part-of"
> Concret-Module1 and 2, and is invisible to genericBuild, unless
> genericBuild also directly import/includes it.
>
> Failing to do this, you couldn't safely refactor Concrete-Module1 and
> 2, without possibly breaking genericBuild.
I think this is a good idea, even if i have no idea of how to implement it.
Maybe we can improve "target visibility" (something close to private /
public).
Project help should be able to display "public" target of a given submodule.
>
>
> Ah, it looks to me that I'm again failing to get my view across. Since
> I'm no longer actively using Ant like I used to, I'll take a step back
> and stop arguing the above points, which are probably incompatible
> with the (simplistic?) way Ant deals with import and target addressing
> (by simple prefixing).
I'm really interested by your point of view :), maybe because you seems to
be on of those who tries to "faire avancer le schmilblick" comme on dis chez
nous ;)
> - <use> is like a "Rich" <import> that support namespace and that allow
> > you to import many time the same build script with different namespace.
>
> And I thought use was like an include ;) i.e. less than import, while
> it's actually more. --DD
Re: EasyAnt
Posted by Dominique Devienne <dd...@gmail.com>.
On Mon, Nov 10, 2008 at 10:16 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Right now I'm pretty close to simply add an "as" attribute to import,
> add "include" as an alias name for import and make the task behave
> differently when it is called as include. This should address all
> EasyAnt uses (except for the names) and we may be able to further
> evolve from there.
Sounds great Stefan. Cheers, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Ooops i forgot "ignoring" prefix should ignore also prefix separator
2008/11/12 Jean-Louis BOUDART <je...@gmail.com>
> Maybe this should be done with a additional attribute like :
> - ignorePrefix
> - disablePrefix
>
> something like
> <import file="..." disablePrefix="true"/>
>
> WDYT?
>
>
> 2008/11/12 Jean-Louis BOUDART <je...@gmail.com>
>
>> Ooops my bad, i've merged with my previous patch :$
>> This is now fixed in:
>>
>> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
>>
>> The patch contains only things related to phases concept.
>>
>> In addition to this, i think that we should add a way to disable
>> prefixing, i have a use case in easyant where i don't want to use prefix.
>> In the patch i removed this control:
>> if (configuredValue != null && configuredValue.length() == 0) {
>> configuredValue = null;
>> }
>>
>> This allow me to have a dirty fix to import a build script without prefix
>> :) by setting as attribute to an empty string (<import file="..." as=""/>).
>>
>>
>>
>>
>> 2008/11/12 Stefan Bodewig <bo...@apache.org>
>>
>>> On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>>>
>>> > EasyAnt switched to ant-713373
>>>
>>> > Every things seems ok, except prefix separator should be applied on
>>> targets
>>> > (ie. in targetHelper) too.
>>>
>>> >
>>> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
>>>
>>> Both places where your patch replaces "." with prefixSeparator (line
>>> 861 and line 888 of the original) are correct in svn, you must be
>>> using some inconsistent state since your patch won't apply.
>>>
>>> I'm a bit puzzled since I never committed a version that had
>>> prefixSeparator only in one place but not the other two.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>
>
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Maybe this should be done with a additional attribute like :
- ignorePrefix
- disablePrefix
something like
<import file="..." disablePrefix="true"/>
WDYT?
2008/11/12 Jean-Louis BOUDART <je...@gmail.com>
> Ooops my bad, i've merged with my previous patch :$
> This is now fixed in:
>
> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
>
> The patch contains only things related to phases concept.
>
> In addition to this, i think that we should add a way to disable prefixing,
> i have a use case in easyant where i don't want to use prefix.
> In the patch i removed this control:
> if (configuredValue != null && configuredValue.length() == 0) {
> configuredValue = null;
> }
>
> This allow me to have a dirty fix to import a build script without prefix
> :) by setting as attribute to an empty string (<import file="..." as=""/>).
>
>
>
>
> 2008/11/12 Stefan Bodewig <bo...@apache.org>
>
>> On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>>
>> > EasyAnt switched to ant-713373
>>
>> > Every things seems ok, except prefix separator should be applied on
>> targets
>> > (ie. in targetHelper) too.
>>
>> >
>> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
>>
>> Both places where your patch replaces "." with prefixSeparator (line
>> 861 and line 888 of the original) are correct in svn, you must be
>> using some inconsistent state since your patch won't apply.
>>
>> I'm a bit puzzled since I never committed a version that had
>> prefixSeparator only in one place but not the other two.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Swich done, everything works perfectly
I like how you've documented it :)
I've updated the patch (now it contains only phases features)
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713748-easyant-patch.diff
Thanks again for this integration
2008/11/13 Stefan Bodewig <bo...@apache.org>
>
> >> should help your caae. It isn's a complete fix since the prefix for
> >> included files without "as" doesn't get set before the first target
> >> (if any) is encountered.
>
> The "complete fix" should be revision 713745.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
>> should help your caae. It isn's a complete fix since the prefix for
>> included files without "as" doesn't get set before the first target
>> (if any) is encountered.
The "complete fix" should be revision 713745.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
> >> by typing ant -p i can see
> >> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
> i
> >> like to compile java classes :)
> >> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> > This is what I get with Ant trunk:
>
> > $ ./build.sh -f ../../Temp/u.xml -p
> > Buildfile: c:\Temp\u.xml
>
> > Main targets:
>
> > compile.iLikeToCompileJavaClasses i like to compile java classes :)
> > myPrefix.plop foo bar
>
> unless I add an empty target to build-std-java in front of the
> includes. If I do, I get the same prefixed names that you get.
ok :)
So what is the expected behavior for prefix nesting?
>
> From my reading of what you expect it should be
>
> * <import> import doesn't contribute to the prefix of <include>d files
> at all
except if we explicitly give an "as" attribute for <import>
>
> * <include>s stack up to make a longer prefix
>
> Is this independent of whether the as asstribute (for either of the
> tasks) has been specified?
>
> Is there some rationale that makes the rules easy to memorize and
> document?
While using nested <include>, stack up to make a longer prefix (the value of
the as attribute or the imported project's name attribute, if any).
<import> doesn't contribute to the prefix of <include>d files at all except
if we explicitly give an "as" attribute for <import>.
>
>
> If my assumptions are correct then
>
> private String getTargetPrefix(AntXMLContext context) {
> String configuredValue = getCurrentTargetPrefix();
> if (configuredValue != null && configuredValue.length() == 0) {
> configuredValue = null;
> }
> if (configuredValue != null) {
> return configuredValue;
> }
>
> String projectName = context.getCurrentProjectName();
> if ("".equals(projectName)) {
> projectName = null;
> }
>
> + if (context.isIgnoringProjectTag() && isInIncludeMode()) {
> // help nested include tasks
> if (projectName != null) {
> setCurrentTargetPrefix(projectName);
> }
> + }
>
> return projectName;
>
> should help your caae. It isn's a complete fix since the prefix for
> included files without "as" doesn't get set before the first target
> (if any) is encountered.
Seems to work, thanks
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
> Here it is i'm <import>ing a file that has no explicit "as" prefix.
> So calling to (prefix = getTargetPrefix(context)) will return the imported
> project's name.
For the <imported> file's targets and only as an additional name, they
should have been added without prefix a few lines above.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
> > It seems to be related to this test
> > if (!isInIncludeMode && context.isIgnoringProjectTag()
>
> means ProjectHelper is currently <import>ing a file
>
> > && (prefix = getTargetPrefix(context)) != null
>
> and there is a prefix defined for the imported file (either an
> explicit "as" prefix or the imported project's name attribute)
Here it is i'm <import>ing a file that has no explicit "as" prefix.
So calling to (prefix = getTargetPrefix(context)) will return the imported
project's name.
That's why i'm entering into the body of this test
>
>
> > && !isPhase) {
>
> Don't know how phase is supposed to factor into this.
>
> The body of that expression adds a prefixed target in addition to the
> non-prefixed target
>
> Adding yet another condition should make the body get executed less
> often, so I don't see why you should get a prefix if you make the body
> less likely to be executed.
>
> Is there a similar additional condition to the place where the
> unprefixed targets are added?
Nop :'(
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
> It seems to be related to this test
> if (!isInIncludeMode && context.isIgnoringProjectTag()
means ProjectHelper is currently <import>ing a file
> && (prefix = getTargetPrefix(context)) != null
and there is a prefix defined for the imported file (either an
explicit "as" prefix or the imported project's name attribute)
> && !isPhase) {
Don't know how phase is supposed to factor into this.
The body of that expression adds a prefixed target in addition to the
non-prefixed target
Adding yet another condition should make the body get executed less
often, so I don't see why you should get a prefix if you make the body
less likely to be executed.
Is there a similar additional condition to the place where the
unprefixed targets are added?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
> Refering to the comment
> // In an imported file (and not completely ignoring the project tag
> *OR*having a preconfigured prefix)
> this test should be like this instead
> if (!isInIncludeMode && !isPhase && (context.isIgnoringProjectTag()
> || (prefix = getTargetPrefix(context)) != null)) {
No.
!isInIncludeMode means "either the main build file or <import>ing a
file"
context.isIgnoringProjectTag() means "either <include>ing or
<import>ing"
so anding those two is the "In an imported file" part of the comment
(prefix = getTargetPrefix(context)) != null covers both branches of
the OR in "not completely ignoring the project tag OR having a
preconfigured prefix" since it will either return the configured
prefix or the <project>'s name attribute.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Refering to the comment
// In an imported file (and not completely ignoring the project tag
*OR*having a preconfigured prefix)
this test should be like this instead
if (!isInIncludeMode && !isPhase && (context.isIgnoringProjectTag()
|| (prefix = getTargetPrefix(context)) != null)) {
Maybe i'm getting wrong
2008/11/13 Jean-Louis BOUDART <je...@gmail.com>
> It seems to be related to this test
> if (!isInIncludeMode && context.isIgnoringProjectTag()
> && (prefix = getTargetPrefix(context)) != null && !isPhase)
> {
>
> But i don't understand why yet :(
>
> Any idea?
>
> 2008/11/13 Stefan Bodewig <bo...@apache.org>
>
>> On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
>>
>>
>> > I'll try to give you details
>>
>> [snip - removed <import phase since you didn't give the file]
>>
>> > by typing ant -p i can see
>> > org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
>> i
>> > like to compile java classes :)
>> > org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>>
>> This is what I get with Ant trunk:
>>
>> $ ./build.sh -f ../../Temp/u.xml -p
>> Buildfile: c:\Temp\u.xml
>>
>> Main targets:
>>
>> compile.iLikeToCompileJavaClasses i like to compile java classes :)
>> myPrefix.plop foo bar
>>
>> This seems to be what you want, I just don't understand why your
>> result may be different. Could you please do a diff between your
>> ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
>> missed/modified some part of trunk that is not related to phases.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
It seems to be related to this test
if (!isInIncludeMode && context.isIgnoringProjectTag()
&& (prefix = getTargetPrefix(context)) != null && !isPhase)
{
But i don't understand why yet :(
Any idea?
2008/11/13 Stefan Bodewig <bo...@apache.org>
> On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
> > I'll try to give you details
>
> [snip - removed <import phase since you didn't give the file]
>
> > by typing ant -p i can see
> > org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
> > like to compile java classes :)
> > org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> This is what I get with Ant trunk:
>
> $ ./build.sh -f ../../Temp/u.xml -p
> Buildfile: c:\Temp\u.xml
>
> Main targets:
>
> compile.iLikeToCompileJavaClasses i like to compile java classes :)
> myPrefix.plop foo bar
>
> This seems to be what you want, I just don't understand why your
> result may be different. Could you please do a diff between your
> ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
> missed/modified some part of trunk that is not related to phases.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
>> I'll try to give you details
> [snip - removed <import phase since you didn't give the file]
>> by typing ant -p i can see
>> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
>> like to compile java classes :)
>> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
> This is what I get with Ant trunk:
> $ ./build.sh -f ../../Temp/u.xml -p
> Buildfile: c:\Temp\u.xml
> Main targets:
> compile.iLikeToCompileJavaClasses i like to compile java classes :)
> myPrefix.plop foo bar
unless I add an empty target to build-std-java in front of the
includes. If I do, I get the same prefixed names that you get.
So what is the expected behavior for prefix nesting?
>From my reading of what you expect it should be
* <import> import doesn't contribute to the prefix of <include>d files
at all
* <include>s stack up to make a longer prefix
Is this independent of whether the as asstribute (for either of the
tasks) has been specified?
Is there some rationale that makes the rules easy to memorize and
document?
If my assumptions are correct then
private String getTargetPrefix(AntXMLContext context) {
String configuredValue = getCurrentTargetPrefix();
if (configuredValue != null && configuredValue.length() == 0) {
configuredValue = null;
}
if (configuredValue != null) {
return configuredValue;
}
String projectName = context.getCurrentProjectName();
if ("".equals(projectName)) {
projectName = null;
}
+ if (context.isIgnoringProjectTag() && isInIncludeMode()) {
// help nested include tasks
if (projectName != null) {
setCurrentTargetPrefix(projectName);
}
+ }
return projectName;
should help your caae. It isn's a complete fix since the prefix for
included files without "as" doesn't get set before the first target
(if any) is encountered.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Jean-Louis BOUDART <je...@gmail.com> wrote:
> I'll try to give you details
[snip - removed <import phase since you didn't give the file]
> by typing ant -p i can see
> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
> like to compile java classes :)
> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
This is what I get with Ant trunk:
$ ./build.sh -f ../../Temp/u.xml -p
Buildfile: c:\Temp\u.xml
Main targets:
compile.iLikeToCompileJavaClasses i like to compile java classes :)
myPrefix.plop foo bar
This seems to be what you want, I just don't understand why your
result may be different. Could you please do a diff between your
ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
missed/modified some part of trunk that is not related to phases.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
I'm using <import>, but it seems that aliases are also applied on <import> i
thought it was what you were excepecting. In our first patch <import> was'nt
prefixed.
I'll try to give you details
<project name="userBuild">
<import file="build-std-java"/>
</project>
<project name="org.apache.easyant#build-std-java">
<import file="phase"/>
<include file="compile-java" as="compile"/>
...
<include file="whatever" as"myPrefix"/>
</project>
<project name="org.apache.easyant#compile-java">
<target name="iLikeToCompileJavaClasses" description="i like to compile java
classes :)"/>
</project>
<project name="org.apache.easyant#whatever">
<target name="plop" description="foo bar"/>
</project>
by typing ant -p i can see
org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
like to compile java classes :)
org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
As you can see it seems that even using <import> without as attribute, it
seems that my <import> has been prefixed with ant project name.
In my case i want to see build-std-java target as if it was my current build
script (ie without prefix) :
compile.iLikeToCompileJavaClasses --> i like to compile java classes :)
myPrefix.plop --> foo bar
2008/11/13 Stefan Bodewig <bo...@apache.org>
> On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
> > In addition to this, i think that we should add a way to disable
> prefixing,
> > i have a use case in easyant where i don't want to use prefix.
>
> Why don't you use <import> instead of <include> in that case?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
> In addition to this, i think that we should add a way to disable prefixing,
> i have a use case in easyant where i don't want to use prefix.
Why don't you use <import> instead of <include> in that case?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Ooops my bad, i've merged with my previous patch :$
This is now fixed in:
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
The patch contains only things related to phases concept.
In addition to this, i think that we should add a way to disable prefixing,
i have a use case in easyant where i don't want to use prefix.
In the patch i removed this control:
if (configuredValue != null && configuredValue.length() == 0) {
configuredValue = null;
}
This allow me to have a dirty fix to import a build script without prefix :)
by setting as attribute to an empty string (<import file="..." as=""/>).
2008/11/12 Stefan Bodewig <bo...@apache.org>
> On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
> > EasyAnt switched to ant-713373
>
> > Every things seems ok, except prefix separator should be applied on
> targets
> > (ie. in targetHelper) too.
>
> >
> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
>
> Both places where your patch replaces "." with prefixSeparator (line
> 861 and line 888 of the original) are correct in svn, you must be
> using some inconsistent state since your patch won't apply.
>
> I'm a bit puzzled since I never committed a version that had
> prefixSeparator only in one place but not the other two.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
> EasyAnt switched to ant-713373
> Every things seems ok, except prefix separator should be applied on targets
> (ie. in targetHelper) too.
> http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Both places where your patch replaces "." with prefixSeparator (line
861 and line 888 of the original) are correct in svn, you must be
using some inconsistent state since your patch won't apply.
I'm a bit puzzled since I never committed a version that had
prefixSeparator only in one place but not the other two.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
EasyAnt switched to ant-713373
Every things seems ok, except prefix separator should be applied on targets
(ie. in targetHelper) too.
Here is the patch that include phase concept + the quick fix to prefix
separator :
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Thanks a lot Stefan !
2008/11/12 Stefan Bodewig <bo...@apache.org>
> On 2008-11-12, Stefan Bodewig <bo...@apache.org> wrote:
>
> > On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
> >> I think that using "<include>" should allow user to have nested prefix,
>
> > should be pretty easy to fix and it makes some sense in the include
> > case.
>
> >> In addition to this, could it be possible to have a parametrized prefix
> >> separator?
>
> > Yep. It will need yet another modification to ProjectHelper for the
> > case where no as attribute has been given and we use the project name,
> > but still is pretty straight forward to do.
>
> Both have been added in revision 713373.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-12, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
>> I think that using "<include>" should allow user to have nested prefix,
> should be pretty easy to fix and it makes some sense in the include
> case.
>> In addition to this, could it be possible to have a parametrized prefix
>> separator?
> Yep. It will need yet another modification to ProjectHelper for the
> case where no as attribute has been given and we use the project name,
> but still is pretty straight forward to do.
Both have been added in revision 713373.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-12, Jean-Louis BOUDART <je...@gmail.com> wrote:
> I'm currently trying to switch to trunk Head revision and i'm getting some
> troubles with "nested inclusion".
> I think that using "<include>" should allow user to have nested prefix,
Sorry, I missed that part when I looked over you patch, should be
pretty easy to fix and it makes some sense in the include case.
It should probably be limited to <include>, though, since <import>
goes all the way to non-prefixed. I'm not totally sure.
> In addition to this, could it be possible to have a parametrized prefix
> separator?
Yep. It will need yet another modification to ProjectHelper for the
case where no as attribute has been given and we use the project name,
but still is pretty straight forward to do.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Hi Stefan,
First of all i would like to thank you for your interests on our patch.
I'm currently trying to switch to trunk Head revision and i'm getting some
troubles with "nested inclusion".
I think that using "<include>" should allow user to have nested prefix, here
is a short example:
<project name="abstract">
<target name="myAbstractTarget" description="i'm abstract">
...
</target>
</project>
<project name="A">
<include file="abstact" as="myPrefix"/>
<target name="mySpecificTargetFromA" depends="myPrefix.myAbstractTarget"
description="i'm A">
...
</target>
</project>
<project name="B">
<include file="A" as="iLikeNestedPrefix"/>
<target name="mySpecificTargetFromB"
depends="iLikeNestedPrefix.mySpecificTargetFromA" description="i'm B">
...
</target>
</project>
<project name="generic build>
<extends file="B"/>
</project>
By typing ant -p i should see something like :
B.mySpecificTargetFromB --> i'm B
B.iLikeNestedPrefix.mySpecificTargetFromA --> i'm A
B.iLikeNestedPrefix.myPrefix.myAbstractTarget --> i'm abstract
In our previous patch it was done by ImportTask (
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-697121-easyant-patch.diffl168->l187)
What do you think about it?
In addition to this, could it be possible to have a parametrized prefix
separator? I guess you've added a "." betwen prefix and target name (ex:
myPrefix.myTarget), could we have something more flexible?
In EasyAnt, we currently don't want to have a prefix separator, by
conventions our public target are prefixed with ":" and our private target
are prefixed with "-".
Thanks in advance for your feedback.
2008/11/11 Stefan Bodewig <bo...@apache.org>
> On 2008-11-10, Stefan Bodewig <bo...@apache.org> wrote:
>
> > Right now I'm pretty close to simply add an "as" attribute to import,
> > add "include" as an alias name for import and make the task behave
> > differently when it is called as include.
>
> Done.
>
> The implementation differs from EasyAnt's and we don't have phases
> (yet?), so Jean-Lousi or Xavier should either modify the patch or tell
> people to now use Ant trunk more recent than 713006.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-10, Stefan Bodewig <bo...@apache.org> wrote:
> Right now I'm pretty close to simply add an "as" attribute to import,
> add "include" as an alias name for import and make the task behave
> differently when it is called as include.
Done.
The implementation differs from EasyAnt's and we don't have phases
(yet?), so Jean-Lousi or Xavier should either modify the patch or tell
people to now use Ant trunk more recent than 713006.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-06, Dominique Devienne <dd...@gmail.com> wrote:
> What I've argued before is that the 'as' attribute used by a build
> should only be visible to that build. Any other build that uses it
> (English meaning of use :) should not be aware of this attribute. This
> way both Concrete-Model1 and 2 can use the same as, and it's
> genericBuild that's then forced to use two different 'as' attributes
> for them to be able to distinguish them.
While I do understand what you mean (and AFAIR I simply dropped out of
any import discussion when it was added, so I don't remember whether I
understood your point then), but as you note yourself, this probably
is incompatible with the way <import> works today.
If we wanted to add it, we'd need a more complex change and an
attribute to explicitly enable that behavior. I'm not saying that it
couldn't be done, it's just more work.
Right now I'm pretty close to simply add an "as" attribute to import,
add "include" as an alias name for import and make the task behave
differently when it is called as include. This should address all
EasyAnt uses (except for the names) and we may be able to further
evolve from there.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Nov 6, 2008 at 4:42 AM, Jean-Louis BOUDART
<je...@gmail.com> wrote:
> I'm not sure that adding an as-attribute make sense for <extends>.
> In our POC you can "import" with <use> mode the same file with different
> prefix. exemple :
> <project name="Abstract-Module">
> ...
> </project>
>
> <project name="Concret-Module1">
> <use file="Abstract-Module" as "AbstractModuleConcret1"/>
> ...
> </project>
>
> <project name="Concret-Module2">
> <use file="Abstract-Module" as "AbstractModuleConcret2"/>
> ...
> </project>
>
> <project name="genericBuild">
> <extends file="Concret-Module1"/>
> <extends file="Concret-Module2"/>
> </project>
What I've argued before is that the 'as' attribute used by a build
should only be visible to that build. Any other build that uses it
(English meaning of use :) should not be aware of this attribute. This
way both Concrete-Model1 and 2 can use the same as, and it's
genericBuild that's then forced to use two different 'as' attributes
for them to be able to distinguish them.
It's analogs to Java's inheritance, where a derived class can only
refer explicitly to its direct parent's methods, and not any of its
ancestors (like in C++). In other words, you can only bypass the
normal virtual dispatch of method if it's a method of your parent.
There's no reason for genericBuild to directly reference
Abstract-Module. Abstract-Module basically became "part-of"
Concret-Module1 and 2, and is invisible to genericBuild, unless
genericBuild also directly import/includes it.
Failing to do this, you couldn't safely refactor Concrete-Module1 and
2, without possibly breaking genericBuild.
Ah, it looks to me that I'm again failing to get my view across. Since
I'm no longer actively using Ant like I used to, I'll take a step back
and stop arguing the above points, which are probably incompatible
with the (simplistic?) way Ant deals with import and target addressing
(by simple prefixing).
> - <use> is like a "Rich" <import> that support namespace and that allow
> you to import many time the same build script with different namespace.
And I thought use was like an include ;) i.e. less than import, while
it's actually more. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Jean-Louis BOUDART <je...@gmail.com>.
> > IIUC EasyAnt solits the two use-cases found for <import> into two
> > > logical tasks.
> > >
> > > * you never want to override a target, you just want to reuse them:
> <use>
> >
> > That's an <include> to me. Rename <use> into <include>, and I'm +1,
>
> I'm not bound to names.
+1 =)
>> I'm not totally sure whether the as-attribute would make sense for
> >> <extends> as well, EasyAnt currently silently ignores it in that case.
> >
> > It makes as much sense in <import> as it does in <include> to me, i.e.
> > to restore proper compartmentalization of the builds.
>
> I'd probably want to allow it for symmetry as well, but I haven't
> thought through all implications.
I'm not sure that adding an as-attribute make sense for <extends>.
In our POC you can "import" with <use> mode the same file with different
prefix.
exemple :
<project name="Abstract-Module">
...
</project>
<project name="Concret-Module1">
<use file="Abstract-Module" as "AbstractModuleConcret1"/>
...
</project>
<project name="Concret-Module2">
<use file="Abstract-Module" as "AbstractModuleConcret2"/>
...
</project>
<project name="genericBuild">
<extends file="Concret-Module1"/>
<extends file="Concret-Module2"/>
</project>
I guess adding an as attribute on <extends> is like having only one import
mode where we can add prefix, and i'm not sure this is the solution.
IMHO we need those two kind of import:
- <extends> similar to the actual <import>
- <use> is like a "Rich" <import> that support namespace and that allow
you to import many time the same build script with different namespace.
That's why i think "as attribute" should be used only with <use>.
What do you think about it?
>
> > I don't think we should invent new terminology (use/extends) for
> > something that already exists (import) and it's natural equivalent to
> > use (include, which doesn't exist).
>
> Then we need to stretch the difference. Two new names would increas
> awareness that <import> does something special.
>
> > What's missing from the above is the notion of TargetGroup to
> > implement the phase concept of EasyAnt (and Maven I guess).
>
> True. To me those concepts are orthogonal and I'd like to have
> separate discussions on them (and picked this topic to be first).
Nice :)
Re: EasyAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 5 Nov 2008, Dominique Devienne <dd...@gmail.com> wrote:
> On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig <bo...@apache.org> wrote:
> > IIUC EasyAnt solits the two use-cases found for <import> into two
> > logical tasks.
> >
> > * you never want to override a target, you just want to reuse them: <use>
>
> That's an <include> to me. Rename <use> into <include>, and I'm +1,
I'm not bound to names.
> > EasyAnt also adds an as-attribute to <use> where the writer of the
> > importing build file can control the prefix of the <use>d targets and
> > overrules the <use>d project's name. This makes sense IMHO.
>
> It does to me too :)
>
>> I'm not totally sure whether the as-attribute would make sense for
>> <extends> as well, EasyAnt currently silently ignores it in that case.
>
> It makes as much sense in <import> as it does in <include> to me, i.e.
> to restore proper compartmentalization of the builds.
I'd probably want to allow it for symmetry as well, but I haven't
thought through all implications.
> I don't think we should invent new terminology (use/extends) for
> something that already exists (import) and it's natural equivalent to
> use (include, which doesn't exist).
Then we need to stretch the difference. Two new names would increas
awareness that <import> does something special.
> What's missing from the above is the notion of TargetGroup to
> implement the phase concept of EasyAnt (and Maven I guess).
True. To me those concepts are orthogonal and I'd like to have
separate discussions on them (and picked this topic to be first).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig <bo...@apache.org> wrote:
> IIUC EasyAnt solits the two use-cases found for <import> into two
> logical tasks.
>
> * you never want to override a target, you just want to reuse them: <use>
That's an <include> to me. Rename <use> into <include>, and I'm +1,
even with the forced prefix (from build file or @as) to included
targets.
> * you may want to override some/most targets: <extends>
That's the current <import> indeed.
> Technically <extends> is what <import> is today. <import>ed targets
> that haven't been overwritten in the main build are known under two
> names (prefixed and not prefixed) and the depends lists of the targets
> in the <extends>-imported file are not rewritten.
>
> Targets coming from a <use>d file only exist in their prefixed form
> and their dependencies are rewritten to include prefixes as well.
> I.e. you can not override the <use>d target's dependencies.
>
> There has been some confusion from time to time on the user list as to
> how you can ensure you get "your" target and not an overwritten one in
> an imported file, so I think <use> is useful outside of EasyAnt as
> well.
>
> EasyAnt also adds an as-attribute to <use> where the writer of the
> importing build file can control the prefix of the <use>d targets and
> overrules the <use>d project's name. This makes sense IMHO.
It does to me too :)
> I'm not totally sure whether the as-attribute would make sense for
> <extends> as well, EasyAnt currently silently ignores it in that case.
It makes as much sense in <import> as it does in <include> to me, i.e.
to restore proper compartmentalization of the builds.
> Changes would be required to the import task as well as to
> ProjectHelper2 (the specific patch also patches AntXMLContext and
> ProjectHelper, but that may turn out to be not necessary. It's an
> implementation detail).
>
> Opinions?
I don't think we should invent new terminology (use/extends) for
something that already exists (import) and it's natural equivalent to
use (include, which doesn't exist). The import/include difference
already exists in XSLT. It's not that import/include is *better* than
use/extends, it's that they are a fairly well known precedent,
especially given that we already have import in Ant.
What's missing from the above is the notion of TargetGroup to
implement the phase concept of EasyAnt (and Maven I guess). Although
it's possible to tack this on to Target, having a separate class to
model this would be better IMHO.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org