subject:"Re\: ant 1.5.4 \: Import"

On Tue, 29 Jul 2003 05:15 am, Antoine Levy-Lambert wrote:
 Now we need someone (Conor ?) to decide in which order these different
 points are going to be added to our code.
 (Like what is happening for antlib).

No, we all get to decide :-). I have but one vote.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
 I agree that ${basedir} should be the value of basedir for the main
 buildfile being executed. But what I think is necessary is to have
 access to the basedirs of the imported file in a systematic, deterministic
 and conflict free way. I do not think we need some special importdir
 what we need is ${basedir.importedprojectname} and so on. This properties
 will point to the where the local basedir for that local file is suppose to
 be.


I think this is all getting too complex for import. What you are describing 
is project composition where each project maintains its own context, its own 
basedir, etc. This can be done separately from import. We have discussed 
this in the past as projectref.

In fact I would like to rename import as include to reinforce the fact 
that this is its primary function. In fact the problems we are seeing with 
import all come because it tries to do two things beyond a simple #include 
operation - target renaming and allowing imports to access resources 
according to their import file location.

The problem with import is that it flattens a hierarchy of project files 
into a single project but tries to preserve some of the hierarchy based on 
project names. Having multiple basedirs, ${basedir.X}, [EMAIL PROTECTED], 
partially 
visible targets, etc is just a whole load of complexity for very little 
benefit, IMHO. 

If you want a hierarchy of projects, do that separately. If you maintain the 
hierarchy in separate project instances, you eliminate all the name clashes, 
etc.

So baed on discussions so far, my proposal would be:

1. import with optional name. The name is to be used in the renaming of 
targets.

2. Define a single property ant.import.file which is resolved at import time 
to the import location. All other properties are nt resolved.

3. All containers are projects for IDE compatibility. Note, however, that 
there will be some build files, designed to be imported, which will not be 
valid standal;ong build files - e.g. their targets may depend on non-existent 
targets which the importer is to provide.

4. All normal Ant operations (i.e. not imports) are resolved to the basedir of 
the outer project. There is no access to other basedirs.

5. Import specs are relative to importing file location. Don't use href as it 
creates expectations of a URL which opens up issues.

6. An attribute may be added to the project element to mark a build file as 
not importable.

Keep is Simple.

Conor




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Nicola Ken Barozzi

Conor MacNeill wrote, On 29/07/2003 1.23:
On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
I agree that ${basedir} should be the value of basedir for the main
buildfile being executed. But what I think is necessary is to have
access to the basedirs of the imported file in a systematic, deterministic
and conflict free way. I do not think we need some special importdir
what we need is ${basedir.importedprojectname} and so on. This properties
will point to the where the local basedir for that local file is suppose to
be.
I think this is all getting too complex for import. What you are describing 
is project composition where each project maintains its own context, its own 
basedir, etc. 
AFAIK this is done with ant
This can be done separately from import. We have discussed 
this in the past as projectref.
Hmmm, I'll look in the archives.
In fact I would like to rename import as include to reinforce the fact 
that this is its primary function. In fact the problems we are seeing with 
import all come because it tries to do two things beyond a simple #include 
operation - target renaming and allowing imports to access resources 
according to their import file location.
That was thought about, but then I looked in the XSLT spec, and import 
seems to look more like it. And it's similar to Java imports.

The problem with import is that it flattens a hierarchy of project files 
into a single project but tries to preserve some of the hierarchy based on 
project names. Having multiple basedirs, ${basedir.X}, [EMAIL PROTECTED], partially 
visible targets, etc is just a whole load of complexity for very little 
benefit, IMHO. 
Are you talking about the current version or the proposals? IMHO the 
current version simple includes with a bit of target name rewriting.

If you want a hierarchy of projects, do that separately. If you maintain the 
hierarchy in separate project instances, you eliminate all the name clashes, 
etc.
Import is not made to make hierarchies of projects. It's made to include 
buildfile snippets and utility finctions, not hierarchical buildfiles.

So based on discussions so far, my proposal would be:
1. import with optional name. The name is to be used in the renaming of 
targets.
+1  Similar to current bahaviour.
2. Define a single property ant.import.file which is resolved at import time 
to the import location. All other properties are nt resolved.
+1 as now
3. All containers are projects for IDE compatibility. Note, however, that 
there will be some build files, designed to be imported, which will not be 
valid standal;ong build files - e.g. their targets may depend on non-existent 
targets which the importer is to provide.
+1 as now
4. All normal Ant operations (i.e. not imports) are resolved to the basedir of 
the outer project. There is no access to other basedirs.
+1 as now
5. Import specs are relative to importing file location. Don't use href as it 
creates expectations of a URL which opens up issues.
+1 as now
6. An attribute may be added to the project element to mark a build file as 
not importable.
+1 Similar to current behaviour.
So basically add:
import file= prefix=/
   ^
and
project importable=true||false||[undefined]/
^
Keep is Simple.
The current version is in fact made to minimize changes and keep it very 
simple, and it seems that you are coming too to my conclusions.

The problem, as you correctly note, is not about import per se, but 
about false expectations that people try to realize with it.

My question is: what are users trying to do with it that is not in his 
scope and cannot be done with ant?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
 
  I think this is all getting too complex for import. What you are
  describing is project composition where each project maintains its own
  context, its own basedir, etc.

 AFAIK this is done with ant


Not quite the same. projectref allowed the projects to be running in 
tandem and for dependencies to exist beteween the projects. e.g.

projectref file=blah.xml ref=blah/

target name=test depends=blah:init
  javac srcdir=${blah:src.dir}/
/target

Syntax et al up for grabs but still very different from ant

  In fact I would like to rename import as include to reinforce the
  fact that this is its primary function. In fact the problems we are
  seeing with import all come because it tries to do two things beyond a
  simple #include operation - target renaming and allowing imports to
  access resources according to their import file location.

 That was thought about, but then I looked in the XSLT spec, and import
 seems to look more like it. And it's similar to Java imports.


