You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/01/04 14:57:16 UTC
Antlib... when?
Any idea on when some sort of Antlib system will be setup?
The DiscoveryTask is a step in the right direction, but a much simpler
system without additional dependencies can be set up for a simple use-case.
Instead of loading "default" properties from a file in the ant.jar, we
can do it for all jars in ${ant.home}/lib. This would make it simple to
move the declarations out of the ant.jar and add "default" tasks to the run.
Could this be a simple option to use?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Nicola Ken Barozzi wrote:
>
>
>>>Nicola - you can just use taskdef with a resource parameter and define
>>>all the cents at once.
>>
>>Yup, but you still have to do it.
>>
>>I want to simply make the user add a <centipede/> tag in the buildfile,
>>but since it's not loaded, it cannot load others the way you say...
>>catch22.
>
>
> <project xmlns:cent="... " >
> <cent:centipeded/>
> ...
>
>
> Sounds simple enough.
>
> Or:
> <antlib name="org.krysalis.cents..."/>
> <centipede>
>
> One line (or ns ) describing the fact that the build file is using centipede
> is not too much to ask.
As always, actual code clears things: the above mechanisms seem just fine +1
Thanks for taking time to explain it to this point :-)
> BTW, centipede can define aditional antlibs if it wants ( I think it would
> be better to require the user to declare all libs it uses - like in XSTL or
> JSP - but it's your choice on what centipede does ).
Yes. We do it with <importcent/>, except the core tasks we load with
<centipede/>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Nicola Ken Barozzi wrote:
>> Nicola - you can just use taskdef with a resource parameter and define
>> all the cents at once.
>
> Yup, but you still have to do it.
>
> I want to simply make the user add a <centipede/> tag in the buildfile,
> but since it's not loaded, it cannot load others the way you say...
> catch22.
<project xmlns:cent="... " >
<cent:centipeded/>
...
Sounds simple enough.
Or:
<antlib name="org.krysalis.cents..."/>
<centipede>
One line (or ns ) describing the fact that the build file is using centipede
is not too much to ask.
BTW, centipede can define aditional antlibs if it wants ( I think it would
be better to require the user to declare all libs it uses - like in XSTL or
JSP - but it's your choice on what centipede does ).
> I need something to load automatically, or I'll have something like this:
>
> <import file="${ant.home}/src/core/xbuild.xml"/>
> <taskdef file="${ant.home}/src/core/tasks.properties"/>
>
> I have now made a Centipede task, but the best I can do is:
>
> <taskdef file="${ant.home}/src/core/tasks.properties"/>
> <centipede/> <!-- does the import -->
>
> After that I can import the "cents", but only after that.
>
>
http://cvs.apache.org/viewcvs/jakarta-poi/centibuild.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
>
>> Conor has a very good point - if you look at a buildfile you should
>> be able to tell what antlibs it is using.
>
> If they are non-core I agree. But let me define what is core.
> As Java can import anything and not use "namespace" on every class name
> with explicit import.
But you still need to do an explicit
import org.apache.tools.ant.*;
The only thing that is imported by default is java.lang - which is quite
small.
Antlib can do the same - either <antlib name="..."> or with xmlns.
>> If the build file doesn't specify what libs it needs - how could
>> you guess ? ( i.e. if a build is written under the assumption that
>> the antlibs exist already in ant/lib and no reference to the
>> name of the antlibs is made ).
>
> You are right, but I need to init the system. These "taglibs", that for
> us are cents, are downloaded by a task that we need to define. It would
> be nicer if it were already there. Not really necessary, but much nicer.
You just need to declare that you use centipede and add one extra line
( <cent:centipede> or <cent:init> ).
Maybe nicer without that - but not cleaner.
I see no problem with including an downloader in antlib - as Conor sugested.
But that's a different issue.
> I have worked with XML a lot, in Cocoon and now Forrest.
> Namespaces are ugly, hard to declare and make the xml files unreadable.
>
> Ant buildfiles are nice also because they don't use namespaces. Please,
> let's resort to them only if *really* necessary.
I agree. If you don't have name conflicts - you can just use
<antlib name="URL" />
If you have conflicts - or just like the ns syntax - you use it.
The best of both worlds.
> You don't normally use full packagename of the classes in your java
> files, don't you?
You do need to do the "import package.*". For ant we can have 2 choices:
either in xmlns or an explicit antlib with the URL.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Nicola Ken Barozzi wrote:
>
>
>>>>Any idea on when some sort of Antlib system will be setup?
>>>
>>>
>>>How is ant lib different from what krysalis does with cents
>>>http://krysalis.org/cents/
>>
>>Basically it makes Ant load *Tasks* without having to specify the name
>>and class in the buildfile. This for example can be used to
>>automatically load the <centipede/> task that automatically does
>>centipede init. Currently, we have to load it by a taskdef, with
>>explicit taskname.
>
>
> Nicola - you can just use taskdef with a resource parameter and define
> all the cents at once.
Yup, but you still have to do it.
I want to simply make the user add a <centipede/> tag in the buildfile,
but since it's not loaded, it cannot load others the way you say... catch22.
I need something to load automatically, or I'll have something like this:
<import file="${ant.home}/src/core/xbuild.xml"/>
<taskdef file="${ant.home}/src/core/tasks.properties"/>
I have now made a Centipede task, but the best I can do is:
<taskdef file="${ant.home}/src/core/tasks.properties"/>
<centipede/> <!-- does the import -->
After that I can import the "cents", but only after that.
http://cvs.apache.org/viewcvs/jakarta-poi/centibuild.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
> Conor has a very good point - if you look at a buildfile you should
> be able to tell what antlibs it is using.
If they are non-core I agree. But let me define what is core.
As Java can import anything and not use "namespace" on every class name
with explicit import.
> Either
> <antlib name="org.krysalis.cents" />
> or
> <project xmlns:cent="antlib:org.krysalis.cents" >
> <cent:foo ...>
>
>
>>Cents are still more than a taglib, because they also carry resources
>>and buildfiles to be imported. They are versioned and automatically
>>downloaded. And access all the info about the project that Centipede
>>loads from the Gump descriptor.
>
>
> That's even better. You could implement ComponentHelper and intercept
> the component creation and download missing antlibs, etc.
We did it without ComponentHelper and a <importcent/> task, that
downloads the file with vfs-using ruper, installs it, unpacks it,
imports the buildfile and loads the tasks. ComponentHelper could help in
making the download "lazy", but it already works well now.
> If the build file doesn't specify what libs it needs - how could
> you guess ? ( i.e. if a build is written under the assumption that
> the antlibs exist already in ant/lib and no reference to the
> name of the antlibs is made ).
You are right, but I need to init the system. These "taglibs", that for
us are cents, are downloaded by a task that we need to define. It would
be nicer if it were already there. Not really necessary, but much nicer.
I have worked with XML a lot, in Cocoon and now Forrest.
Namespaces are ugly, hard to declare and make the xml files unreadable.
Ant buildfiles are nice also because they don't use namespaces. Please,
let's resort to them only if *really* necessary.
You don't normally use full packagename of the classes in your java
files, don't you?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Nicola Ken Barozzi wrote:
>>> Any idea on when some sort of Antlib system will be setup?
>>
>>
>> How is ant lib different from what krysalis does with cents
>> http://krysalis.org/cents/
>
> Basically it makes Ant load *Tasks* without having to specify the name
> and class in the buildfile. This for example can be used to
> automatically load the <centipede/> task that automatically does
> centipede init. Currently, we have to load it by a taskdef, with
> explicit taskname.
Nicola - you can just use taskdef with a resource parameter and define
all the cents at once.
Conor has a very good point - if you look at a buildfile you should
be able to tell what antlibs it is using.
Either
<antlib name="org.krysalis.cents" />
or
<project xmlns:cent="antlib:org.krysalis.cents" >
<cent:foo ...>
> Cents are still more than a taglib, because they also carry resources
> and buildfiles to be imported. They are versioned and automatically
> downloaded. And access all the info about the project that Centipede
> loads from the Gump descriptor.
That's even better. You could implement ComponentHelper and intercept
the component creation and download missing antlibs, etc.
If the build file doesn't specify what libs it needs - how could
you guess ? ( i.e. if a build is written under the assumption that
the antlibs exist already in ant/lib and no reference to the
name of the antlibs is made ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nick Chalko wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Any idea on when some sort of Antlib system will be setup?
>
>
> How is ant lib different from what krysalis does with cents
> http://krysalis.org/cents/
Basically it makes Ant load *Tasks* without having to specify the name
and class in the buildfile. This for example can be used to
automatically load the <centipede/> task that automatically does
centipede init. Currently, we have to load it by a taskdef, with
explicit taskname.
Cents are still more than a taglib, because they also carry resources
and buildfiles to be imported. They are versioned and automatically
downloaded. And access all the info about the project that Centipede
loads from the Gump descriptor.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nick Chalko <ni...@chalko.com>.
Nick Chalko wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Any idea on when some sort of Antlib system will be setup?
>
>
> How is ant lib different from what krysalis does with cents
> http://krysalis.org/cents/
>
>>
>> The DiscoveryTask is a step in the right direction, but a much
>> simpler system without additional dependencies can be set up for a
>> simple use-case.
>>
>> Instead of loading "default" properties from a file in the ant.jar,
>> we can do it for all jars in ${ant.home}/lib. This would make it
>> simple to move the declarations out of the ant.jar and add "default"
>> tasks to the run.
>
I understand why you want this.
It is a simple solution to the simple use case. I think it is a good start.
>>
>> Could this be a simple option to use?
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Any idea on when some sort of Antlib system will be setup?
How is ant lib different from what krysalis does with cents
http://krysalis.org/cents/
>
> The DiscoveryTask is a step in the right direction, but a much simpler
> system without additional dependencies can be set up for a simple
> use-case.
>
> Instead of loading "default" properties from a file in the ant.jar, we
> can do it for all jars in ${ant.home}/lib. This would make it simple
> to move the declarations out of the ant.jar and add "default" tasks to
> the run.
>
> Could this be a simple option to use?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
I was going to open the same subject next week :-)
I hope people have returned from vacation and will start reviewing
PropertyHelper. Even if not perfect, I think it is a move in the
right direction. One important thing is that now property management
is centralized in PH - instead of Project.
One thing I would like ( based on the early experiment on embed ) is
do the same thing with ComponentHelper.
I can check in the current version - i.e. a cut&paste of all component
( task, type ) management code from Project, plus simple hooks to
allow ComponentHelpers to be chained.
This by itself doesn't solve the antlib problem - it just provides a
hook that people may use. We still need to agree on one ( or few )
mechanisms for antlib that will be the "official" antlib.
I think the DiscoveryTask was a good idea, but not good enough. It
is still a bit too complex.
I think properties are simple and commonly used in defining collections
of tasks ( using taskdef resource=...). One very simple extension
would be:
<project xmlns:jmx="ant:org.apache.commons.modeler.ant" >
<jmx:mlet ... />
<jmx:attribute ... />
...
A ns with ant: prefix will just load an ant.properties from the given
package. If not found - it may look in a catalog and download it, or
any other advanced thing.
Other ns URLs could be supported as well, but IMO this is simple
enough to work :-)
I'm open to any alternative mechanism(s), but I really want to keep
the 2 issues separated, and to first resolve the hook.
Costin
Nicola Ken Barozzi wrote:
>
> Any idea on when some sort of Antlib system will be setup?
>
> The DiscoveryTask is a step in the right direction, but a much simpler
> system without additional dependencies can be set up for a simple
> use-case.
>
> Instead of loading "default" properties from a file in the ant.jar, we
> can do it for all jars in ${ant.home}/lib. This would make it simple to
> move the declarations out of the ant.jar and add "default" tasks to the
> run.
>
> Could this be a simple option to use?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Christopher Lenz wrote:
> Nicola Ken Barozzi wrote:
>
>> Conor MacNeill wrote:
>>
>>> Christopher Lenz wrote:
>>>
>>>> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in
>>>> META-INF (for example; be it some XML format or a properties file),
>>>> and that descriptor would contain a URI that needs to be used as XML
>>>> namespace URI in the build file.
>>>>
>>>> Hope I'm not totally off here... haven't followed much of the
>>>> discussion before this thread.
>>>
>>>
>>> No, spot on - that is what I had in mind.
>>
>>
>> I think too that this is the way, just with a change:
>>
>> - Automatic antlib loads in ant.home/lib would be without namespace,
>> as they are treated as "default" ones.
>
>
> Not sure.
>
> Rather than adding an additional "ext" dir to separate between the
> default antlibs (i.e. the set of tasks distributed with Ant) and
> external antlibs, why not have all default antlibs specify
> "http://ant.apache.org/" (for example) as their namespace URI. That
> would be the default namespace for buildfiles, of course.
>
> External antlibs could still be placed in $ANT_HOME/lib, but would
> specify a different namespace URI in their descriptor.
>
> Am I missing something?
Technically you are correct. MHO is that putting them in phisically
different dirs is more evident to the users.
"This goes here, that goes there."
Just a possibility.
>> - Normal taskdef would be without namespace.
>
> It'd be nice to be able to import "legacy" tasks into a namespace
> specified in the <taskdef>, though. Not sure how this would work, and
> it's not very important either ;-)
>
>> - <antlib> call would be with namespace.
>
> Hmm.. can't parse this.. can you elaborate?
If I load tasks from an antlib, they get loaded with the namespace. The
above to cases are about implicit loading, by putting jars in special
dirs, this is about asking for it explicitly in the buildfile.
>> - We can add a ant.home/ext dir where antlib loads *with* namespace
>>
>> As for a descriptor, being a Cocoon developer, and having used xml for
>> so much time, I can only suggest... not to use it, simple properties
>> like now is just good enough, just add a namespace property as
>> suggested above. :-)
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Christopher Lenz <cm...@gmx.de>.
Nicola Ken Barozzi wrote:
> Conor MacNeill wrote:
>> Christopher Lenz wrote:
>>> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in
>>> META-INF (for example; be it some XML format or a properties file),
>>> and that descriptor would contain a URI that needs to be used as XML
>>> namespace URI in the build file.
>>>
>>> Hope I'm not totally off here... haven't followed much of the
>>> discussion before this thread.
>>
>> No, spot on - that is what I had in mind.
>
> I think too that this is the way, just with a change:
>
> - Automatic antlib loads in ant.home/lib would be without namespace, as
> they are treated as "default" ones.
Not sure.
Rather than adding an additional "ext" dir to separate between the
default antlibs (i.e. the set of tasks distributed with Ant) and
external antlibs, why not have all default antlibs specify
"http://ant.apache.org/" (for example) as their namespace URI. That
would be the default namespace for buildfiles, of course.
External antlibs could still be placed in $ANT_HOME/lib, but would
specify a different namespace URI in their descriptor.
Am I missing something?
> - Normal taskdef would be without namespace.
It'd be nice to be able to import "legacy" tasks into a namespace
specified in the <taskdef>, though. Not sure how this would work, and
it's not very important either ;-)
> - <antlib> call would be with namespace.
Hmm.. can't parse this.. can you elaborate?
> - We can add a ant.home/ext dir where antlib loads *with* namespace
>
> As for a descriptor, being a Cocoon developer, and having used xml for
> so much time, I can only suggest... not to use it, simple properties
> like now is just good enough, just add a namespace property as suggested
> above. :-
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Nicola Ken Barozzi wrote:
>>> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in
>>> META-INF (for example; be it some XML format or a properties file),
>>> and that descriptor would contain a URI that needs to be used as XML
>>> namespace URI in the build file.
>>>
>>> Hope I'm not totally off here... haven't followed much of the
>>> discussion before this thread.
>>>
>>
>> No, spot on - that is what I had in mind.
That's what I had in mind too ( or close enough :-).
I was just describing it in reverse - you look in build.xml, see a
namespace URI ( or an <antlib name=> ) and you locate the descriptor
using a resource derived from the URI.
JSP are similar - you need to declare all taglibs that you use in
the jsp page. Same for XSLT - where all extension elements/functions
you use must be declared.
One important issue - if you don't have the antlib, you obviously
don't have the descriptor either. So the info about where to download
must be derived from the URI - either using an indirect catalog or
just using the URI as a base for lookup.
We can have the URI carry both informations ( descriptor location
in the jar and URL for download ) - just use an encoded form of the
URL as the resource path.
> I think too that this is the way, just with a change:
>
> - Automatic antlib loads in ant.home/lib would be without namespace,
> as they are treated as "default" ones.
I think both Conor and me are disagreeing with you on this one.
XSLT, JSP, etc are all requiring some explicit information about what
antlibs you need - otherwise a user who doesn't have the jars in ant/lib
will have no way to guess what is wrong and what .jar he has to install.
> - Normal taskdef would be without namespace.
I.e backward compat - that's clear. If you mean: you should be able to use
taskdef for antlibs - I agree.
> - <antlib> call would be with namespace.
Unless <taskdef> is used to load the antlib - which will work like it does
today.
> As for a descriptor, being a Cocoon developer, and having used xml for
> so much time, I can only suggest... not to use it, simple properties
> like now is just good enough, just add a namespace property as suggested
> above. :-)
I agree - keep the simple properties for the simple case ( i.e. what we
need today ), and eventually use an XML descriptor for advanced features.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Conor MacNeill wrote:
> Christopher Lenz wrote:
>
>>
>> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in
>> META-INF (for example; be it some XML format or a properties file),
>> and that descriptor would contain a URI that needs to be used as XML
>> namespace URI in the build file.
>>
>> Hope I'm not totally off here... haven't followed much of the
>> discussion before this thread.
>>
>
> No, spot on - that is what I had in mind.
I think too that this is the way, just with a change:
- Automatic antlib loads in ant.home/lib would be without namespace,
as they are treated as "default" ones.
- Normal taskdef would be without namespace.
- <antlib> call would be with namespace.
- We can add a ant.home/ext dir where antlib loads *with* namespace
As for a descriptor, being a Cocoon developer, and having used xml for
so much time, I can only suggest... not to use it, simple properties
like now is just good enough, just add a namespace property as suggested
above. :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Christopher Lenz wrote:
>
> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in META-INF
> (for example; be it some XML format or a properties file), and that
> descriptor would contain a URI that needs to be used as XML namespace
> URI in the build file.
>
> Hope I'm not totally off here... haven't followed much of the discussion
> before this thread.
>
No, spot on - that is what I had in mind.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Christopher Lenz <cm...@gmx.de>.
Hi all,
jumping in...
Conor MacNeill wrote:
> Costin Manolache wrote:
>> 3. If you don't need namespaces, you'll not have to use them. I.e. if you
>> have a simple project and use few libs - you can still use the simpler
>> syntax.
>
> what is the "simpler syntax"? You mean no namespace qualifiers? How do
> you see both these mechanisms working at once? - defining all tasks in
> the default namespace and ignoring collisions?
>
> This means the build file depends on the user's config to some extent.
> One user has no colision and uses <deploy> whilst another does and get
> the wrong <deploy> defined first. Not sure this is good.
I would say that tasks defined "behind the scenes" through the antlib
mechanism should always be defined in namespaces. However, users can
still define tasks manually using <taskdef>, and such tasks will by
default be available in the default namespace - this would provide the
required backwards compatibility, and users who don't want to deal with
namespaces just need to <taskdef> all required tasks manually.
I agree that antlib defining external tasks in the default namespace is
not a good idea.
>> The xmlns syntax is well defined - the only issue is the semantics of the
>> URI. Some people have strong opinions on that. My (strong:-)
>> preference is for a URI that does have some semantics - i.e. it can be
>> resolved to a java package. Some form of catalog can resolve this to
>> URLs or something
>> else.
>
> We need to have some mechanism to match the URI to a jar, whatever the
> URI format is. At this stage my pref would be to use a standard HTTP URL
> from which the library may be downloaded (not necessarily directly).
Why not use a mechanism similar to JSP1.2 taglibs?
Every JAR in $ANT_HOME/lib would be scanned for a descriptor in META-INF
(for example; be it some XML format or a properties file), and that
descriptor would contain a URI that needs to be used as XML namespace
URI in the build file.
Hope I'm not totally off here... haven't followed much of the discussion
before this thread.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
[...]
> The behavior will be to load the tasks just like today, and eventually
> generate errors on name conflicts ( with a message that if you have
> conflicts you must use namespaces - you are no longer in the "simple"
> case ).
+1
simple and effective IMHO
>>This means the build file depends on the user's config to some extent. One
>>user has no colision and uses <deploy> whilst another does and get the
>>wrong <deploy> defined first. Not sure this is good.
>
>
> Yes, if the user has a simple config with non-conflicting antlibs - he'll
> have a simpler build file. He'll still declare what antlibs it uses, and
> if we detect a conflict we can inform him that the simple times have ended
> and he must use namespaces ( at least for the antlibs with conflicts ).
Yup.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Conor MacNeill wrote:
>> 3. If you don't need namespaces, you'll not have to use them. I.e. if you
>> have a simple project and use few libs - you can still use the simpler
>> syntax.
>
> what is the "simpler syntax"? You mean no namespace qualifiers? How do you
> see both these mechanisms working at once? - defining all tasks in the
> default namespace and ignoring collisions?
The current syntax, with no namespaces. Just define the tasks with
<taskdef resource="my/antlib/package/ant.properties />
or some new
<antlib name="my.antlib.package" />
The behavior will be to load the tasks just like today, and eventually
generate errors on name conflicts ( with a message that if you have
conflicts you must use namespaces - you are no longer in the "simple"
case ).
> This means the build file depends on the user's config to some extent. One
> user has no colision and uses <deploy> whilst another does and get the
> wrong <deploy> defined first. Not sure this is good.
Yes, if the user has a simple config with non-conflicting antlibs - he'll
have a simpler build file. He'll still declare what antlibs it uses, and
if we detect a conflict we can inform him that the simple times have ended
and he must use namespaces ( at least for the antlibs with conflicts ).
>> The xmlns syntax is well defined - the only issue is the semantics of the
>> URI. Some people have strong opinions on that. My (strong:-) preference
>> is for a URI that does have some semantics - i.e. it can be resolved to
>> a java package. Some form of catalog can resolve this to URLs or
>> something else.
>>
>
> We need to have some mechanism to match the URI to a jar, whatever the URI
> format is. At this stage my pref would be to use a standard HTTP URL from
> which the library may be downloaded (not necessarily directly).
That's a good option too.
What about combining the 2 variants. My proposal was to use the URI to
identify the package, and use this to load the descriptor ( assuming
the jar is available and a catalog can help the download ).
We can use the URL, and require that each jar includes a
META-INF/ant/ENCODED_URL resource for the descriptor. This way you
have a simple way to match the URL against a .properties ( or .xml )
descriptor, without extra config ( catalog, etc ) or net access.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Costin Manolache wrote:
>
> My 'itch' is to have pluggable support for component creation. If nobody
> -1 the ComponentHelper - then any antlib can be implemented as an
> optional task. I'll probably be ok with any "official" solution ( if
> it isn't too complex ), and probably I'll do my own experiments.
>
> Having a simple ComponentHelper plugin that uses the XML namespace to
> load a simple properties descriptor is one reasonable solution. Certainly
> not the only one.
>
>
I'll check it out.
>
> 1. If a namespace will be used to resolve conflicts - it will be XML
> namespace ( i.e. we won't invent our own ).
>
Ok, +1, let's use XML namespace to define task/type namespace.
> 2. Existing files will not have to change. ( i.e. the default namespace
> will be used for the core tasks ).
Obviously :-) +1
>
> 3. If you don't need namespaces, you'll not have to use them. I.e. if you
> have a simple project and use few libs - you can still use the simpler
> syntax.
what is the "simpler syntax"? You mean no namespace qualifiers? How do you
see both these mechanisms working at once? - defining all tasks in the
default namespace and ignoring collisions?
This means the build file depends on the user's config to some extent. One
user has no colision and uses <deploy> whilst another does and get the wrong
<deploy> defined first. Not sure this is good.
>
> The xmlns syntax is well defined - the only issue is the semantics of the
> URI. Some people have strong opinions on that. My (strong:-) preference is
> for a URI that does have some semantics - i.e. it can be resolved to
> a java package. Some form of catalog can resolve this to URLs or something
> else.
>
We need to have some mechanism to match the URI to a jar, whatever the URI
format is. At this stage my pref would be to use a standard HTTP URL from
which the library may be downloaded (not necessarily directly).
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Conor MacNeill wrote:
> Costin Manolache wrote:
>>
>>
>> But we have namespace support now ! :-)
>
> You mean XML namespace support? That is (potentially) different from the
> task/type namespace. Perhaps XML namespace can be used for task
> resolution. It has been mooted in the past for other roles (identification
> of aspects, such as a documentation aspect). We probably need some
> agreement on how/if to use XML namespaces in Ant.
My 'itch' is to have pluggable support for component creation. If nobody
-1 the ComponentHelper - then any antlib can be implemented as an
optional task. I'll probably be ok with any "official" solution ( if
it isn't too complex ), and probably I'll do my own experiments.
Having a simple ComponentHelper plugin that uses the XML namespace to
load a simple properties descriptor is one reasonable solution. Certainly
not the only one.
>> And naming collision was allwasy a possiblity with taskdef.
>
> Indeed. Every time we change defaults.properties we can cause people to
> have to rewrite their build files to avoid the collision. It may even
> break existing build files, I'm not sure. This problem is much smaller
> than the problem that will exist when we provide an Antlib concept. IOW, I
> don't think we can argue that the pre-existence of a problem allows us to
> neglect that problem in the future.
My point was that naming conflicts are not the biggest problem we are
facing.
The only way I know to avoid naming conflicts is to use a namespace. Not
using the XML namespace if we do need a namespace ( and inventing our own )
would be a very bad idea IMO.
I don't think that the antlib concept will directly increase the number
of tasks or the likelyhood of conflicts.
Renaming tasks is a very different issue. Renaming existing tasks is yet
another issue ( and see no reason for it to happen - I think we agree on
this).
> When we have antlibs, I expect people and companies to start shipping
> antlibs. Let's say, for example, that tomcat and an app server provider
> both
> ship antlibs and both provide a <deploy> task. How can I use those
> tasks?
> If you believe this can be supported through XML namespaces, we need to
> work out what the build file looks like for that, I think.
How is that different from tomcat shiping a properties file ( and using
taskdef resource=... ) ? People and companies are already shipping
ant tasks and libs.
If we want to use XML namespaces to reduce the chance of conflicts - and
this can be optional, so "simple" build files will not have to do it -
then the syntax is pretty clear.
<project xmlsns:tomcat="...." >
<tomcat:deploy ... >
I don't see too many choices for that ( the URL of the NS is the only
big issue ).
Do you see any other option on resolving name conflicts in
xml files ?
> Let's talk about what the build file looks like and work from there.
I think we should agree on some basic issues:
1. If a namespace will be used to resolve conflicts - it will be XML
namespace ( i.e. we won't invent our own ).
2. Existing files will not have to change. ( i.e. the default namespace
will be used for the core tasks ).
3. If you don't need namespaces, you'll not have to use them. I.e. if you
have a simple project and use few libs - you can still use the simpler
syntax.
The xmlns syntax is well defined - the only issue is the semantics of the
URI. Some people have strong opinions on that. My (strong:-) preference is
for a URI that does have some semantics - i.e. it can be resolved to
a java package. Some form of catalog can resolve this to URLs or something
else.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Costin Manolache wrote:
>
>
> But we have namespace support now ! :-)
You mean XML namespace support? That is (potentially) different from the
task/type namespace. Perhaps XML namespace can be used for task resolution.
It has been mooted in the past for other roles (identification of aspects,
such as a documentation aspect). We probably need some agreement on how/if
to use XML namespaces in Ant.
> And naming collision was allwasy a possiblity with taskdef.
Indeed. Every time we change defaults.properties we can cause people to have
to rewrite their build files to avoid the collision. It may even break
existing build files, I'm not sure. This problem is much smaller than the
problem that will exist when we provide an Antlib concept. IOW, I don't
think we can argue that the pre-existence of a problem allows us to neglect
that problem in the future.
When we have antlibs, I expect people and companies to start shipping
antlibs. Let's say, for example, that tomcat and an app server provider both
ship antlibs and both provide a <deploy> task. How can I use those tasks?
If you believe this can be supported through XML namespaces, we need to work
out what the build file looks like for that, I think.
>
>
>>Further I believe build files should make explicit the libraries/tasks
>>they depend on. IMHO, we don't want to tie a build file's operation to the
>
>
> That's a very good poing, I agree. That's why I think using the ns is a good
> idea.
>
>
>
>>So, for me two requirements for antlib
>>1. Global management of task names, handling name collisions, name
>>resolution, aliasing, etc.
>
>
> I'm not sure I understand what you mean - or if NS would cover your
> requirement.
>
Let's talk about what the build file looks like and work from there.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Costin Manolache <cm...@yahoo.com>.
Conor MacNeill wrote:
>> Instead of loading "default" properties from a file in the ant.jar, we
>> can do it for all jars in ${ant.home}/lib. This would make it simple to
>> move the declarations out of the ant.jar and add "default" tasks to the
>> run.
>>
>> Could this be a simple option to use?
>>
>
> The problem I see with this approach relates to management of task names.
> By removing the management of task names from the properties file in
> ant.jar you open up the system to issues such as task name collisions.
> IOW, since the naming of tasks is no longer under centralized control (ie.
> as defined in Ant's CVS), something needs to be done to manage a
> distributed task namespace.
But we have namespace support now ! :-)
And naming collision was allwasy a possiblity with taskdef.
> Further I believe build files should make explicit the libraries/tasks
> they depend on. IMHO, we don't want to tie a build file's operation to the
That's a very good poing, I agree. That's why I think using the ns is a good
idea.
> So, for me two requirements for antlib
> 1. Global management of task names, handling name collisions, name
> resolution, aliasing, etc.
I'm not sure I understand what you mean - or if NS would cover your
requirement.
> 2. Declaration of library/task dependencies in build file.
+1
I would add:
3. Easy to develop simple task library ( i.e. a simple properties should
work - even if we support more fancy XML descriptors )>
4. Like in other areas of ant - the system should be flexible and allow
future enhancements.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Jeff Turner <je...@apache.org>.
On Sun, Jan 05, 2003 at 02:18:15AM +1100, Conor MacNeill wrote:
...
> Further I believe build files should make explicit the libraries/tasks they
> depend on. IMHO, we don't want to tie a build file's operation to the
> current user's config. Someone reading the build file should understand
> what libraries they need to provide in their Ant configuration to use the
> build file. It should not have to be a set of guess/try/fail cycles.
Sounds good. It would be nice to be able to declare a dep on a certain
Ant version too, so people running Ant 1.5 scripts with Ant 1.4 get a
user-defined error. It can probably be done as a task. I coded up a
system like this for an Ant-based HTTP testing framework:
<uses version="0.9.14">
<feature name="jelly"/>
<feature name="xhtml-schema"/>
</uses>
http://aft.sourceforge.net/manual/Auxiliary%20tasks.html#N10280
An Ant equivalent of xsl:fallback would be neat too =)
--Jeff
> So, for me two requirements for antlib
> 1. Global management of task names, handling name collisions, name
> resolution, aliasing, etc.
>
> 2. Declaration of library/task dependencies in build file.
>
> Thoughts?
>
> Conor
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Nicola Ken Barozzi wrote:
>
> Any idea on when some sort of Antlib system will be setup?
>
I believe Ant 1.6 should contain some form of antlib functionality. MHO.
> Instead of loading "default" properties from a file in the ant.jar, we
> can do it for all jars in ${ant.home}/lib. This would make it simple to
> move the declarations out of the ant.jar and add "default" tasks to the
> run.
>
> Could this be a simple option to use?
>
The problem I see with this approach relates to management of task names. By
removing the management of task names from the properties file in ant.jar
you open up the system to issues such as task name collisions. IOW, since
the naming of tasks is no longer under centralized control (ie. as defined
in Ant's CVS), something needs to be done to manage a distributed task
namespace.
For example, if two jars in ANT_HOME/lib both define a <fubar> task, which
do you use?
Further I believe build files should make explicit the libraries/tasks they
depend on. IMHO, we don't want to tie a build file's operation to the
current user's config. Someone reading the build file should understand what
libraries they need to provide in their Ant configuration to use the build
file. It should not have to be a set of guess/try/fail cycles.
So, for me two requirements for antlib
1. Global management of task names, handling name collisions, name
resolution, aliasing, etc.
2. Declaration of library/task dependencies in build file.
Thoughts?
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Antlib... when?
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Just for the record, I'm working on XDoclet subtasks at the moment and
refactoring the proposal/xdocs stuff and migrating it to live within
the XDoclet codebase. This will allow third-party task writers to use
XDoclet and generate "descriptors" for their tasks/datatypes easily.
The descriptors are currently planned for documentation, but have use
for part of this discovery mechanism as well as for IDE's and other
tools that wrap Ant to learn about what the tasks/types support by
looking at the embedded descriptors.
How shall we compare notes and see if what I'm doing applies to Antlib
needs? I'll hopefully be committing my stuff into XDoclet's CVS soon.
Its taken me a while to get it converted to the new XDoclet API and get
back into the swing of things with it, my apologies. But I'm now
actively working on it and progress is being made by the minute.
Erik
On Saturday, January 4, 2003, at 08:57 AM, Nicola Ken Barozzi wrote:
>
> Any idea on when some sort of Antlib system will be setup?
>
> The DiscoveryTask is a step in the right direction, but a much simpler
> system without additional dependencies can be set up for a simple
> use-case.
>
> Instead of loading "default" properties from a file in the ant.jar, we
> can do it for all jars in ${ant.home}/lib. This would make it simple
> to move the declarations out of the ant.jar and add "default" tasks to
> the run.
>
> Could this be a simple option to use?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>