On Tue, 2 Oct 2001 18:39, Holger Engels wrote:
> possible solution:
>
> -> evaluate the path definition on demand - probably more than once a
> build
>
>
> rationale:
>
> -> a target depends on a path, the same way as targets depend on other
> targets
>
>
> Discussion?
We talked about (and I think we agreed?) that there should be 3 phases;
definition, resolution and usage.
Ie the following would define it
 <path id="some.path">
  <pathelement path="${build.classpath}/" />
  <fileset dir="${build}/lib">
   <include name="*.jar" />
  </fileset>
 </path>
However it wouldn't be resolved until actually used. This resolution could
happen as task executes or via something like
<property name="..." value="${some.path}"/>
which would resolve the value (ie create list of files in path).
This could be applied universally to any types that implement Resolvable. So
it definetly sounds like a good idea! ;)
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
