ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 06:37:20 GMT
> -----Original Message-----
> From: Jose Alberto Fernandez []
> Well that makes sense but it seems more writing for writing sake.
> In Java, classpaths are outside of the language,

My expectation is that most antlibs will be available implicitly by location
of the .tsk files. This puts it outside the scope of the build file.
Nevertheless, I know what you mean and a combined form may be OK. I'll give
it a spin this weekend.

> they are a feature of the
> JVM. But in ANT we are having both on the same file, and at the
> same time, I
> see no reason on keeping them separatly just because...
> Is there anything that we are gaining by keeping them separate?

You mean besides logical consistency :-) Lets say this is now two forms

<import lib="com.m64.tasks.fubar" task="foo"/>
<import lib="com.m64.tasks.fubar" task="bar" alias="echo"/>


<antlib location="blahblah">
   <classpath ...>
   <import task="foo"/>
   <import task="bar" alias="echo"/>

The former case is used when the library comes from a .tsk file. The lib
identifier is contained in tsk file's antlib.xml file. The second case is
used when you are referencing the lib directly in the build file. How is

> I really think <includes> will be the cause of problems (and more presure
> for mutable variables) if you see MAKE, originally it was all inmutable
> variables. Variables took their value before any target is executed. But
> with includes and the patterns MAKE developed, they had to add
> more and more
> mutability, and then a way to stop recursive evaliation, and more
> and more.

Realisitically include is already here with entities at the XML level and
people are using it. We won't prevent that. <include> just makes the include
operation more natural. Anyway, I don't see that include really changes the
property scoping issues. They really come into play at the <projectref>

> "." is very much use in current builds, I do not think it would be really
> such a good idea.

Agreed - so lets have some suggestions.

> I think that the rules need to allow for deferenciating between
> internal and
> public properties. Internal variables should always take their values from
> the project defining them. Public or parameters, take their values from
> their caller, and any local definition is considered a "default" value in
> case no value is passed. Without that we finish with a sort of gigantic
> globat name space very difficult to control in large projects.

Not sure about this concept. I'll give it some thought.


View raw message