You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jon Stevens <jo...@latchkey.com> on 2000/12/10 22:15:19 UTC
[PROPOSAL] Optional Tasks
I'm still not sure what version of Ant this should apply to, but lets get
the proposal written before I spend a whole bunch more time justifying
myself for my reasons. I see a lot of people still not "getting it" so I
hope to have a proposal to clarify things for people.
Here are the rules to the proposal:
-----------------------------------------------------------------
The definition of a "core" task is a task that Ant really cannot live
without. This would be similar to taglibs that are part of the core JSP
specification.
The definition of an "optional" task is a task that really should be
packaged with the product it serves.
However, there are cases where this is not feasible. Therefore, we will
provide a separate CVS repository and mailing lists that serve as a storage
and support area for tasks that cannot be bundled with the original
products. Such as a perforce task. This would be similar to the taglibs
Jakarta Project.
-----------------------------------------------------------------
thanks,
-jon
RE: [PROPOSAL] Optional Tasks
Posted by Peter Donald <do...@apache.org>.
At 12:02 11/12/00 +1100, Conor MacNeill wrote:
>One thing which I would like some thought on is the situation where we have
>a task which defines an "interface" and for which there may be many
>implementations. A current example would be the <ejbjar> task which really
>defines an interface into which specific EJB deployment tools can be plugged
>in (as nested elements).
Very kewl idea. I would like to see it done in a way similar to how Sockets
are abstracted. By doing it this way we make sure that no implementations
behind facade offer further services. ie I would hate it if suddenly
javac/jikes/jcv/whatever started to become incompatable with each other
because the task authors decided to allow extra task specific sub-tags.
We could provide a controlled mechanism for extentions/added
sub-elements/attributes thou. These would be ignored if task not recognizes
them.
>Another candidate is the <javac> task itself. The current mess of supporting
>many compiler variations is not really nice. I would like to see a mechanism
>where different compilers could be plugged in. In fact such a system would
>allow the Jikes implementation to be moved out of the core and into the
>Jikes project.
Naah that would suck. Jikes does not have any java parts in project and
when distributed rarely comes with source/whatever. It would be hell for
some developers to get jikes to work in an environment like that.
>In summary, I think there are cases where it would be nice to define a
>common "interface" for a task and allow different implementations for this
>task. I don't want to lose sight of that unified approach because the
>optional tasks are scattered over the net.
agreed.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Optional Tasks
Posted by Peter Donald <do...@apache.org>.
At 11:12 12/12/00 +0100, Nico Seessle wrote:
>----- Original Message -----
>From: "Stefan Bodewig" <bo...@apache.org>
>To: <an...@jakarta.apache.org>
>Sent: Tuesday, December 12, 2000 9:57 AM
>Subject: Re: [PROPOSAL] Optional Tasks
>
>
>> BTW it's not just James who was going to add this feature (task
>> deployment via JAR files) for Ant 2, it has been specced before and
>> Pete's proposal implements it as well 8-)
>
>And when do we know which of this proposals will become 2.0?
we won't for a while. I suspect it will be an amalgam of the proposals thou
I guess only time will tell.
>Does it make
>any sense to implement/post/deliver something like this on the 1.2 codebase?
If we can do it without breaking any current build files and not placing
unreasonable expectations on Ant2.0 then I say +1 ;) By "unreasonable
expectations" I mean any behaviour that we will end up having to support in
Ant2.0 must not be too divergent to proposals or must be clearly marked as
VOLATILE or something like that.
Didn't you post some patches ages ago that did just that ? ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Optional Tasks
Posted by Nico Seessle <Ni...@epost.de>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Tuesday, December 12, 2000 9:57 AM
Subject: Re: [PROPOSAL] Optional Tasks
> BTW it's not just James who was going to add this feature (task
> deployment via JAR files) for Ant 2, it has been specced before and
> Pete's proposal implements it as well 8-)
And when do we know which of this proposals will become 2.0? Does it make
any sense to implement/post/deliver something like this on the 1.2 codebase?
Nico
Re: [PROPOSAL] Optional Tasks
Posted by Stefan Bodewig <bo...@apache.org>.
Jon Stevens <jo...@latchkey.com> wrote:
> The definition of a "core" task is a task that Ant really cannot
> live without. This would be similar to taglibs that are part of the
> core JSP specification.
>
> The definition of an "optional" task is a task that really should be
> packaged with the product it serves.
>
> However, there are cases where this is not feasible. Therefore, we
> will provide a separate CVS repository and mailing lists that serve
> as a storage and support area for tasks that cannot be bundled with
> the original products.
And then there is a bunch of tasks that are not needed to build Ant
and that are not related to a specific product either. <rmic>, <war>,
<exec>, <native2ascii> and so on. They should go into the repository
of optional tasks as well.
So if we can clarify the definition of what goes into the separate
repository, that's fine with me.
As Ant 1.x won't gain the ability of easy deployment of task libraries
this (moving out tasks from Ant's repository into a separate one) is
one of the migration steps for Ant2. Should we stop accepting any new
tasks until Ant 2 is there?
BTW it's not just James who was going to add this feature (task
deployment via JAR files) for Ant 2, it has been specced before and
Pete's proposal implements it as well 8-)
Stefan
Re: [PROPOSAL] Optional Tasks
Posted by Louis Tribble <lo...@metamata.com>.
Conor MacNeill wrote:
> I am cool with this idea. Maybe we can call the project "antlibs" :-)
Or "antnest"?
Louis
RE: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
On Mon, 11 Dec 2000, Peter Donald wrote:
> I am not sure that all of these should be hidden behind a facade. It makes
> sense because a developer can easily swap between jikes, javac or other
> compilers.
>
> However javacc type tasks are not something the developer can switch
> between easily. It may make sense for them all to have similar form and
> perhaps inherit from a base class but a developer is unlikely to switch
> parser generators that willy nilly - and switching would require other
> changes in their code.
True, but I still think, it would be better to have smaller
number of highly parametrized tasks, than many simple, in
many cases repeating the same attributes and parameters
tasks with task-per-tool model. If I am a developer, who needs task
supporting tool A, which is an EJB container, compiler compiler or jidl
compiler, I just go the the proper section of ANT docs, about jidl
compilers, check my tool is suported there, and how or where to get
optional task jar for for jidl task to support apropriate tool.
Otherwise, we not only risk duplicating code for tasks (which as you said
could be solved by base class or whatever) but also risk repeating
documentation, and making it hard for users to use and manage it all.
I fully agree, that tool specific things are always different, but jidl
always takes the .idl files and generate stubs and skeletons, so, it
depends where we would like to put the granularity - on the task-logic, or
on the tool-implementation? To me puting on the task-logic would be
nicer, and promote reuse of: base class, helper classes, documentation,
task syntax and semantics. It is true, javacc task for metamata cannot be
as easily swapped for antlr, as jikes and javac for javac, nevertheless,
javacc always do the same thing: takes grammar and generates parser, and
logically it should be always the same, parametrized task. If one
asks: 'does ant supports parser generators' we say: yes, use javacc task.
if one asks: 'does ant supports tool A which is idl compiler' we
say: check idl compilers section. Otherwise we always need to now the
tool, and always have to point to a particular ant task for info.
> I know my opinions are probably different from most but ... I have
> experienced all sorts of pain when there was no centralized repository. If
> any of you have ever tried to get mixed version of elisp scripts to work
> then you porobably know what I mean.
>
> [...]
>
> I agree that it may place a bit of extra work on ant-dev but if we place
> them in a contrib place and effectively say unsupported then it should be
> sweet. Ant-dev will only have to maintain them when they break the contract
> between tasks and container (and perhaps other obvious errors). The "work"
> done by task is maintained by outsiders who can send patches to
> ant-lib/ant-contrib. This way when an outsider abandons a task - or
> continues to use the task at a lower version of ant it still can be adopted
> by someone else.
Sure. I support central repository as well, but, I think, task
contributors, at least, now, and for comming future, could help by direct
supporting their own tasks, writting docs, etc. True, it can be done in a
'send-patch-we-will-do-it' model, but it takes time, and it puts
additional pressure on ant commiters. Optional tasks are not part of ANT
core, and could be managed by their contributors - sure, ant commiters
could help, could take care of abandoned tasks, and coordinate all the
optional task business, but giving more direct control on optional tasks
to ppl would only help, I think. It seems to me simpler, to keep my own
tasks repo locally, patch it, play with it, and commit it, instead of
keep my own tasks repo locally, patch it, play with it, checkout latest
ANT, prepare patch, send the patch, wait, checkout applied patch, merge
the differences, write docs, prepare the patch, send the patch, wait,
checkout patched docs, merge the differences, repeat the above loop every
now and than when external project evolves.
regards
Mariusz
RE: [PROPOSAL] Optional Tasks
Posted by Peter Donald <do...@apache.org>.
At 02:32 11/12/00 +1300, Mariusz Nowostawski wrote:
>
>javac - java compiler
> (classic, modern, jikes, others)
>
>javacc - java compiler compiler (parser generator)
> (metamata, antlr, sablecc, others)
>jidl - idl stubs/skeletons generator
> (java2 jidl, many others in java and native)
>ejbjar - enterprise beans packager (with configuration)
> (weblogic, ias, jboss, many others)
I am not sure that all of these should be hidden behind a facade. It makes
sense because a developer can easily swap between jikes, javac or other
compilers.
However javacc type tasks are not something the developer can switch
between easily. It may make sense for them all to have similar form and
perhaps inherit from a base class but a developer is unlikely to switch
parser generators that willy nilly - and switching would require other
changes in their code.
With respect to the ejbjar* and idl* type tasks I think there is a similar
case. Last time I checked these sort of things were container specific and
thus not really easy to switch between. However it would be good for them
to have similar form and perhaps inherit from a base class ?
>> In summary, I think there are cases where it would be nice to define a
>> common "interface" for a task and allow different implementations for this
>> task. I don't want to lose sight of that unified approach because the
>> optional tasks are scattered over the net.
>
>But should those "interfaces" being kept in ANT core, or should they be
>kept in seperate, optional tasks repository? For javac, it should be kept
>in the core, but what about others? There is not that many of them, at the
>moment which needs to have unified "interface", so maybe that should be
>part of the core, and then, all the optional tasks can be scattered over
>the places, and there would be no need for a repository of optional tasks?
>But it puts some additional work on jakarta-ant commiters.
I know my opinions are probably different from most but ... I have
experienced all sorts of pain when there was no centralized repository. If
any of you have ever tried to get mixed version of elisp scripts to work
then you porobably know what I mean.
Other examples may be difference between FreeBSD and Linux distributions. I
use Linux and very commonly go through hell trying to get all versions
matching between RPMs of required tools at required version. Sometimes it
is just impossible to do and you have to hand-install stuff. One of my
friends runs FreeBSD and as soon as they need something they know they can
with a few commands update everything. I hae heard that similar conditions
exist for Debian.
I agree that it may place a bit of extra work on ant-dev but if we place
them in a contrib place and effectively say unsupported then it should be
sweet. Ant-dev will only have to maintain them when they break the contract
between tasks and container (and perhaps other obvious errors). The "work"
done by task is maintained by outsiders who can send patches to
ant-lib/ant-contrib. This way when an outsider abandons a task - or
continues to use the task at a lower version of ant it still can be adopted
by someone else.
The number of patched elisp files I have that were abandoned by the
original authours is large. If the www.emacs.org group ever get off the
ground then they may get updated but until then no one else will see my
mods ;/ - I don't want to see the same thing happen with ant.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
On Mon, 11 Dec 2000, Conor MacNeill wrote:
> How about:
>
> Core Tasks = all tasks ant needs to build itself.
Just very quick look at ant build.xml and:
replace, fail, exec-family, rename, ...
and possibly others are not needed to build ant, but still, to me they
_should_ be part of the core. The definition suggested is not good enough,
I think.
Personally, I also would like to have jikes support in core, whatever
model of tasks ANT will have. No matter how nice the task pluggable
architecture of ANT is, java compiler is a such integral part of every
building process, that good support with variety of compilers is only good
for ANT. If I could, I would discourage removing jikes from the core. ;o)
cheers
mariusz
RE: [PROPOSAL] Optional Tasks
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Monday, 11 December 2000 12:34
> To: ant-dev@jakarta.apache.org
> Cc: ant-dev@jakarta.apache.org
> Subject: RE: [PROPOSAL] Optional Tasks
>
>
> At 12:02 11/12/00 +1030, Barrie Treloar wrote:
> >On Mon, 11 Dec 2000, Mariusz Nowostawski wrote:
> >
> >> But should those "interfaces" being kept in ANT core, or should they be
> >> kept in seperate, optional tasks repository? For javac, it
> should be kept
> >[del]
> >
> >> I prefer a central repository and "unification factory" for optional
> >> tasks, which could take care of defining those "interfaces", and which
> >> could keep track of all the optional tasks. The only exception would be
> >> javac being part of the core.
> >
> >I think you will find that most people would say that "javac" is not
> >part of core.
> >
> >The way core has been described, IIRC,
> > Project,
> > Task,
> > Target,
> > Property.
>
> Or alternatively ;)
>
> Core= Project + Target + task
> Core Tasks= Property + Taskdef
>
How about:
Core Tasks = all tasks ant needs to build itself.
Conor
RE: [PROPOSAL] Optional Tasks
Posted by Peter Donald <do...@apache.org>.
At 12:02 11/12/00 +1030, Barrie Treloar wrote:
>On Mon, 11 Dec 2000, Mariusz Nowostawski wrote:
>
>> But should those "interfaces" being kept in ANT core, or should they be
>> kept in seperate, optional tasks repository? For javac, it should be kept
>[del]
>
>> I prefer a central repository and "unification factory" for optional
>> tasks, which could take care of defining those "interfaces", and which
>> could keep track of all the optional tasks. The only exception would be
>> javac being part of the core.
>
>I think you will find that most people would say that "javac" is not
>part of core.
>
>The way core has been described, IIRC,
> Project,
> Task,
> Target,
> Property.
Or alternatively ;)
Core= Project + Target + task
Core Tasks= Property + Taskdef
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Optional Tasks
Posted by James Duncan Davidson <du...@x180.net>.
On 12/10/00 5:32 PM, "Barrie Treloar" <Ba...@camtech.com.au> wrote:
> I think you will find that most people would say that "javac" is not
> part of core.
>
> The way core has been described, IIRC,
> Project,
> Task,
> Target,
> Property.
Javac is not part of the core object model -- but it would be a "core" task
bundled with every copy of Ant.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: [PROPOSAL] Optional Tasks
Posted by Barrie Treloar <Ba...@camtech.com.au>.
On Mon, 11 Dec 2000, Mariusz Nowostawski wrote:
> But should those "interfaces" being kept in ANT core, or should they be
> kept in seperate, optional tasks repository? For javac, it should be kept
[del]
> I prefer a central repository and "unification factory" for optional
> tasks, which could take care of defining those "interfaces", and which
> could keep track of all the optional tasks. The only exception would be
> javac being part of the core.
I think you will find that most people would say that "javac" is not
part of core.
The way core has been described, IIRC,
Project,
Task,
Target,
Property.
Barrie
--
Barrie Treloar
____________________________________________________________________
Barrie Treloar Phone: +61 8 8303 3300
Senior Analyst/Programmer Fax: +61 8 8303 4403
Electronic Commerce Division Email: barrie@camtech.com.au
Camtech (SA) Pty Ltd http://www.camtech.com.au
--- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________
RE: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
javac - java compiler
(classic, modern, jikes, others)
javacc - java compiler compiler (parser generator)
(metamata, antlr, sablecc, others)
jidl - idl stubs/skeletons generator
(java2 jidl, many others in java and native)
ejbjar - enterprise beans packager (with configuration)
(weblogic, ias, jboss, many others)
> In summary, I think there are cases where it would be nice to define a
> common "interface" for a task and allow different implementations for this
> task. I don't want to lose sight of that unified approach because the
> optional tasks are scattered over the net.
But should those "interfaces" being kept in ANT core, or should they be
kept in seperate, optional tasks repository? For javac, it should be kept
in the core, but what about others? There is not that many of them, at the
moment which needs to have unified "interface", so maybe that should be
part of the core, and then, all the optional tasks can be scattered over
the places, and there would be no need for a repository of optional tasks?
But it puts some additional work on jakarta-ant commiters.
I prefer a central repository and "unification factory" for optional
tasks, which could take care of defining those "interfaces", and which
could keep track of all the optional tasks. The only exception would be
javac being part of the core.
Re: [PROPOSAL] Optional Tasks
Posted by Peter Donald <do...@apache.org>.
At 02:08 12/12/00 +1300, Mariusz Nowostawski wrote:
>On Mon, 11 Dec 2000, James Duncan Davidson wrote:
>> IOW, you probably want something like
>>
>> <ejb impl="com.foo.ant.ejb.EjbClass" name1="val1" name2="val2">
>> ...
>> </ejb>
>>
>> Where the ejb task is a shell that looks up the impl specified and then
sets
>> things on that. I think that would be the cleanest way to get to where you
>> want to go.
I would probably oppose that because in some cases it doesn't make sense.
For example if I wanted to use jikes to build ant rather than suns javac it
would involve changing the build file ... which would break it for everyone
else who doesn't use jikes. For some tasks it may make sense - thou I can't
think of one of the top of my head.
I much prefer to see <foo-ejb .../> and <baah-ejb .... /> because it is
simple and it matches use case. It is conceptually much easier for users of
ant. It is unlikely that tasks that do different things (despite taking the
same parameters) are going to want to be interchanged. For tasks that do
identical things (but through different methods) then it makes sense for
them to have the same name (ie javac).
>I want to go there as well. But, I would rather see it like this: the
>abstract class plug in as task, with all the common attributes different
>implementations share, and then a particular implementation plug in its
>additional funcionality.
>
><ejb name1="value1" name2="value2">
> <weblogic name3="value3" />
></ejb>
The problem is that you end up with a plethora of tasks that on first
glance look compatable but in fact aren't. It would make build files
context sensitive. ie does the ejb task refer to weblogic one, the jboss
one, the openejb one etc. What happens if we include both weblogic and
openejb sub-elements ? etc
>Here I would go for:
>
><javac ... /> (default, i.e. modern, if not available, classic)
>
><javac .... > (all generic parameters)
> <jikes pedantic="on" > (all jikes specific options)
></javac>
>
><javac ...>
> <mjavac > (all metamata specific stuff here)
></javac>
>
>Who has proposed that before? I am sure I saw it being proposed, but it
>never made its way to codebase, don't remember why?
Mainly because it does not solve the problem ... just moves it to a new
place. Instead of defining magic properties (ie
build.compiler.pedantic=true) you define magic sub-elements. However it is
non-trivial to validate subelements. ie Is subelement X a typo or does it
refer to a particular implementation?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
On Mon, 11 Dec 2000, James Duncan Davidson wrote:
> On 12/10/00 5:02 PM, "Conor MacNeill" <co...@ebinteractive.com.au> wrote:
>
> > One thing which I would like some thought on is the situation where we have
> > a task which defines an "interface" and for which there may be many
> > implementations. A current example would be the <ejbjar> task which really
> > defines an interface into which specific EJB deployment tools can be plugged
> > in (as nested elements).
>
> A second level interface -- i.e. Have a set of abstract classes that plug in
> as Tasks, but they themselves have impls that are specific.
>
> IOW, you probably want something like
>
> <ejb impl="com.foo.ant.ejb.EjbClass" name1="val1" name2="val2">
> ...
> </ejb>
>
> Where the ejb task is a shell that looks up the impl specified and then sets
> things on that. I think that would be the cleanest way to get to where you
> want to go.
I want to go there as well. But, I would rather see it like this: the
abstract class plug in as task, with all the common attributes different
implementations share, and then a particular implementation plug in its
additional funcionality.
<ejb name1="value1" name2="value2">
<weblogic name3="value3" />
</ejb>
name1 and name2 are common parameters for all possible ejb tasks, and
name3 is weblogic specific.
Each abstract task has the default implementation, thus the user does not
need to specify it, but for all the others, nested tag needs to be
used. for parser generators it could be that default is metamata:
<javacc grammar="mygrammar" outputdirectory="src" /> (default metamata)
<javacc grammar="mygrammar" outputdirectory="src">
<antlr/> (possibly with antlr specific parameters)
</javacc>
Mapping between nested tags and java classes is done via property files,
or whatever metadata format is being used for tasks. The point is, that
abstract task implementation takes care of all the standard stuff, and
passes it to the implementation, which then takes care of implementation
specific stuff, and does the job. The implementation is pluggable via the
nested element.
>
> <javac [impl="org.apache.ant.javac.JavacImpl"] .... ></java>
>
Here I would go for:
<javac ... /> (default, i.e. modern, if not available, classic)
<javac .... > (all generic parameters)
<jikes pedantic="on" > (all jikes specific options)
</javac>
<javac ...>
<mjavac > (all metamata specific stuff here)
</javac>
Who has proposed that before? I am sure I saw it being proposed, but it
never made its way to codebase, don't remember why?
cheers
mariusz
Re: [PROPOSAL] Optional Tasks
Posted by James Duncan Davidson <du...@x180.net>.
On 12/10/00 5:02 PM, "Conor MacNeill" <co...@ebinteractive.com.au> wrote:
> One thing which I would like some thought on is the situation where we have
> a task which defines an "interface" and for which there may be many
> implementations. A current example would be the <ejbjar> task which really
> defines an interface into which specific EJB deployment tools can be plugged
> in (as nested elements).
A second level interface -- i.e. Have a set of abstract classes that plug in
as Tasks, but they themselves have impls that are specific.
IOW, you probably want something like
<ejb impl="com.foo.ant.ejb.EjbClass" name1="val1" name2="val2">
...
</ejb>
Where the ejb task is a shell that looks up the impl specified and then sets
things on that. I think that would be the cleanest way to get to where you
want to go.
> Another candidate is the <javac> task itself. The current mess of supporting
> many compiler variations is not really nice. I would like to see a mechanism
> where different compilers could be plugged in. In fact such a system would
> allow the Jikes implementation to be moved out of the core and into the
> Jikes project.
Amen.
<javac [impl="org.apache.ant.javac.JavacImpl"] .... ></java>
Where the implicit is the Ant native version that just uses the JDK (so you
wouldn't ever do the above), but you could set impl="jikes.compilerImpl" and
it would defer things out to that impl.
> In summary, I think there are cases where it would be nice to define a
> common "interface" for a task and allow different implementations for this
> task. I don't want to lose sight of that unified approach because the
> optional tasks are scattered over the net.
Right. Though of course that interface will be unique per task type. Ie, the
javac and ejb examples above would have different interfaces.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: [PROPOSAL] Optional Tasks
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Monday, 11 December 2000 8:15
> To: ant-dev@jakarta.apache.org
> Subject: [PROPOSAL] Optional Tasks
>
>
> I'm still not sure what version of Ant this should apply to, but lets get
> the proposal written before I spend a whole bunch more time justifying
> myself for my reasons. I see a lot of people still not "getting it" so I
> hope to have a proposal to clarify things for people.
>
> Here are the rules to the proposal:
>
> -----------------------------------------------------------------
> The definition of a "core" task is a task that Ant really cannot live
> without. This would be similar to taglibs that are part of the core JSP
> specification.
>
> The definition of an "optional" task is a task that really should be
> packaged with the product it serves.
>
> However, there are cases where this is not feasible. Therefore, we will
> provide a separate CVS repository and mailing lists that serve as
> a storage
> and support area for tasks that cannot be bundled with the original
> products. Such as a perforce task. This would be similar to the taglibs
> Jakarta Project.
I am cool with this idea. Maybe we can call the project "antlibs" :-)
One thing which I would like some thought on is the situation where we have
a task which defines an "interface" and for which there may be many
implementations. A current example would be the <ejbjar> task which really
defines an interface into which specific EJB deployment tools can be plugged
in (as nested elements).
Another candidate is the <javac> task itself. The current mess of supporting
many compiler variations is not really nice. I would like to see a mechanism
where different compilers could be plugged in. In fact such a system would
allow the Jikes implementation to be moved out of the core and into the
Jikes project.
In summary, I think there are cases where it would be nice to define a
common "interface" for a task and allow different implementations for this
task. I don't want to lose sight of that unified approach because the
optional tasks are scattered over the net.
Cheers
Conor
Re: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
> > Also, central place can make integration of particular tasks, for example
> > parser generation, into a single task possible.
>
> You are stating things in a way as if you see something that is broken that
> you can't fix. Think in terms of doing things properly.
;o) right, my fault. But sometimes, not having enough time/power/resources
makes the latter much easier and faster and simpler to achieve.
> We should build functionality into Ant that makes integration of optional
> tasks as easy as downloading a .jar file from a website and placing it into
> a directory.
>
> I believe that what James is doing with Ant 2.0 allows for this.
Agreed. I think only tasks from non-open source projects, and
projects where it is difficult to get the original project to make ant
task available should go to the central repository then.
And
> > Also, central place can make integration of particular tasks, for
> > example parser generation, into a single task possible.
is still true. I would imagine javacc task which does not rely during
compile time on metamata/antlr/sablecc/other compilercompiler at all.
That would be good example of centrally managed task. Similar model could
be used for example for jidl, ejb, and other tasks which provide
common functionality being implemented in tool specific manner (not sure
how it is eventually solved in ant currently, seems like not solved at
all).
I like tasks being modular, even jar per task. As long as I do not have to
do anything else but place the jar in a proper place. And one optional.jar
for all centrally managed tasks ;o)
`
> > I like the idea that task contributors could automatically get added as
> > developers, and could maintain their own tasks. Maybe SourceForge is the
> > good place for it. Developers of optional tasks could maintain a webpage
> > with the list of all of them, and jakarta-ant would simply point to it.
> > This model really makes jakarta-ant resource not coupled with all the
> > optional stuff, and jakarta-ant commiters do not need to do a thing for
> > all these optional stuff. They could put a link to prebuild binary of
> > optional.jar as well.
>
> Bingo.
Do you have already a SourceForge project for all your optional tasks
which could serve as a project for all centrally managed optional tasks,
Jon? If not, what name do you guys suggest, I can register it straight
away. We could put all optional tasks from current ANT there, and evlove
to the new ANT model once it is ready (seems to me like lots of talking
before ANT 2 model will eventually happen ;o)
And tool specific tasks which can go to their parent project would migrate
from this central repository to external projects over time, and once the
modular task architecture is in place.
cheers
Mariusz
Re: [PROPOSAL] Optional Tasks
Posted by James Duncan Davidson <du...@x180.net>.
On 12/10/00 3:28 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> We should build functionality into Ant that makes integration of optional
> tasks as easy as downloading a .jar file from a website and placing it into
> a directory.
>
> I believe that what James is doing with Ant 2.0 allows for this.
Yeppers.. It's not checked in yet, but there's some functionality that I'm
playing with right now that formalizes this sort of approach. It started out
as a proof of concept for doing CJAN downloads, but since a task jar can
live anywhere spec'd by a URL, it's cake to make it work for tasks well in
advance of CJAN.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: [PROPOSAL] Optional Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 12/10/2000 1:52 PM, "Mariusz Nowostawski" <ma...@marni.otago.ac.nz>
wrote:
> I am in support of this. I think, the central place makes the life of
> users easier, as the user needs to have single optional.jar and do not
> need to play with any property files or <taskdef>s on her own. Having a
> single web-page with just a list of optional tasks, is not that easy to
> use, user needs to plug in different jars with optional tasks, and play
> with taskdefs or property files for them (unless ANT have a .aar file
> format 'Ant optional task ARchieve' ;o) with some standard way of putting
> optional tasks and their meta-information, description and task-to-class
> mapping.
> Also, central place can make integration of particular tasks, for example
> parser generation, into a single task possible.
You are stating things in a way as if you see something that is broken that
you can't fix. Think in terms of doing things properly.
We should build functionality into Ant that makes integration of optional
tasks as easy as downloading a .jar file from a website and placing it into
a directory.
I believe that what James is doing with Ant 2.0 allows for this.
> I like the idea that task contributors could automatically get added as
> developers, and could maintain their own tasks. Maybe SourceForge is the
> good place for it. Developers of optional tasks could maintain a webpage
> with the list of all of them, and jakarta-ant would simply point to it.
> This model really makes jakarta-ant resource not coupled with all the
> optional stuff, and jakarta-ant commiters do not need to do a thing for
> all these optional stuff. They could put a link to prebuild binary of
> optional.jar as well.
Bingo.
-jon
Re: [PROPOSAL] Optional Tasks
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
> -----------------------------------------------------------------
> The definition of a "core" task is a task that Ant really cannot live
> without. This would be similar to taglibs that are part of the core JSP
> specification.
>
> The definition of an "optional" task is a task that really should be
> packaged with the product it serves.
>
> However, there are cases where this is not feasible. Therefore, we will
> provide a separate CVS repository and mailing lists that serve as a storage
> and support area for tasks that cannot be bundled with the original
> products. Such as a perforce task. This would be similar to the taglibs
> Jakarta Project.
> -----------------------------------------------------------------
(Perhaps the axiom:
core task == Ant really cannot live without
should read:
core task == to compile it one does not need to have anything else apart
form ant itself
)
I am in support of this. I think, the central place makes the life of
users easier, as the user needs to have single optional.jar and do not
need to play with any property files or <taskdef>s on her own. Having a
single web-page with just a list of optional tasks, is not that easy to
use, user needs to plug in different jars with optional tasks, and play
with taskdefs or property files for them (unless ANT have a .aar file
format 'Ant optional task ARchieve' ;o) with some standard way of putting
optional tasks and their meta-information, description and task-to-class
mapping.
Also, central place can make integration of particular tasks, for example
parser generation, into a single task possible.
I like the idea that task contributors could automatically get added as
developers, and could maintain their own tasks. Maybe SourceForge is the
good place for it. Developers of optional tasks could maintain a webpage
with the list of all of them, and jakarta-ant would simply point to it.
This model really makes jakarta-ant resource not coupled with all the
optional stuff, and jakarta-ant commiters do not need to do a thing for
all these optional stuff. They could put a link to prebuild binary of
optional.jar as well.
cheers
mariusz