import is closer to C #include than java import.

  The problem with import is that it flattens a hierarchy of project
  files into a single project but tries to preserve some of the hierarchy
  based on project names. Having multiple basedirs, ${basedir.X},
  [EMAIL PROTECTED], partially visible targets, etc is just a whole load of
  complexity for very little benefit, IMHO.


 The current version is in fact made to minimize changes and keep it very
 simple, and it seems that you are coming too to my conclusions.

 The problem, as you correctly note, is not about import per se, but
 about false expectations that people try to realize with it.


Yes. I am arguing for the current import with some limited changes.

 My question is: what are users trying to do with it that is not in his
 scope and cannot be done with ant?

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Nicola Ken Barozzi

Conor MacNeill wrote, On 29/07/2003 9.15:
On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
I think this is all getting too complex for import. What you are
describing is project composition where each project maintains its own
context, its own basedir, etc.
AFAIK this is done with ant
Not quite the same. projectref allowed the projects to be running in 
tandem and for dependencies to exist beteween the projects. e.g.

projectref file=blah.xml ref=blah/
target name=test depends=blah:init
  javac srcdir=${blah:src.dir}/
/target
Syntax et al up for grabs but still very different from ant
Ah, ok, now I get it, thanks :-)
Basically it's an ant file that exposes targets and properties.
Given this, I understand the proposal of making:
  import - include
  projectref - import
although I'm personally +-0 on either denomination.
But is the above not overlapping with Gump?
Personally, I don't see the real need for it, as the same can be done 
with correctly-written @importable files. In the specific, init values 
should be included rather than imported.

Can you point me to some relevant use-cases?
TIA
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

2003-07-29 Thread Jose Alberto Fernandez

 From: Conor MacNeill [mailto:[EMAIL PROTECTED]
 
 I think this is all getting too complex for import. What 
 you are describing 
 is project composition where each project maintains its own 
 context, its own 
 basedir, etc. This can be done separately from import. We 
 have discussed 
 this in the past as projectref.
 
 In fact I would like to rename import as include to 
 reinforce the fact 
 that this is its primary function. In fact the problems we 
 are seeing with 
 import all come because it tries to do two things beyond a 
 simple #include 
 operation - target renaming and allowing imports to access resources 
 according to their import file location.
 

Is import to support target overriding? If it does, then
we are talking about import if it does not (i.e., targets in 
importing and imported files with same name causes ERROR) then
we are talking about include.

 The problem with import is that it flattens a hierarchy of 
 project files 
 into a single project but tries to preserve some of the 
 hierarchy based on 
 project names. Having multiple basedirs, ${basedir.X}, 
 [EMAIL PROTECTED], partially 
 visible targets, etc is just a whole load of complexity for 
 very little 
 benefit, IMHO. 
 

As long as I have a way to specify relative imports I have no issue.

 
 1. import with optional name. The name is to be used in the 
 renaming of 
 targets.
 

Fine, but then this is not include it is import. :-)

 2. Define a single property ant.import.file which is resolved 
 at import time 
 to the import location. All other properties are nt resolved.
 

This one you need to explain better. What does it mean resolved at import time?
Can I mention this property inside a target of the imported file?
If I can, would it be set to the expected value when the target is later 
executed?

Otherwise, would the lifespan of the property be the import action itself?
That may mean the property will be set while executing top-level targets
And if I want to preserve the value I need to save if on my own properties.

If the otherwise is what you mean, then fine. But I would prefer having
the local basedir (or the file dir) because one usually need to refer
to other relative files and not to the build file itself. It makes no sense
to force users to do file arithmetic when it is not necessary.
(I vote for keeping ant.import.basedir) which applies all the basedir rules
as we have them today.

 4. All normal Ant operations (i.e. not imports) are resolved 
 to the basedir of 
 the outer project. There is no access to other basedirs.
 

With the caviat that during importing I can have access to
the ant.import.basedir and can save it on my own properties
if I need to.

 5. Import specs are relative to importing file location. 
 Don't use href as it 
 creates expectations of a URL which opens up issues.
 

Yes, that is fine. As long as I can say file=${basedir}/xyz (for
an import from the top) or file=${ant.import.basedir}/xyz (for an
import from the local basedir).

Imports can only be at top level, right?

 6. An attribute may be added to the project element to mark 
 a build file as 
 not importable.
 

I really do not see the need for this. It seem superfluous.
How many of you scan their disks for build.xml files to execute
without knowing what they do? 

 Keep is Simple.
 

Yes.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Stefan Bodewig

If you want to simplify things, why not go even further?

On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:

 1. import with optional name. The name is to be used in the renaming
 of targets.

I'd like to think about removing target renaming completely.  What
exactly is the use-case for this?  I've come up with a vague idea, but
it would help tremendously what people do want this feature for.

 2. Define a single property ant.import.file which is resolved at
 import time to the import location. All other properties are nt
 resolved.

Why does the imported/included file need to know its name, after we've
limited it to not access resources relative to its own basedir as in

 4. All normal Ant operations (i.e. not imports) are resolved to the
 basedir of the outer project. There is no access to other basedirs.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Stefan Bodewig

On Mon, 28 Jul 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:

 href should also support URLs But as DD pointed out, this is opening
 a pandora box.  If imported files are downloaded from an http server
 or from a jar file, there will be problems with properties, ...

I don't think I've understood this problem.  As only the outer file
has a basedir, property file=/ will be resolved to the basedir
of the outer file, no URLs involved.

 2) several components should be able to import the same build file
 ---
 (Alexey Solofnenko)
 proja.xml
 import projb.xml
 import projc.xml
 
 projb.xml and projc.xml must be allowed to import both common.xml
 for instance

Where is the problem?

 ProjectHelper2 is complaining about such situations currently

So it should be fixed.

If we wanted to allow overriding of targets but no target renaming at
all, we'd simply ignore all targets that are already there while
importing.

Top-level tasks will appear twice, with or without a name attribute.

 7) antreturn
 

Is not related to import.

We've dismissed any such patches in the past, which doesn't mean we'll
dismiss it again.  But we should keep the discussions separate in
order to get this one finished.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Nicola Ken Barozzi

