ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 07:46:25 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> > -----Original Message-----
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> >
> > 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"/>
>
> or
>
> <antlib location="blahblah">
>    <classpath ...>
>    <import task="foo"/>
>    <import task="bar" alias="echo"/>
> </antlib>
>
> 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
> that?
>

Well I rather like the usage of lib="c.d.f.v" because it defines a name
space for libraries and it can help in resolving a lot of the issues of
conflicts.

One of my issues is for default behaviour to be expressable in whatever
language abstraction the users get. I believe that if you can expressed all
features just with the features you allow users to use then you are
providing a complete set.

So, can you express using <antlib> and <import> how the pre-install
(extensions) libraries will be loaded? Foe example can I say:

	<antlib>
		<fileset dir="${ant.home} >
		<include name="*.tsk">
		</fileset>
	</antlib>
	<import lib="ant.core"/>

If I could, that means we can express loading of libraries, as just the
default application of that XML fragment. It also means that we have a
presice semantics for how the default loading should work. If we change the
way <antlib> or <import> behave, this will also change as a concequence. And
so on...

So, can you propose a syntax that allows for expressing that? If oyu have it
then I guess that is good enough for me.

> >
> > 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>
> level.
>
> >
> > "." 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 posted some in my previous message. ;)
You could use ":" (I really do not see a problem), ">>", "^", "->" (which
are more like dereference operators. You may want to be able to say:
${A>>B>>C} for deep referencing of property "C" of project "B" on project
"C". :)

> >
> > 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.
>
> Conor
>


Mime
View raw message