You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Tim Dawson <td...@wamnet.com> on 2001/11/01 23:12:21 UTC
RE: [Ant2] Tasks as siblings of
Stefan writes:
> > I would prefer (1) if we made it a normal target.
>
> Which would be the old unmodified "no tasks outside of targets" which
> received a -1 by Conor ...
Well, he has to -1 it again now, doesn't he? I don't think a "-1000" counts
for the next thousand times the vote is brought up. :-)
Bevan Arps writes:
> What about making this a proper target (ie no special syntax
> or anything)
> but have it identified in the project element.
+1000 :-)
This was actually my original request that kicked one of the earlier threads
that morphed into this one. Actually, I used "init" as the attribute to keep
away from the spelling (i.e. initialise vs initialize) controversies. :-)
Someone had a problem with this because what if "getReady" had
depends="foo". But I didn't really think that would be much of a problem.
Another issue that was raised that I don't quite understand is that
supposedly preprocess/validation requires top-level tasks. I mean, wouldn't
it be possible to just execute the init target, and then validate all the
other targets? this is effectively what happens if you have top level tasks.
Tim
> -----Original Message-----
> From: Bevan Arps [mailto:bevan.arps@actfs.co.nz]
> Sent: Wednesday, October 31, 2001 2:01 PM
> To: Ant Developers List; ant-dev@jakarta.apache.org
> Subject: Re: [Ant2] Tasks as siblings of <target>
>
>
> At 09:39 31/10/2001 +0100, Stefan Bodewig wrote:
> >Seems we have three options left that didn't receive any -1s:
> >
> >(1) All tasks (and types) can be placed into an <init>
> construct which
> >is much like a target, but cannot have dependencies of its own. All
> >targets depend on this one implicitly. No tasks or types can be
> >siblings of target.
>
> Just a thought from a satisfied Ant user ...
>
> What about making this a proper target (ie no special syntax
> or anything)
> but have it identified in the project element.
>
> ie something like this:
>
> <project
> name="myTestProject"
> default="buildEverything"
> initialise="getReady">
>
> <target name="buildEverything">
> ...
> </target>
>
> <target name="getReady">
> ...
> </target>
>
> </project>
>
> The "contract" could be simply that the initialise target always gets
> executed first, reguardless of what other targets are invoked.
>
> I don't think that there would be any need to restrict it
> from having it's
> own depends list - since an initialisation target could be
> used to ensure
> things are available, having a number of dependencies to
> check for the
> availability of files/classes/xxx could be useful.
>
> Cheers,
> Bevan.
>
>
>
> --
> "Programming is an Art Form that Fights Back"
>
> Bevan Arps (<ma...@actfs.co.nz>bevan.arps@actfs.co.nz)
> Senior OO Analyst, ACT Financial Systems
>
> This communication is confidential to ACT Financial
> Systems (Asia
> Pacific) and is intended for use only by the addressee.
> The views and
> opinions expressed in this email are the senders own and do not
> represent the views and opinions of ACT Financial
> Systems (Asia
> Pacific).
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Peter Donald <do...@apache.org>.
Hi,
Ill answer these questions ... yet again. The answers are all in the archives
though if you want further clarification and don't want to come off as
trolling again - look em up.
On Tue, 6 Nov 2001 16:40, Jose Alberto Fernandez wrote:
> > how many times do I have to state this. <antcall/> in ants own build file
> > is used due to limitations of ant1.x. Several committers have stated that
> > they dislike antcall for numerous reasons. The only committers who
> > supported antcall are me and diane and I have changed my mind.
>
> Does this mean that you are against <ant> also?
no ones ever said that. Though come to think of it there will probably be a
much lesser need for this task. Not sure.
> Unless you remove that one
> the exact same usage pattern can be achieved. Actually that is what the
> current implementation does:
>
> <ant buildfile="${ant.file}" target="..." />
Well considering ant.file will probably not be a property in Ant2 it will
look something like
<ant file="build.xml" target="..." />
but other than that yep.
> > This is not the first time I have said this ... hmmm didn't I say this
> > just last week in response to one of your other "questions".
>
> I certaintly doubt people will be willing to give up <antcall>.
> I have not seen the proposal for any other task that allows altering
> property values in a controlled manner. Which I think is a valid usage for
> <antcall>.
The need for this has slowly been decreasing. The majority of reasons that
this is used nowadays is to implement dynamic templating which is not
something that we will be supporting.
It was used in the past a fair bit to get around limitations of declarations
(ie when properties where used in path elements or like) but most of these
limitations have been removed. I am not actually sure if there is any of
these issues left ????
> But since you are so convinced, can you clarify how you forsee the new
> constructs you propose in ANT2 can be used to rewrite ANT's own build file?
> I am trying to understand what is what you have in mind.
templating. The same idea I have had since you convinced me how evil antcall
was. See archives for description.
> > well the JDOM/DOM or TOM (Task Object Model) is basically the way that
> > most of the proposals have done. The tasks are represented via TaskModel
> > that is a simplified XML-like structure (basically elements can't have
> > mixed content). Two of the the proposals also have Target and Project
> > models that are not represented as this XML-like tree.
> >
> > There is essentially 3 types of state that we should be modeling. How we
> > do it is up to debate. They are;
> > 1. property/datatype values
> > 2. list of registered tasks, aspects, conditions, datatypes, other types
> > etc 3. targets that have been evaluated
>
> We should not forget the tasks objects attribute and element setting, which
> depend on the current state of property/datatype values.
we have already voted to have this evaluated at runtime so there is no need
for any state recording as everything is either stored in (1) or the TOM.
Nothing else is needed.
--
Cheers,
Pete
-------------------------------------------------------
"When we remember we are all mad, the mysteries of life
disappear and life stands explained." -Mark Twain
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Peter Donald" <do...@apache.org>
> how many times do I have to state this. <antcall/> in ants own build file is
> used due to limitations of ant1.x. Several committers have stated that they
> dislike antcall for numerous reasons. The only committers who supported
> antcall are me and diane and I have changed my mind.
>
Does this mean that you are against <ant> also? Unless you remove that one
the exact same usage pattern can be achieved. Actually that is what the current
implementation does:
<ant buildfile="${ant.file}" target="..." />
> This is not the first time I have said this ... hmmm didn't I say this just
> last week in response to one of your other "questions".
>
I certaintly doubt people will be willing to give up <antcall>.
I have not seen the proposal for any other task that allows altering property values
in a controlled manner. Which I think is a valid usage for <antcall>.
But since you are so convinced, can you clarify how you forsee the new constructs
you propose in ANT2 can be used to rewrite ANT's own build file?
I am trying to understand what is what you have in mind.
> well the JDOM/DOM or TOM (Task Object Model) is basically the way that most
> of the proposals have done. The tasks are represented via TaskModel that is a
> simplified XML-like structure (basically elements can't have mixed content).
> Two of the the proposals also have Target and Project models that are not
> represented as this XML-like tree.
>
> There is essentially 3 types of state that we should be modeling. How we do
> it is up to debate. They are;
> 1. property/datatype values
> 2. list of registered tasks, aspects, conditions, datatypes, other types etc
> 3. targets that have been evaluated
>
We should not forget the tasks objects attribute and element setting, which depend
on the current state of property/datatype values.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 14:25, Jose Alberto Fernandez wrote:
> From: "Peter Donald" <do...@apache.org>
>
> > On Tue, 6 Nov 2001 03:13, Jose Alberto Fernandez wrote:
> > > From: "Peter Donald" <do...@apache.org>
> > >
> > > I do not know what you mean?
> > > Has <antcall> being -1 as user pattern?
> >
> > <antcall/> as a lightweight method call has been.
>
> Have you take a look at ANT's build.xml file later? It uses <antcall/>
> in several places, why are this uses acceptable if you claim such use
> has been rejected?
how many times do I have to state this. <antcall/> in ants own build file is
used due to limitations of ant1.x. Several committers have stated that they
dislike antcall for numerous reasons. The only committers who supported
antcall are me and diane and I have changed my mind.
This is not the first time I have said this ... hmmm didn't I say this just
last week in response to one of your other "questions".
> Maybe they are not considered "lightweight", but how do you plan to
> distinguish between "lightweight" and "not lighweight" usages?
we discourage use of antcall because it will not be a lightweight call.
> > > Otherwise, I do not see how a "use case" can be use to veto some
> > > particular implementation approach.
> >
> > easily. See java wrt to pointers.
>
> Please elaborate.
pointers lead to bad programming thus they were eliminated from the picture.
> Of course the question here is how close can the model and runtime
> representation be, and still maintain the ability to process this kind of
> thing efficiently. Today, the model (Project) and the runtime state are so
> close (almost the same) that cannot do any reuse. The other extreme would
> be to use JDOM/DOM as the model (memory equivalent to XML File) and process
> from there. Is there a more efficient intermediate state?
well the JDOM/DOM or TOM (Task Object Model) is basically the way that most
of the proposals have done. The tasks are represented via TaskModel that is a
simplified XML-like structure (basically elements can't have mixed content).
Two of the the proposals also have Target and Project models that are not
represented as this XML-like tree.
There is essentially 3 types of state that we should be modeling. How we do
it is up to debate. They are;
1. property/datatype values
2. list of registered tasks, aspects, conditions, datatypes, other types etc
3. targets that have been evaluated
(1) is accessible to projects tasks - probably via TaskContext
(2) is accessible to components inside runtime and two proposals have called
this the "frame"
(3) IIRC is also stored in frame of one prposal while others just keep it in
call stack. I prefer it to be stored in frame as that makes management of
cross-project DAGs much simpler and a bit lower coupling.
--
Cheers,
Pete
----------------------------------
"Don't play dumb with me.
I happen to be an expert at that"
- Maxwell Smart
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 6 Nov 2001, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> Notice that state also includes the value of properties. so if I
> have:
>
> <property name="a" value="1" />
> <property name="b" value="${a}2" />
>
> I would like to reuse the model in for example a call like:
>
> <antcall ....>
> <param name="a" value="3" />
> </antcall>
>From features.html:
Ant2 will run the build process fully dynamically, which means
that task won't be instantiated before they are actually being run
and <code>${}</code> expansion will see the very latest value of a
property.
So this is supposed to work (even without antcall).
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Peter Donald" <do...@apache.org>
> On Tue, 6 Nov 2001 03:13, Jose Alberto Fernandez wrote:
> > From: "Peter Donald" <do...@apache.org>
> >
> > I do not know what you mean?
> > Has <antcall> being -1 as user pattern?
>
> <antcall/> as a lightweight method call has been.
>
Have you take a look at ANT's build.xml file later? It uses <antcall/>
in several places, why are this uses acceptable if you claim such use
has been rejected?
Maybe they are not considered "lightweight", but how do you plan to
distinguish between "lightweight" and "not lighweight" usages?
> > Otherwise, I do not see how a "use case" can be use to veto some particular
> > implementation approach.
>
> easily. See java wrt to pointers.
>
Please elaborate.
> > The funny thing is that we have a "compiled" version of the project model,
> > the Project object, but this object is not reusable since we pollute it
> > with execution state as we go thru it. I hope we can change that in ANT2.
>
> Most of the proposals separated the model from the runtime state.
>
Notice that state also includes the value of properties. so if I have:
<property name="a" value="1" />
<property name="b" value="${a}2" />
I would like to reuse the model in for example a call like:
<antcall ....>
<param name="a" value="3" />
</antcall>
Of course the question here is how close can the model and runtime representation
be, and still maintain the ability to process this kind of thing efficiently. Today,
the model (Project) and the runtime state are so close (almost the same) that
cannot do any reuse. The other extreme would be to use JDOM/DOM as the
model (memory equivalent to XML File) and process from there. Is there a more
efficient intermediate state?
Cheers,
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 03:13, Jose Alberto Fernandez wrote:
> From: "Peter Donald" <do...@apache.org>
>
> > > One thing that I would like to be able to do is for ANT to have a more
> > > reasonable implementation of <antcall>. Today every <antcall> reads and
> > > parses the project file over and over. Which looks like a waist and
> > > makes the file system the only way for GUIs to communicate with ANT.
> > > What we really need here is to be able to reause the internal
> > > representation of the Project at the point where properties have not
> > > been applied to attributes. That would allow for its evaluation as
> > > parameters. Any ideas on how to do this efficiently?
> >
> > easily done. However that has been -1'ed as a use case so ... ;)
>
> I do not know what you mean?
> Has <antcall> being -1 as user pattern?
<antcall/> as a lightweight method call has been.
> Have settle that the only way to execute a project is from the file system?
Not sure. I can't recall anything definite but thats the impression I get.
> Otherwise, I do not see how a "use case" can be use to veto some particular
> implementation approach.
easily. See java wrt to pointers.
> The funny thing is that we have a "compiled" version of the project model,
> the Project object, but this object is not reusable since we pollute it
> with execution state as we go thru it. I hope we can change that in ANT2.
Most of the proposals separated the model from the runtime state.
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Peter Donald" <do...@apache.org>
> > One thing that I would like to be able to do is for ANT to have a more
> > reasonable implementation of <antcall>. Today every <antcall> reads and
> > parses the project file over and over. Which looks like a waist and makes
> > the file system the only way for GUIs to communicate with ANT. What we
> > really need here is to be able to reause the internal representation of the
> > Project at the point where properties have not been applied to attributes.
> > That would allow for its evaluation as parameters. Any ideas on how to do
> > this efficiently?
>
> easily done. However that has been -1'ed as a use case so ... ;)
>
I do not know what you mean?
Has <antcall> being -1 as user pattern?
Have settle that the only way to execute a project is from the file system?
Otherwise, I do not see how a "use case" can be use to veto some particular
implementation approach. Or do you mean something else?
The funny thing is that we have a "compiled" version of the project model,
the Project object, but this object is not reusable since we pollute it with
execution state as we go thru it. I hope we can change that in ANT2.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Peter Donald <do...@apache.org>.
On Mon, 5 Nov 2001 21:25, Jose Alberto Fernandez wrote:
> Independently of what it is decided, I would like that any arquitecture we
> come up with will manage this "keyworkds" are its functionality in a
> pluggable fashion. That will allow for extensions or customizations in the
> future on this regard. I am not saying they are tasks, mayby they are
> ModelBuilders :)
It has only been close to a year I have been advocating ProjectBuilders for
just this purpose.
> > Everything that is not specifically recognized will probably be
> > collected into a model component that supports arbitrarily nested XML
> > elements. This will of course be used for tasks/types but may also be
> > used for other constructions which need to be processed in the execution
> > phase. So, there should be sufficient extensibility in the model for
> > other elements without making the parsing phase some sort of stripped
> > down DOM builder or taking on the "everything is a task" view.
>
> One thing that I would like to be able to do is for ANT to have a more
> reasonable implementation of <antcall>. Today every <antcall> reads and
> parses the project file over and over. Which looks like a waist and makes
> the file system the only way for GUIs to communicate with ANT. What we
> really need here is to be able to reause the internal representation of the
> Project at the point where properties have not been applied to attributes.
> That would allow for its evaluation as parameters. Any ideas on how to do
> this efficiently?
easily done. However that has been -1'ed as a use case so ... ;)
--
Cheers,
Pete
---------------------------------------------------
For every complex problem there is a solution that
is simple, neat and wrong
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
ejbjar, depset
Posted by Holger Engels <he...@mercatis.de>.
I sent several patches and sources some time ago. I wonder, when they will
be applied to the repository?!
types:
o depset
ejb:
o handling of manifest files
o automatic adding of dependant classes
Both, DepSet and GenericDeploymentTool depend on a helper class:
org.apache.tools.ant.types.Dependencies
Also there was a submission of a websphere deployment tool some time ago
(can't remember the name of the submitter). I use it frequently on windows
2000 and linux and it seems to be stable ..
If you don't find the time, to incorporate these enhancements, just give
me rw and I'll do it. I really want to have this in the next release!
Cheers,
Holger
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Jose Alberto Fernandez wrote:
>
> How committed are we to *all* this things? I really do not remember if there
> have been votes in all this details.
Quoting from http://jakarta.apache.org/ant/ant2/features.html
"Ant2 will have a clear separation between the front-end that is
responsible for user interactions, the object model that represents the
project to build and the part of Ant that runs the build process itself.
This separation is expected to ease the integration of Ant (or parts of
it) into other products."
> The reason for my question is that I do remember
> the huge discussion we had about how AntGUIs were suppose to communicate with
> ANT itself (can they manipulate the build-model?) or should all communications
> be thru XML (either text or (J)DOM?).
In my view, all front end processes will manipulate a build model - not
DOM/JDOM/SAX or anything else XML specific. Some build models may ceom
from non-XML sources including GUI models, embedded code, or whatever
else you want to think of. XML representation is just one possible
representation.
>
> Independently of what it is decided, I would like that any arquitecture we come up
> with will manage this "keyworkds" are its functionality in a pluggable fashion.
> That will allow for extensions or customizations in the future on this regard.
> I am not saying they are tasks, mayby they are ModelBuilders :)
The approach I outlined should support enough extensibility. I think we
need to be careful not to overabstract the parser to cater for future
possibilities that may never eventuate. Lets add it in when we really
have a need.
> One thing that I would like to be able to do is for ANT to have a more reasonable
> implementation of <antcall>. Today every <antcall> reads and parses the project
> file over and over.
Yep that is bad and doesn't work at all when the build model comes from
a non-XML source. This will go, I am sure.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
> In Ant2, we want to strongly separate parsing from execution. In my
> view, parsing will contruct an object model of the build file which will
> be handed to the execution part of Ant. There will no effective
> communication between these two phases apart from the build model
> itself. Some things (not necessarily many) need to be processed and
> validated in the parsing stage. This is why "target" and some other
> keywords ("projectref", "include", whatever) will be coded into the
> parser because it allows the parser to contruct the build object model.
How committed are we to *all* this things? I really do not remember if there
have been votes in all this details. The reason for my question is that I do remember
the huge discussion we had about how AntGUIs were suppose to communicate with
ANT itself (can they manipulate the build-model?) or should all communications
be thru XML (either text or (J)DOM?).
Independently of what it is decided, I would like that any arquitecture we come up
with will manage this "keyworkds" are its functionality in a pluggable fashion.
That will allow for extensions or customizations in the future on this regard.
I am not saying they are tasks, mayby they are ModelBuilders :)
> Everything that is not specifically recognized will probably be
> collected into a model component that supports arbitrarily nested XML
> elements. This will of course be used for tasks/types but may also be
> used for other constructions which need to be processed in the execution
> phase. So, there should be sufficient extensibility in the model for
> other elements without making the parsing phase some sort of stripped
> down DOM builder or taking on the "everything is a task" view.
>
One thing that I would like to be able to do is for ANT to have a more reasonable
implementation of <antcall>. Today every <antcall> reads and parses the project
file over and over. Which looks like a waist and makes the file system the only
way for GUIs to communicate with ANT. What we really need here is to be able
to reause the internal representation of the Project at the point where properties
have not been applied to attributes. That would allow for its evaluation as
parameters. Any ideas on how to do this efficiently?
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Tim Dawson wrote:
> Stefan writes:
>
>>>I would prefer (1) if we made it a normal target.
>>>
>>Which would be the old unmodified "no tasks outside of targets" which
>>received a -1 by Conor ...
>>
>
> Well, he has to -1 it again now, doesn't he?
OK.
-1.
I think there are a number of reasonable reasons for having global
properties. First of all just about all current Ant build files use this
pattern. They could have used "init" targets but most people chose to
use global properties. This is true even when there is some other init
tasks that get done such as making directories. Apart from being an
established usage pattern, I think it is also a usability issue. When I
look at a buildfile for the first time I can see pretty much straight
away what are the "control points" for the build - "OK, I can turn
deprecations on here, change the build area there, etc". These control
points are important because they will be the things I override from the
command line or from <ant> calls when I use this buildfile.
Moving this declaration into a target will make that less obvious. That
isn't to say I am against an <init> element or even an init attribute on
the project. I'm not that keen on the latter as it causes surprises when
it has depends attribute. Even Bevan's definition
> The "contract" could be simply that the initialise target always gets
executed first, reguardless of what other targets are invoked.
fails in the face of a depends attribute. That can be overcome, of
course - just depends how mucgh support you want to do on ant-user. So I
see the issue of top level tasks and an init solution in whatever form
as not being necessarily mutually exclusive.
> I don't think a "-1000" counts
> for the next thousand times the vote is brought up. :-)
I don't think I -1'd it originally but vetos cannot, in general, be
overruled.
> Someone had a problem with this because what if "getReady" had
> depends="foo". But I didn't really think that would be much of a problem.
> Another issue that was raised that I don't quite understand is that
> supposedly preprocess/validation requires top-level tasks. I mean, wouldn't
> it be possible to just execute the init target, and then validate all the
> other targets? this is effectively what happens if you have top level tasks.
>
In Ant2, we want to strongly separate parsing from execution. In my
view, parsing will contruct an object model of the build file which will
be handed to the execution part of Ant. There will no effective
communication between these two phases apart from the build model
itself. Some things (not necessarily many) need to be processed and
validated in the parsing stage. This is why "target" and some other
keywords ("projectref", "include", whatever) will be coded into the
parser because it allows the parser to contruct the build object model.
Everything that is not specifically recognized will probably be
collected into a model component that supports arbitrarily nested XML
elements. This will of course be used for tasks/types but may also be
used for other constructions which need to be processed in the execution
phase. So, there should be sufficient extensibility in the model for
other elements without making the parsing phase some sort of stripped
down DOM builder or taking on the "everything is a task" view.
option (1) -1 but not necessarily against <init>, init=""
option (2) +1
option (3) +0 - can be done in execution stage only and not necessary if (2) goes.
Conor
(Happy to discuss further).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 1 Nov 2001, Tim Dawson <td...@wamnet.com> wrote:
> Stefan writes:
>> > I would prefer (1) if we made it a normal target.
>>
>> Which would be the old unmodified "no tasks outside of targets"
>> which received a -1 by Conor ...
>
> Well, he has to -1 it again now, doesn't he?
Not really - even if this had been a formal vote so far (and not just
a discussion to see whether there is any sense in starting a vote 8-).
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ant2] Tasks as siblings of
Posted by Peter Donald <do...@apache.org>.
On Fri, 2 Nov 2001 09:12, Tim Dawson wrote:
> Another issue that was raised that I don't quite understand is that
> supposedly preprocess/validation requires top-level tasks. I mean, wouldn't
> it be possible to just execute the init target, and then validate all the
> other targets? this is effectively what happens if you have top level
> tasks.
Then you would need to
a) restrict the possible tasks inside init to just those required (which
doesn't include all those property/available/etc) which most people would not
find useful
b) make thse constructs tasks which would require tight coupling between
runtime and tasks which would unduly restrict future evolution
c) not intuitive - imagine you had to search through a java file for an init
method and inside that was located all the java import statements.
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>