Stefan Bodewig wrote, On 29/07/2003 12.59:
If you want to simplify things, why not go even further?
On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:
1. import with optional name. The name is to be used in the renaming
of targets.
I'd like to think about removing target renaming completely.  What
exactly is the use-case for this?  I've come up with a vague idea, but
it would help tremendously what people do want this feature for.
I thought I had already answered this?
Anyway, the need is that I have to be able to override a target I import.
For example, let's say I have a compile target I want to import, and I 
want to make it additionally call the pre target before and the post 
target after. This is a very common usecase that can make me reuse 
targets with minor adjustments case per case.

So, let's say that there is no renaming. To use the imported compile 
target I will have to make my mycompile target.

project
 import file=commontargets.xml/
 target name=mycompile depends=pre, compile, post/
 target name=pre
 /target
 target name=post
 /target
/project
Now all seems ok, just a minor issue that I cannot use compile but 
have to change name...

Then I want to run the test target that is in the imported buildfile.
Wait a sec, the test target in the imported buildfile is:
 target name=test depends=compile
 /target
But it won't work, as I need to call pre to be able to launch a compile!
There is no way out, I'm not able anymore to use an imported target.
In case of renaming, I can do:
project
 import file=commontargets.xml/
 target name=compile depends=pre, original.compile, post/
 target name=pre
 /target
 target name=post
 /target
/project
and test will work.
What renaming does is give me the possibility of decorating the imported 
targets, and effectively importing the dependency graph, not only the 
single targets.

This is a major feature of import.
2. Define a single property ant.import.file which is resolved at
import time to the import location. All other properties are nt
resolved.
Why does the imported/included file need to know its name, after we've
limited it to not access resources relative to its own basedir as in
It *has* to be able to access resources relative to it's position, else 
for most purposes it's useless.

The problem comes with the concept of basedir, as in normal buildfiles 
it references the path WRT which all paths are resolved. Here they are 
*not* resolved automatically, but the author can use to do it in a 
similar way by using the and file position.

It's the automaticity of this resolving that is the problem, and 
basedir is normally associated with it.

4. All normal Ant operations (i.e. not imports) are resolved to the
basedir of the outer project. There is no access to other basedirs.
If the above two features were missing, it would be almost of no use. 
And yes, in that case it would have to be called imclude.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-29 Thread Stefan Bodewig

On Tue, 29 Jul 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote:

 I thought I had already answered this?

quite possible.

 Anyway, the need is that I have to be able to override a target I
 import.

I don't think I like either the idea of of what you describe nor the
implementation.  I'd probably prefer a simple include without any
target overrides then.

Let's say I'm -0 on the feature as such and consequently won't stand
in the way of any implementation details with further questions.

 For example, let's say I have a compile target I want to import, and
 I want to make it additionally call the pre target before and the
 post target after.

Then you don't want to import the target but a different target IMHO.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote:
 Personally, I don't see the real need for it, as the same can be done
 with correctly-written @importable files. In the specific, init values
 should be included rather than imported.

 Can you point me to some relevant use-cases?


Ok, attached is a small test case which shows the failings of import when 
there are target name collisions. In this case the dependency of test to 
critical in b.xml is incorrectly replaced with a depenency on the 
critical target in a.xml. 

Target renaming doesn't help here. Having everything in a single project 
namespace remains a problem. I'd say the number of target name collisions 
between imported build files is going to be high because of the tendency to 
choose target names from a small pool of common names.

Conor

attachment: collision.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-28 Thread Antoine Levy-Lambert

I would like to summarize a number of ideas I have read concerning import.

1) attributes for the import task itself :
-

11) file
import file=a/b/common.xml/
=== import relative to the basedir of importing build file

12) href
(Peter Reilly)
import href=a/b/common.xml/
 import relative to the directory containing the importing build file.

href should also support URLs
But as DD pointed out, this is opening a pandora box.
If imported files are downloaded from an http server or from a jar file,
there will be problems with properties, ...

13) name
(Nicola Ken Barozzi and Dominique Devienne)
import file=blah.xml name=blah/
Give a name to the imported project
Useful to solve conflicts (see point 2)

2) several components should be able to import the same build file
---
(Alexey Solofnenko)
proja.xml
import projb.xml
import projc.xml

projb.xml and projc.xml must be allowed to import both common.xml for
instance

ProjectHelper2 is complaining about such situations currently

3) new attributes for project

there is a suggestion by Nicola Ken Barozzi to add
importable with the values true (meaning that the file can be imported) or
false(never imported).
if it is not mentioned then it is possible to import the build file with a
warning.

4) importable or fragment
--
Conor and others suggest a new top-level tag called
importable for files which are only meant to be imported
It sounds good, the only problem is that IDEs providing support to write ant
build files will not support creating these files immediately. The IDEs will
certainly catch up with that, but if we do this, in the first months build
file writers will need to write the files in basic editors

5) debate about what is the basedir of an imported file
--
can be :
- the basedir of the imported file
- base dir of importing file

I would go for :

- basedir of importing file if the imported file does not have a basedir
- basedir of imported file if the imported file has a basedir

6) magic attributes
--
there is already
ant.file.[project name] = location of the build file
 (see ProjectHelper2.java)
I think I saw someone asking for another magic attribute, but I cannot
remember which one ...

7) antreturn

this is not directly related, but there is a lot of value in the code
suggested by Dominique Devienne.
I am sure this addresses a need.

Now we need someone (Conor ?) to decide in which order these different
points are going to be added to our code.
(Like what is happening for antlib).

Cheers,

Antoine




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:

 Sure. Let me push the C/C++ analogy a little further.

Leaving this analogy aside ...

In the particular case you've mentioned (checkstyle.xml using
build.xml) I'm absolutely with Ken, farm out the common stuff and
import it from both.  Use composition instead of inheritance.

 The analogy with Ant breaks when we talk about target overriding
 which will be a useful usecase.

Yes, here we are talking about import as a method of inheritance, so
we are using the same task for two different concepts.  Maybe this is
the cause of confusion and should be amended by either using two
different tasks or an attribute?  It almost seems as if you'd want
different basedir semantics depending on which concept we are talking
about.

I'm not really sure, which semantics we want to use, but if the
basedir of the importing file always wins, I fail to see how I can do
an import in an imported file.  If A imports B and B imports C, how
does B address C if all relative paths depend on A's basedir, that B
cannot even pretend to know about?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:

 +1 on capability to restrict a build file to only be imported
 -1 to make that mandatory for imports

