Dominique --
Dang, I didn't know there was a competition going on!
I wrote most of the Antelope tasks because I had a specific need. Feel
free to grab what you want and put it in Ant-contrib. I like your
"loophole" for your "antreturn" task, I didn't like the code reuse
either, but the way the "
quiet bad english. :)
- Message d'origine -
De : "Antoine Levy-Lambert" <[EMAIL PROTECTED]>
À : "Ant Developers List" <[EMAIL PROTECTED]>
Envoyé : jeudi 28 août 2003 16:37
Objet : Re: [VOTE] Ant/Antcall Returning properties and
references [WAS] Re: a
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
> Antoine Levy-Lambert wrote:
> > So far, I have got two +1 (myself and Jan Materne) for this
> proposal.
> > The vote will be closed tomorrow at 12:28 pm CET (20 hours
> from now).
> > Three +1s are required for a code change, so, by the lik
Antoine Levy-Lambert wrote:
So far, I have got two +1 (myself and Jan Materne) for this proposal. The
vote will be closed tomorrow at 12:28 pm CET (20 hours from now). Three +1s
are required for a code change, so, by the likes of it, the vote will have a
negative result.
The , , tasks of Antelope
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> I'd like to explore the needs that is driving this specific feature
> request - and see whether there is a different way to meet it.
> or will allow you to import a set of properties (or
> property setting tasks) f
On Thu, 28 Aug 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]>
wrote:
> So far, I have got two +1 (myself and Jan Materne) for this
> proposal.
Just a quick comment from myself.
I don't really like the idea of turning into a method call,
that's why I won't give you a positive vote - unless I can
August 22, 2003 12:28 PM
Subject: [VOTE] Ant/Antcall Returning properties and references [WAS] Re:
ant 1.5.4 : Import
> I think that the code of Dominique would add a lot of value to ant.
> Instead of committing the code as is, I would like simply to add the new
> features to the task.
>
+1
Jan
> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 22, 2003 12:29 PM
> To: Ant Developers List
> Subject: [VOTE] Ant/Antcall Returning properties and references [WAS]
> Re: ant 1.5.4 : Import
>
>
&g
Cheers,
Antoine
- Original Message -
From: "Dominique Devienne" <[EMAIL PROTECTED]>
To: "'Ant Developers List'" <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 5:36 PM
Subject: RE: ant 1.5.4 : Import
> Then have a look at what I did in the
Nicola Ken Barozzi wrote:
Jose Alberto Fernandez wrote, On 31/07/2003 13.24:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
...
Wait a second, does this mean that there is crosstalk between the
lines 1, 2, 3?
Yes, there is crosstalk and at least in XSLT this is a good thing.
It means that y
> On Thu, 31 Jul 2003 10:38 pm, Antoine Levy-Lambert wrote:
> > I am willing to start changing based on the email of Conor of
July
> > 29th, 2003.
> > I am of course more than happy if other committers want to participate
in
> > the exercise.
> >
>
> Cool. I think things are in flux for a few da
On Thu, 31 Jul 2003 10:38 pm, Antoine Levy-Lambert wrote:
> I am willing to start changing based on the email of Conor of July
> 29th, 2003.
> I am of course more than happy if other committers want to participate in
> the exercise.
>
Cool. I think things are in flux for a few days more, though.
I am willing to start changing based on the email of Conor of July
29th, 2003.
I am of course more than happy if other committers want to participate in
the exercise.
> In fact I would like to rename as to reinforce the fact
> that this is its primary function. In fact the problems we are seei
Jose Alberto Fernandez wrote, On 31/07/2003 13.24:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
...
Wait a second, does this mean that there is crosstalk between
the lines
1, 2, 3?
Yes, there is crosstalk and at least in XSLT this is a good thing.
It means that you can write a bunch of file
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote, On 30/07/2003 21.14:
>
>
> > In escense, the idea is to associate a precedence to each
> target (template in XSLT)
> > and when we say target X in a dependency, what is meant is
> the highest precedence X.
>
Jose Alberto Fernandez wrote, On 30/07/2003 21.14:
Guys,
I think that using C++ or C# as the model for ANT inheritance would be very bad.
As I remember, the rules for resolving multiple inheritance in C++ are
very complicated.
Furthermore I don't know them ;-)
I would propose using the XSLT model.
that this, I do not see why ANT will need much
more.
Cheers,
Jose Alberto
> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Sent: 30 July 2003 09:46
> To: [EMAIL PROTECTED]
> Subject: Re: ant 1.5.4 : Import
>
>
>
> Conor MacNeil
Would not it be easier to explicitly specify basedir for every include.
It works for me.
- Alexey.
--
{ http://trelony.cjb.net/ } Alexey N. Solofnenko
Pleasant Hill, CA (GMT-8 usually)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Albrecht, Matt wrote:
-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 3:46 AM
OTOMH this could be solved by rewriting all dependencies that
are not in
the import line.
(1)---a
multi-import (2)---b
(3)---c--
> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 30, 2003 3:46 AM
>
> OTOMH this could be solved by rewriting all dependencies that
> are not in
> the import line.
>
>(1)---a
> multi-import (2)---b
>(3)--
Conor MacNeill wrote, On 30/07/2003 0.10:
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
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,
I meant start with , and then specify 's behavior and
implement it. Too much work lately... --DD
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 29, 2003 9:12 AM
> To: 'Ant Developers List'
> S
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> > 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 bu
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 pro
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 comple
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 u
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
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
>
> I think this is all getting too complex for . What
> you are describing
> is project composition where each project maintains its own
> context, its own
> basedir, etc. This can be done separately from . We
> have discussed
> this in the p
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 . What you are
describing is project composition where each project maintains its own
context, its own basedir, etc.
AFAIK this is done with
Not quite t
On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
> >
> > I think this is all getting too complex for . What you are
> > describing is project composition where each project maintains its own
> > context, its own basedir, etc.
>
> AFAIK this is done with
>
Not quite the same. allowed t
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, d
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
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
I would like to summarize a number of ideas I have read concerning import.
1) attributes for the import task itself :
-
11) file
===> import relative to the basedir of importing build file
12) href
(Peter Reilly)
> import relative to the directory contai
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> 3) What does ${basedir} mean in an imported build file?
>
>Well I think I go at length in my answer to Jose Alberto, but I'll
>just say again that it should resolve to the top level's build file
>basedir.
>
>Imagine I
I answer Jose Alberto below about his specific points, but here are a
few others that were discussed:
1) Imported file build names
Actually, I don't care about the name of the imported file at all,
and as a build writer, I wish I didn't have to give the project a
name at all! When I imp
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 th
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-
CTED]
> 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
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
??
By not using relative paths (but something like ${this.basedir}/lib),
I guess.
Good q
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 on it, but having it as a separate property
would be convenient.
> BTW, the property is based on the project's name which
On 25 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> I think that the file attribute is confusing. If a
> was used,
looks good.
> It may be also be possible to use URL's here,
sounds good.
8-)
Stefan
-
To unsubscribe,
On Fri, 2003-07-25 at 15:51, Conor MacNeill wrote:
> 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 p
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
>
>
>
>
>
>
>
> ??
>
> By not using relative paths (but something like ${this.basedir}/lib),
> I guess.
>
Good
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
On Sat, 26 Jul 2003, Conor MacNeill <[EMAIL PROTECTED]>
wrote:
> Clear as mud?
Errm, yes.
How would you do
??
By not using relative paths (but something like ${this.basedir}/lib),
I guess.
Stefan
-
To unsubscri
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 ab
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.
On Fri, 25 Jul 2003, Conor MacNeill <[EMAIL PROTECTED]>
wrote:
> +1 on capability to restrict a build file to only be ed
> -1 to make that mandatory for s
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
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 bot
Conor MacNeill wrote, On 25/07/2003 1.25:
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 th
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 statemen
On Fri, 25 Jul 2003 01:44 am, Kenneth Wood wrote:
> 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" fil
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
;m talking about, but maybe they could be ON
only if explicitly requested??? Dual behavior is not good, but neither is
tricky behavior... --DD
> -Original Message-
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2003 10:53 AM
> To: Ant Developers L
-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 ;)
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 task that piggybacks on , and allows
> returning properties and/or references from the called build file back into
> the caller's context (Projec
--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 ;) be
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
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.
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)
---
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 wr
: 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 imp
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]
&
> 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 set
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 fro
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
ROTECTED]
> 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 at
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
--
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:
> >
> >
>
> Sure - pretty much what I thought, maybe a more descriptive attribute name
> (overrideprefix). It would default to the imported project name.
>
> >
> >
Conor MacNeill wrote, On 24/07/2003 14.49:
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
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 descr
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
>
> What about:
>
>
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
> rel
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
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
On Thu, 2003-07-24 at 03:59, Conor MacNeill wrote:
> At the moment I have issues with . The importing within imports is
> not
> right, at the moment, I think. Also I think we need to give a bit of
> a stretch :-) I'd like to see that happen first. For me a first 1.6 beta is
> still about a mo
On Thu, 24 Jul 2003 11:03 am, Antoine Levy-Lambert wrote:
> Hi,
>
> I am concerned about the Perforce bugs, about which a lot of people have
> complained.
>
The problem is that there are lots of bug fixes to Ant in HEAD that can be
back ported to 1.5. These are useful for many people. The more th
I have a patch I have been testing for some time, I can submit it to fix the
threading issues.
-Original Message-
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 6:04 PM
To: Ant Developers List
Subject: ant 1.5.4
Hi,
I am concerned about the Perforce
78 matches
Mail list logo
