You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by peter reilly <pe...@corvil.com> on 2003/07/24 11:19:26 UTC
Re: ant 1.5.4 : Import
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Stefan Bodewig <bo...@apache.org>.
On 24 Jul 2003, peter reilly <pe...@corvil.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by peter reilly <pe...@corvil.com>.
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Steve Loughran <st...@iseran.com>.
Conor MacNeill wrote:
> 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.
maybe projects should get a default name of their full filepath
>
> 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.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ant 1.5.4 : Import
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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