fine with me.

 +0 to an attribute in project to designate such files
 +1 to a new root element instead.

The attribute would enable a build file to explicitly state that it is
not importable, that's what Nicola Ken says IIRC.

I'm not exactly sure which use case that would be, but it's sort of
like final on a class - it would allow a build file to ensure that no
targets have been overridden.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003 12:19 am, Stefan Bodewig wrote:
 On Fri, 25 Jul 2003, Conor MacNeill [EMAIL PROTECTED]

 If A imports B and B imports C, how
 does B address C if all relative paths depend on A's basedir, that B
 cannot even pretend to know about?


The paths won't depend on A's basedir. They won't event depend on B's basedir. 
They will only depend only on B's location.

So if B and C are in the same dir and B's basedir is .., the import for C 
will still be import file=C - i.e. basedir in B is ignored. What 
Dominique meant when he said everything is resolved to A's basedir he really 
meant everything *except* import paths (I hope that is what he intended). So 
fileset dirs, etc are resolved to A's basedir even if they are declared in B 
or C.

Clear as mud?

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003 12:19 am, Stefan Bodewig wrote:
 On Fri, 25 Jul 2003, Conor MacNeill [EMAIL PROTECTED]

 wrote:
  Sure. Let me push the C/C++ analogy a little further.

 Leaving this analogy aside ...

 In the particular case you've mentioned (checkstyle.xml using
 build.xml) I'm absolutely with Ken, farm out the common stuff and
 import it from both.  Use composition instead of inheritance.


On the particular issue of this approach in Ant's build file, I would 
disagree. I would prefer to maintain Ant's main build file as a single entity 
and not factor out stuff to separate headers defining locations. Just MHO, 
of course.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:

 Clear as mud?

Errm, yes.

How would you do

taskdef resource=...
  classpath
fileset dir=lib/ includes=*.jar/
  /classpath
/taskdef

??

By not using relative paths (but something like ${this.basedir}/lib),
I guess.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

2003-07-25 Thread Alexey Solofnenko

  I agree with Conor. And I also like a possibility to execute subcomponent
build separately. 

  I do not know whether import allows the same build file to be included
several times from different components. This feature would allow having all
the dependencies in the (sub)component build files, not in the main build
file.

- Alexey.

--
{ http://trelony.cjb.net/ } Alexey N. Solofnenko
Pleasant Hill, CA (GMT-8 usually)


-Original Message-
From: Conor MacNeill [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 24, 2003 8:39 AM
To: Ant Developers List
Subject: Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:

 I (strongly again ;) believe that imported build files should be designed
 to be imported, and never used without being imported. 

I disagree (strongly :-). I think augmenting/overriding an existing build
file 
is a valid use for import. I recently changed the checkstyle build I have 
been using (check.xml) to import Ant's build.xml to pick up property defs
for 
various locations. Have a look.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003 12:52 am, Stefan Bodewig wrote:
 On Sat, 26 Jul 2003, Conor MacNeill [EMAIL PROTECTED]

 wrote:
  Clear as mud?

 Errm, yes.

 How would you do

 taskdef resource=...
   classpath
 fileset dir=lib/ includes=*.jar/
   /classpath
 /taskdef

 ??

 By not using relative paths (but something like ${this.basedir}/lib),
 I guess.


Good question. Currently you get a property telling you the location of your 
build file - not your basedir.

BTW, the property is based on the project's name which might be an issue if 
the name is controllable by the importing build file. Is a name mandatory for 
an importable project or just one that want to know its location?

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:

 Currently you get a property telling you the location of your build
 file - not your basedir.

You could use dirname/ on it, but having it as a separate property
would be convenient.

 BTW, the property is based on the project's name which might be an
 issue if the name is controllable by the importing build file.

Depends on who is in ultimate control.

If I need access to my build file location in the imported file, the
only way right now is when I can control the name.  So the name
attribute on the import would have to be the fallback if the
imported file doesn't have a name.

On the other hand, the name is also used to resolve target name
clashes IIUC, then you'll probably want the importing file to be in
control.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-25 Thread Nicola Ken Barozzi

Conor MacNeill wrote, On 25/07/2003 17.19:
On Sat, 26 Jul 2003 12:52 am, Stefan Bodewig wrote:
On Sat, 26 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:
Clear as mud?
Errm, yes.
How would you do
taskdef resource=...
 classpath
   fileset dir=lib/ includes=*.jar/
 /classpath
/taskdef
??
By not using relative paths (but something like ${this.basedir}/lib),
I guess.

Good question. Currently you get a property telling you the location of your 
build file - not your basedir.
Correct, bacause the basedir has no meaning as the file is imported.
What about ant.projectdir and ant.projectdir.projectname properties?
BTW, the property is based on the project's name which might be an issue if 
the name is controllable by the importing build file. Is a name mandatory for 
an importable project or just one that want to know its location?
IMHO the latter.
Explaining a bit more my cases:
 1) I have a project that is made only to be imported:
fragment name=.../fragment
- Ant will deny the use of it standalone -
I would need this when I use the ant.file.currentproject
property that is not available when I run it standalone.
(although we could as well put it, and so this use-case
looses meaning it seems)
 2) I have a project that is not made to be imported:
project importable=false.../project
- Ant will deny the use of it as imported -
This project does not check that the resources and paths
are resolved using the ant.file.projectname property, and
thus would not work properly if imported.
In this case the name attribute is mandatory.
 3) I have a project that can be imported or used as-is:
project importable=true.../project
- Ant will never deny it's use -
This project does not use external resources, or
checks for them in a manner that works in both scenarios.
 4) I have a project that does not say if it can be imported:
project importable=true.../project
- Ant will never deny it's use but warn if it's imported -
The author does not tell you how it's meant to use.
Most probably it's not made to be imported, so if you want
to import it, good luck!
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

2003-07-25 Thread Jose Alberto Fernandez

Guys, I think you are missing the point completely
on this discussion. I do not understand why are you trying
to impose your coding-style preferences for ANT on other
people by forcing things like importable and so forth.

The issue here is very simple, suppose I have the following
files:

/a/b/c/d/e/build.xml:
project name=e
 import file=../f/build.xml/
