On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] 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 :)
It seems to be related to this test
if (!isInIncludeMode context.isIgnoringProjectTag()
means ProjectHelper is currently importing a file
(prefix = getTargetPrefix(context)) != null
and there is a prefix defined for the imported file (either an
explicit as prefix or
On 2008-11-13, Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] 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
On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] 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()
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)) {
On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
It seems to be related to this test
if (!isInIncludeMode context.isIgnoringProjectTag()
means ProjectHelper is currently importing a file
(prefix = getTargetPrefix(context)) != null
and there is a prefix defined
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:
On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
Here it is i'm importing 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
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
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 [EMAIL
On 2008-11-12, Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] 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
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 :
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] 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
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
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
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] 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,
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 [EMAIL PROTECTED]
Ooops my bad, i've merged with my previous patch :$
This is now fixed in:
Ooops i forgot ignoring prefix should ignore also prefix separator
2008/11/12 Jean-Louis BOUDART [EMAIL PROTECTED]
Maybe this should be done with a additional attribute like :
- ignorePrefix
- disablePrefix
something like
import file=... disablePrefix=true/
WDYT?
2008/11/12
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] 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
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
On 2008-11-10, Stefan Bodewig [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
On 2008-11-06, Dominique Devienne [EMAIL PROTECTED] 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
On Mon, Nov 10, 2008 at 10:16 AM, Stefan Bodewig [EMAIL PROTECTED] 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
On Wed, 5 Nov 2008, Dominique Devienne [EMAIL PROTECTED] wrote:
On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig [EMAIL PROTECTED] 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
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
On Thu, Nov 6, 2008 at 4:42 AM, Jean-Louis BOUDART
[EMAIL PROTECTED] 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
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
On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig [EMAIL PROTECTED] 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
29 matches
Mail list logo
