So where are we on all this?
Is Jose's approach of having an empty interface going to be accepted? I
haven't seen a bunch of +1's on this, but this seems to be where the
discussion was going before it dropped off.
I bring this up again because I keep running into annoying problems because
of the current implementation. Today's gem was that <condition> isn't
allowed at the top, but I need that functionality in order to specify
defaults for environment variables used by my build.xml file, e.g.
<property environment="env"/>
<!-- provide a default for the WEBLOGIC_INSTALL environment var -->
<!-- NOTE: we're relying on the fact that this won't override -->
<!-- any previous setting made in the actual environment -->
<condition property="env.WEBLOGIC_INSTALL" value="C:\netco\wls">
<os family="windows"/>
</condition>
<condition property="env.WEBLOGIC_INSTALL" value="/netco/wls">
<os family="unix"/>
</condition>
<property file="build.properties" />
The build.properties file contains (among other things) the following
install.dir=${env.WEBLOGIC_INSTALL}
install.app.dir=${install.dir}/config/wamnet/applications
install.lib.dir=${install.dir}/lib
So clearly, the environment variable needs to be defined before the call to
<property file=>, and the only way to do that, short of putting an init
dependency inside every single target, is to allow <condition> to live at
the top level.
Or, to allow an <init> target. ;->
Tim
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 23, 2001 3:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Ant2] Tasks as siblings of <target>
>
>
> On Tue, 23 Oct 2001 23:38, Stefan Bodewig wrote:
> > On Mon, 22 Oct 2001, Peter Donald <[EMAIL PROTECTED]> wrote:
> > > On Mon, 22 Oct 2001 17:42, Stefan Bodewig wrote:
> > >> Declaring TaskContexts (whatever that will be), declaring and
> > >> attaching build listeners from within a build file, ...
> > >
> > > those examples work.
> >
> > So would you still prefer hardcoded names in the build file parser?
>
> Prolly not but I am not sure we can identify them with a
> "Declarable" or
> whatever because the objects don't get created to ages later.
>
> >
> > > Fine grain services allow tasks to do more interesting stuff but
> > > also could be a maintanence nightmare and overly
> constraining as we
> > > evolve. Large interfaces can be inflexible.
> >
> > Let's examine what the container needs to provide from our current
> > knowledge and not stretch that too far. Combined with a
> note that the
> > API for "privileged" tasks could be changed even in minor releases,
> > this should work.
>
> kool.
>
> > Back to the original subject - would we allow such
> "privileged" tasks
> > to live at the same level as targets and how would we identify them?
>
> I think privlidged tasks are a different thing altogether
> from declarable
> tasks.
>
> --
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