/project

/a/b/c/d/f/build.xml:
project name=f
 echoHere is F!/echo
/project

/p/q/r/build.xml:
project name=r
  import file=/a/b/c/d/e/build.xml/
/project

/t/u/v/build.xml:
project name=v
 import file=/a/b/c/d/e/build.xml/
/project

Now, /a/b/c/d directory contains the installation of some useful library
of ANT code scripts.

The two diferent unrelated projects in /p/q/r and /t/u/v are trying to use it.
Here the only meaningful way to import f into e is by expanding the file
relative ../f/build.xml relative to the location of project e.

So I need to be able to write this, in some way. Notice that having or not
having basedir defined is just a redhearing.


Additionally, projects e and f may internally need to refer to resources
(i.e., files) located as part of this library, hence I need to have a way
to access the local basedir inside this files.

Jose Alberto


 -Original Message-
 From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
 Sent: 25 July 2003 15:20
 To: [EMAIL PROTECTED]
 Subject: Re: ant 1.5.4 : Import
 
 
 On Fri, 25 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
 wrote:
 
  Sure. Let me push the C/C++ analogy a little further.
 
 Leaving this analogy aside ...
 
 In the particular case you've mentioned (checkstyle.xml using
 build.xml) I'm absolutely with Ken, farm out the common stuff and
 import it from both.  Use composition instead of inheritance.
 
  The analogy with Ant breaks when we talk about target overriding
  which will be a useful usecase.
 
 Yes, here we are talking about import as a method of inheritance, so
 we are using the same task for two different concepts.  Maybe this is
 the cause of confusion and should be amended by either using two
 different tasks or an attribute?  It almost seems as if you'd want
 different basedir semantics depending on which concept we are talking
 about.
 
 I'm not really sure, which semantics we want to use, but if the
 basedir of the importing file always wins, I fail to see how I can do
 an import in an imported file.  If A imports B and B imports C, how
 does B address C if all relative paths depend on A's basedir, that B
 cannot even pretend to know about?
 
 Stefan
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Sat, 26 Jul 2003 01:16 am, peter reilly wrote:
 On Fri, 2003-07-25 at 15:51, Conor MacNeill wrote:

 Or a pint of guinness ;-)


Good idea. :-)

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-25 Thread Steve Loughran

Conor MacNeill wrote:
On Fri, 25 Jul 2003 01:50 am, Dominique Devienne wrote:
Getting back to your point, where does that leaves us for basedir?

I've slept on it :-). I'd vote to go with the current behaviour. i.e. ignore 
basedir. Import tasks will always import relative to the file containing the 
import statement. Slightly different from the standard Ant file resolution 
behaviour but a reasonable approach for import. In the end, since most 
people use . for basedir, it would not be a problem in general.

If you want to be able to build files to only function as imports, I'd support 
that (so called dual behaviour). In fact, I'd be tempted to use an element 
besides project to make it even more explicit. Such an element would not 
support basedir. I did that in Mutant - it was called fragment but it could 
be called import. I wouldn't find that confusing with the import task but 
others might - maybe importable

So 
+1 on capability to restrict a build file to only be imported
+1, if people want it
-1 to make that mandatory for imports
-1 to make that mandatory for imports
+0 to an attribute in project to designate such files
0
+1 to a new root element instead.
0
Given it isnt a project, I suppose it does make sense to name it 
differently. This will prevent confusion. One issue: IDE 
integration...both JEdit and IntelliJ recognise ant build files, and I'd 
like their functionality to propagate to includable components

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-24 Thread peter reilly

On Thu, 2003-07-24 at 03:59, Conor MacNeill wrote:

 At the moment I have issues with import. The importing within imports is 
 not 
 right, at the moment, I think. Also I think we need to give antlib a bit of 
 a stretch :-) I'd like to see that happen first. For me a first 1.6 beta is 
 still about a month or two away.
Hi Conor,

What are the issues with import.

I think we should write them down and deal with
them - it cannot be that difficult..
The difficult ones (manipulation of basebir etc)
we should explicitly defer to ant  1.6.


import is a real cool feature.

 
 
  After the initial release of 1.6, I foresee a long period of bug fixing. :(
  But I like fixing bugs personally :-)
 
 Agreed (on both counts).
+1 

Peter



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Thu, 24 Jul 2003 07:19 pm, peter reilly wrote:
 What are the issues with import.

 I think we should write them down and deal with
 them - it cannot be that difficult..
 The difficult ones (manipulation of basebir etc)
 we should explicitly defer to ant  1.6.

Not difficult but the issues are there.

The renaming of overridden targets depends on project names but lots of 
projects don't have names. I believe the name can be provided in the import 
task to access overridden targets in unnamed projects and also to handle name 
collisions. Probably would require creation of the parsing context in the 
import task.

The basedir issue :-). I'd rather get it right in 1.6 than create a backward 
compatibility issue down the track. Got enough of those to deal with already. 
Import file resolution must be done relative to the basedir of the project 
doing the import, regardless of whether that is the outermost project.

For example,

project basedir=..
  import file=base2/build.xml/

  echo message=base1/build.xml/
/project

This will not work:

Cannot find base2/build.xml imported from base1/build.xml

I've attached a small zip (will it make it through email?). I believe all 3 
builds should work as you would expect. Currently only the one without 
imports does.

Telling people only to use absolute imports is not acceptable, IMHO.

 import is a real cool feature.

Sure enough and also important enough to get right.

Conor
attachment: import.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

Conor MacNeill wrote, On 24/07/2003 13.36:
On Thu, 24 Jul 2003 07:19 pm, peter reilly wrote:
What are the issues with import.
I think we should write them down and deal with
them - it cannot be that difficult..
The difficult ones (manipulation of basebir etc)
we should explicitly defer to ant  1.6.
Not difficult but the issues are there.
The renaming of overridden targets depends on project names but lots of 
projects don't have names. I believe the name can be provided in the import 
task to access overridden targets in unnamed projects and also to handle name 
collisions. 
What about:
 import file=blah.xml name=blah/
Probably would require creation of the parsing context in the 
import task.
?
The basedir issue :-). I'd rather get it right in 1.6 than create a backward 
compatibility issue down the track. Got enough of those to deal with already. 
Import file resolution must be done relative to the basedir of the project 
doing the import, regardless of whether that is the outermost project.

