ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <tdawso...@yahoo.com>
Subject RE: Ant 1.9 & Task Packaging
Date Wed, 23 Jan 2002 07:10:43 GMT
Stefan writes:
>> Anything inside of core and included in the build would have to pass
>> a strict "can this run without ANY 3rd party jars?"

>A very hard rule and we won't hold it, I'm sure.  Crimson is a 3rd
>party jar.

Ah my bad on the wording. Actually when I said 3rd party jars, I meant "jars
that are not included".  Crimson happens to be included in the Ant
distribution, so AFAIC core tasks depending on Crimson are fine.

The reason I suggested the rule is for tasks like <style>. Its a "built-in
task" and yet it won't run unless you separately download xalan and xerces
and put them in the classpath. It drives me absolutely nuts when I build
projects and have to go hunting the ClassNotFound stack traces to figure out
what's missing.

So what core tasks would rely on non-included jars? And if they're core
tasks (meaning useful to darn near everybody, right?), why not include those
jars in the Ant binaries?

I would think anything that's in core should run out of the box. And any
antlib should include the jars it relies on - or at least fail with a clear
error message stating where to get the right jar when this is not possible
due to licensing issues (e.g. starteam tasks).

Tim


> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Tuesday, January 22, 2002 7:14 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Ant 1.9 & Task Packaging
>
>
> On Mon, 21 Jan 2002, Tim Dawson <tdawson47@yahoo.com> wrote:
>
> > currently we have a few packages, "taskdefs", for the - supposedly -
> > core stuff, and taskdefs.compilers, taskdefs.condition,
> > taskdefs.rmic, and then a catchall, taskdefs.optional.* where
> > everything else is bunched. This is a bit confusing as some tasks
> > haven't been migrated to a hierarchy, etc.
>
> It is not strictly a matter of migration (the compiler, rmic and
> condition subpackages just happened to suddenly be there 8-).  Moving
> classes into different packages can create backwards compatibility
> problems as well (there is at least one link on our external tools
> page to a task that "extends org.apache.tools.ant.taskdefs.Javac").
>
> Of course we are free to chose new packages for Ant2 as we like.
>
> > org.apache.tools.ant2
> > 	(main engine, interfaces, abstract superclasses)
>
> make that org.apache.ant, no need for the 2 IMHO as Ant 1.x is in the
> tools subpackage.
>
> Most (all?) proposals use that package as well.
>
> > Anything inside of core and included in the build would have to pass
> > a strict "can this run without ANY 3rd party jars?"
>
> A very hard rule and we won't hold it, I'm sure.  Crimson is a 3rd
> party jar.
>
> > Further, if we're really moving to a container architecture with
> > Ant2, then we should define a spec for the build file, execution
> > engine, and task extensions API through a JSR
>
> Has been proposed by others (Conor) before.
>
> > BEA should be able to provide a "weblogic.jar" that could just be
> > referenced in a build file, and used with whatever recent version of
> > Ant you've downloaded.
>
> You are absolutely correct, they should be.  Why don't they?  All
> people would have to do was to add a single <taskdef> line.
>
> Stefan
>
> --
> To unsubscribe, e-mail:
> <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:ant-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message