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:[EMAIL PROTECTED] > Sent: Tuesday, January 22, 2002 7:14 AM > To: [EMAIL PROTECTED] > Subject: Re: Ant 1.9 & Task Packaging > > > On Mon, 21 Jan 2002, Tim Dawson <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