For example,
project basedir=..
  import file=base2/build.xml/
  echo message=base1/build.xml/
/project
This will not work:
Cannot find base2/build.xml imported from base1/build.xml

I've attached a small zip (will it make it through email?). I believe all 3 
builds should work as you would expect. Currently only the one without 
imports does.
In base1/build.xml I changed the import to:
  import file=../base2/build.xml/
And it works.
So IIUC it's really only about making the import task resolve files 
relative to the basedir of the project that imports, as you say above.

Telling people only to use absolute imports is not acceptable, IMHO.
IMHO what you propose is the correct behaviour, and the one that users 
(me too) would think should happen (least surprise rule).

import is a real cool feature.
Sure enough and also important enough to get right.
+1
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:

 What about:

   import file=blah.xml name=blah/

Sure - pretty much what I thought, maybe a more descriptive attribute name 
(overrideprefix). It would default to the imported project name.


 So IIUC it's really only about making the import task resolve files
 relative to the basedir of the project that imports, as you say above.


Yes. This is how Ant works for other tasks so it should work that way for 
import too. The resolution does have to be done in Import itself using a 
String argument since the default File argument would be resolved by Ant to 
the outermost project's basedir which would be wrong.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

Conor MacNeill wrote, On 24/07/2003 14.49:
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
 import file=blah.xml name=blah/
Sure - pretty much what I thought, maybe a more descriptive attribute name 
(overrideprefix). It would default to the imported project name.
A bit long...
What about this, it seems descriptive enough IMHO.
 import file=blah.xml prefix=blah/
or
 import file=blah.xml use-prefix=blah/
So IIUC it's really only about making the import task resolve files
relative to the basedir of the project that imports, as you say above.
Yes. This is how Ant works for other tasks so it should work that way for 
import too. The resolution does have to be done in Import itself using a 
String argument since the default File argument would be resolved by Ant to 
the outermost project's basedir which would be wrong.
Well, import already uses a String argument but does the following:
   // Paths are relative to the build file they're imported from,
   // *not* the current directory (same as entity includes).
   File importedFile = new File(file);
   if (!importedFile.isAbsolute()) {
   importedFile = new File(buildFileParent, file);
   }
I reckon that this change would resolve to the initial basedir, right?
   File importedFile = new File(getProject().resolveFile(file));
   if (!importedFile.isAbsolute()) {
   importedFile = new File(buildFileParent, file);
   }
Don't have time to try it ATM :-(
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-24 Thread peter reilly

On Thu, 2003-07-24 at 13:49, Conor MacNeill wrote:
 On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
 
  What about:
 
import file=blah.xml name=blah/
 
 Sure - pretty much what I thought, maybe a more descriptive attribute name 
 (overrideprefix). It would default to the imported project name.
 
 
  So IIUC it's really only about making the import task resolve files
  relative to the basedir of the project that imports, as you say above.
 
 
 Yes. This is how Ant works for other tasks so it should work that way for 
 import too. The resolution does have to be done in Import itself using a 
 String argument since the default File argument would be resolved by Ant to 
 the outermost project's basedir which would be wrong.

Just to be sure I understand ...
Assuming the following:
A.xml imports B.xml which imports C.xml.

B has an import
import file=C.xml/

Are saying that A.xml is the outermost project and B.xml is the current
project ?

If so this is not the way import works, there is only one project. (As
against ant and antcall et al, where there is a new sub-project).

In the current code, if B.xml has a basedir attribute for the project
element, the attribute is ignored (Not good).

So the question is what should B's import be relative to:

  1) A.xml's basedir
  2) B.xml
  3) B.xml's currently ignored basedir attribute.

I think that the consensus is 3).

Peter



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003 12:49 am, peter reilly wrote:
 So the question is what should B's import be relative to:

   1) A.xml's basedir
   2) B.xml
   3) B.xml's currently ignored basedir attribute.

 I think that the consensus is 3).


+1

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

a) I personally think that (2) is the least surprising answer,

and furthermore that

b) the effective basedir for the task to operate inside any
   imported file should always be the outermost one.

Also,

c) Imported projects which have an explicit basedir specified
   should result in a warning about that attribute being ignored.

In other words, the context of execution of any imported file should be the
top level build file. I foresee no end in the confusion that would result
otherwise.

Some might argue that an imported file should be able to know where if was
imported from, but I see this as dangerous. It's a limitation that would
make imports in Ant very straightforward.

I'm interested to hear about use bases that would refute my argument on the
other hand, to see what I missed. Thanks, --DD

 -Original Message-
 From: peter reilly [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 9:49 AM
 To: Ant Developers List
 Subject: Re: ant 1.5.4 : Import
 
 So the question is what should B's import be relative to:
 
   1) A.xml's basedir
   2) B.xml
   3) B.xml's currently ignored basedir attribute.
 
 I think that the consensus is 3).
 
 Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

2003-07-24 Thread Stefan Bodewig

On 24 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:

 So the question is what should B's import be relative to:
 
   1) A.xml's basedir
   2) B.xml
   3) B.xml's currently ignored basedir attribute.
 
 I think that the consensus is 3).

I'm not sure, I'm more along the lines of (3) if B has a basedir
attribute and (1) if B has none.

That is that I can write an importable snippet that doesn't depend on
on its own location by omitting the basedir attribute and setting it
if it does.

The usecase for the later is something like Centipede's cents (as I
understand them) where a taskdef in the imported snippet needs to
specify jars for the classpath - and would do so using relative paths.
For easier installment of the full package, that should be relative to
the imported file IMHO.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

Dominique Devienne wrote, On 24/07/2003 16.55:
...
In other words, the context of execution of any imported file should be the
top level build file. I foresee no end in the confusion that would result
otherwise.
Some might argue that an imported file should be able to know where if was
imported from, but I see this as dangerous. It's a limitation that would
make imports in Ant very straightforward.
Can you please expand on this point?
The dir argumentation is what follows:
 - imported buildfile targets are like macros, thus are usually intended
   to be used as if inserted in the main buildfile itself
 - some of the imported targets may need resources relative to *them*,
   and not the importing file, hence the importedfile.ant.file property
Thus all things in the imported file are done relative to the *base* 
file, and hence the current way would be correct.

Thus, in the sake of consistency, I now start to think that something 
like the following would be needed to make what Conor thinks should happen:

  import file=${thisprojectname.ant.file}/../base2/build.xml/
or better
  import file=${thisprojectname.basedir}/base2/build.xml/
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

 I'm interested to hear about use bases that would refute my argument on the
 other hand, to see what I missed. Thanks, --DD


Say I have build B importing C and I'm using B quite happily.

Then one day, I create A to import B and the import in B of C no longer works 
because B had a basedir setting. That would surprise me.

The above scenario assumes that we are taking basedir into account in the B-C 
case, which is not what option (2) is about. But option(2) makes resolution 
of import names not follow the same rules as every other Ant task (i.e. 
taking into account project basedir).

I guess I can live with (2). Basedirs are not that common anyway, and having 
import outside that framework is OK.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

This is indeed a valid use of knowledge of where an imported file was
imported from.

I still think (strongly) that the basedir of any imported file should be
ignored (with a warning if it's something else than ., the default), and
always use the one of the top-level build.

To allow the use-case presented by Stefan, and disambiguate unequivocally
what is being used, a new magic attribute should used to locate
resources/files relative to the currently imported file.

During import, this magic attribute would be resolved/replaced at parse
time, so each imported file is fully resolved against is own directory.

Finding names is always difficult, but an 'importdir' attribute doesn't
sound too bad. --DD

 -Original Message-
 From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 10:09 AM
 To: [EMAIL PROTECTED]
 Subject: Re: ant 1.5.4 : Import
 
 That is that I can write an importable snippet that doesn't depend on
 on its own location by omitting the basedir attribute and setting it
 if it does.
 
 The usecase for the later is something like Centipede's cents (as I
 understand them) where a taskdef in the imported snippet needs to
 specify jars for the classpath - and would do so using relative paths.
 For easier installment of the full package, that should be relative to
 the imported file IMHO.
 
 Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

I don't disagree with your scenario in the sense that it would break, but I
disagree that it's either a good usage of import or desirable.

I (strongly again ;) believe that imported build files should be designed to
be imported, and never used without being imported. I would even be
favorable (but I might be the only one) to add an attribute to project
that was required the be import-able, and would render that build non-usable
directly.

This way, you eliminate any possible confusion. --DD

 -Original Message-
 From: Conor MacNeill [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 10:23 AM
 To: Ant Developers List
 Subject: Re: ant 1.5.4 : Import
 
  I'm interested to hear about use bases that would refute my argument on
 the
  other hand, to see what I missed. Thanks, --DD
 
 
 Say I have build B importing C and I'm using B quite happily.
 
 Then one day, I create A to import B and the import in B of C no longer
 works
 because B had a basedir setting. That would surprise me.
 
 The above scenario assumes that we are taking basedir into account in the
 B-C
 case, which is not what option (2) is about. But option(2) makes
 resolution
 of import names not follow the same rules as every other Ant task (i.e.
 taking into account project basedir).
 
 I guess I can live with (2). Basedirs are not that common anyway, and
 having
 import outside that framework is OK.
 
 Conor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

Did my other messages answer your questions??? --DD

 -Original Message-
 From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 10:09 AM
 To: [EMAIL PROTECTED]
 Subject: Re: ant 1.5.4 : Import

 Dominique Devienne wrote, On 24/07/2003 16.55:

 ...
  In other words, the context of execution of any imported file should be
 the
  top level build file. I foresee no end in the confusion that would
 result
  otherwise.

  Some might argue that an imported file should be able to know where if
 was
  imported from, but I see this as dangerous. It's a limitation that would
  make imports in Ant very straightforward.

 Can you please expand on this point?

 The dir argumentation is what follows:

   - imported buildfile targets are like macros, thus are usually intended
 to be used as if inserted in the main buildfile itself
   - some of the imported targets may need resources relative to *them*,
 and not the importing file, hence the importedfile.ant.file property

 Thus all things in the imported file are done relative to the *base*
 file, and hence the current way would be correct.

 Thus, in the sake of consistency, I now start to think that something
 like the following would be needed to make what Conor thinks should
 happen:

import file=${thisprojectname.ant.file}/../base2/build.xml/

 or better

import file=${thisprojectname.basedir}/base2/build.xml/

 --
 Nicola Ken Barozzi   [EMAIL PROTECTED]
  - verba volant, scripta manent -
 (discussions get forgotten, just code remains)
 -

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import


Dominique Devienne wrote, On 24/07/2003 17.23:
Did my other messages answer your questions??? --DD
IIUC we agree.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:

 I (strongly again ;) believe that imported build files should be designed
 to be imported, and never used without being imported. 

I disagree (strongly :-). I think augmenting/overriding an existing build file 
is a valid use for import. I recently changed the checkstyle build I have 
been using (check.xml) to import Ant's build.xml to pick up property defs for 
various locations. Have a look.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dominique Devienne wrote, On 24/07/2003 17.18:
This is indeed a valid use of knowledge of where an imported file was
imported from.
I still think (strongly) that the basedir of any imported file should be
ignored (with a warning if it's something else than ., the default), and
always use the one of the top-level build.
To allow the use-case presented by Stefan, and disambiguate unequivocally
what is being used, a new magic attribute should used to locate
resources/files relative to the currently imported file.
During import, this magic attribute would be resolved/replaced at parse
time, so each imported file is fully resolved against is own directory.
Finding names is always difficult, but an 'importdir' attribute doesn't
sound too bad. --DD
There is already an ant.file.importedfilename that can be used by
immported files, and we have asked to make it since a long time ago,
because we found out in Centiepde that it was needed.

Is it this what you are saying?
http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/docs/manual/CoreTasks/import.html?rev=HEADcontent-type=text/html
Stefan Bodewig wrote, On 24/07/2003 17.09:
...
The usecase for the later is something like Centipede's cents (as I
understand them) where a taskdef in the imported snippet needs to
specify jars for the classpath - and would do so using relative paths.
For easier installment of the full package, that should be relative to
the imported file IMHO.
But since we package cents and get the resources for the cents, and
install the cents in their own dirs, for us it makes sense to keep the
references relative.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

Then have a look at what I did in the past two days to do something similar
;-) I created an antreturn task that piggybacks on ant, and allows
returning properties and/or references from the called build file back into
the caller's context (Project).

That would take care of that use case ;-) --DD

 -Original Message-
 From: Conor MacNeill [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 10:39 AM
 To: Ant Developers List
 Subject: Re: ant 1.5.4 : Import
 
 On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:
 
  I (strongly again ;) believe that imported build files should be
 designed
  to be imported, and never used without being imported.
 
 I disagree (strongly :-). I think augmenting/overriding an existing build
 file
 is a valid use for import. I recently changed the checkstyle build I have
 been using (check.xml) to import Ant's build.xml to pick up property defs
 for
 various locations. Have a look.
 
 Conor


?xml version=1.0?

project name=AntReturnTest default=test-returnProperty

  !-- Our custom tasks we are testing --
  taskdef resource=com/lgc/buildmagic/tasks.properties /
  typedef resource=com/lgc/buildmagic/types.properties /

  target name=test-returnProperty
antreturn antfile=AntReturnNestedTest.xml target=set-properties
  return
property name=propA /
property name=propC /
  /return
/antreturn
  /target

  target name=test-returnReference
antreturn antfile=AntReturnNestedTest.xml target=set-references
  return
reference refid=pathRef /
reference refid=filesetRef /
  /return
/antreturn
  /target

/project

?xml version=1.0?

project name=AntReturnNestedTest default=set-properties

  target name=set-properties
property name=propA value=a /
property name=propB value=bb /
property name=propC value=ccc /
property name=propD value= /
  /target

  target name=set-references
path id=pathRef location=${basedir} /
fileset id=filesetRef dir=${basedir}
  include name=AntReturn*Test.xml /
/fileset
patternset id=patternsetRef
  include name=dummy /
/patternset
  /target

/project

// vim:ts=2:sw=2
package com.lgc.buildmagic.test;

import org.apache.tools.ant.ProjectComponent;
import org.apache.tools.ant.types.Path;
import org.apache.tools.ant.types.FileSet;

import com.lgc.buildmagic.util.BuildFileTestCase;

/**
 * Tests lt;antreturngt;.
 *
 * @author a href=mailto:[EMAIL PROTECTED]Dominique Devienne/a
 * @version Jul 2003 - Copyright (c) 2003, Landmark Graphics Corp.
 */
public class AntReturnTest
 extends BuildFileTestCase { 
 
  public void testReturnProperty() {
executeTarget(test-returnProperty);

assertProperty(propA, a);
assertProperty(propB, null);
assertProperty(propC, ccc);
assertProperty(propD, null);
  }

  private void assertProperty(String name, String expectedValue) {
String value = getProject().getProperty(name);
assertEquals(name +  property, value, expectedValue);
  }

  public void testReturnReference() {
executeTarget(test-returnReference);

assertReference(pathRef, Path.class);
assertReference(filesetRef, FileSet.class);
assertReference(patternsetRef, null);
  }

  private void assertReference(String refid, Class expectedClass) {
Object value = getProject().getReference(refid);
if (expectedClass != null) {
  assertNotNull(refid +  reference, value);
  assertEquals(refid +  reference type, expectedClass,
value.getClass());
  assertSame(refid +  reference project, getProject(),
 ((ProjectComponent)value).getProject());
}
else {
  assertEquals(refid +  reference found, false, value != null);
}
  }

} // END class AntReturnTest 

// vim:ts=2:sw=2
package com.lgc.buildmagic;

import java.util.List;
import java.util.Iterator;
import java.util.ArrayList;
import java.util.Collections;

import org.apache.tools.ant.Project;
import org.apache.tools.ant.ProjectComponent;
import org.apache.tools.ant.BuildException;

import org.apache.tools.ant.types.Reference;

import org.apache.tools.ant.taskdefs.Ant;
import org.apache.tools.ant.taskdefs.Property;

/**
 * ...
 *
 * @author a href=mailto:[EMAIL PROTECTED]Dominique Devienne/a
 * @version Jul 2003 - Copyright (c) 2003, Landmark Graphics Corp.
 *
 * @ant.task category=control
 */
public class AntReturn
 extends Ant {

  private Project _newProject;
  private ReturnedElements _returns;

  public void init() {
super.init();
setInheritAll(false);
setInheritRefs(false);
  }

  public void execute()
  throws BuildException {
int returnCount = 0;
if (_returns != null) {
  returnCount = _returns._references.size()
  + _returns._properties.size();
}

if (returnCount  0  _newProject == null) {
  // Create dummy property to get at nested project
  Property p = createProperty();
  p.setName(sdliugyhspuygh.asdjhriawu120983472

Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003 01:36 am, Dominique Devienne wrote:
 Then have a look at what I did in the past two days to do something similar
 ;-) I created an antreturn task that piggybacks on ant, and allows
 returning properties and/or references from the called build file back into
 the caller's context (Project).

 That would take care of that use case ;-) --DD


Not really - it doesn't allow for the overriding of a single target within 
another build file. It's useful anyway and probably should be added to ant 
but I don't see it as a reason to disallow importing of other projects.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import

2003-07-24 Thread Kenneth Wood

-Original Message-
From: Conor MacNeill [ mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 10:39 AM
To: Ant Developers List
Subject: Re: ant 1.5.4 : Import

On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:

 I (strongly again ;) believe that imported build files should be
 designed to be imported, and never used without being imported.

I disagree (strongly :-). I think augmenting/overriding an existing build
file
is a valid use for import. I recently changed the checkstyle build I have
been using (check.xml) to import Ant's build.xml to pick up property defs
for
various locations. Have a look.

[KWW]-
Well, that's convenient, but not necessarily what I would have expected.

A C or C++ program doesn't include another  program just
to get definitions. Instead, the definitions are put into
a .h file, and both programs import that .h file of definitions.

So, the definitions of locations could be in
a locations.xml file, then imported by Ant's build.xml and your check.xml
allowing both build files to share the definitions, but not pull in any
unwanted
things.

-[KWW]

Conor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ant 1.5.4 : Import