> >>Do we want to make them core tasks or do we want to farm > them out into > >>an antlib of their own? > >> > > > > Because its based only on (new) standard classes I would do that as > > core tasks. And as an adoption of <jar>, so the user doesn´t has to > > create the JAR bofore "pack200"ing. > > "core tasks" would be the right solution if it could be implemented > using JDK1.3 ( or even 1.4 ), or at very least use introspection. > I'm kind of -1 for conditional compilation ( which would > force ant to be > built with 1.5 beta ). > > It would be really nice to have pack200 implemented in 1.3, > both packer > and unpacker/class loader - it would reduce the size of our code and > make this cool feature available _now_ and to everyone. I > hate when Sun > bundles features with JDK ( like logging, NIO ) in order to force > adoption, hurting the new feature and existing users who > can't benefit > from them, and eventually the standard itself, since alternative > solutions supporting current VMs are more likely to be > adopted instead.
We can make an OptionalTask. There´s no difference in the users point of view - if he had the needed 3rd party lib. The task is available without the need of <taskdef>ing it or declaring via namespace. As an antlib maybe we could bundle it with the 3rd party lib. But if that file format should become the future "jar"-format, then the task should be part of Ant itself - not an external. So I see these possibilities: 1) Optional Task and conditional compile, depending on presence of JDK 1.5. 2) Core Task and the implementation of the format as a util class 3) AntLib with bundled lib 4) AntLib without bundled lib and autodownload ;-) I think the first would be the best. Reimplementing the format wouldn´t be easy enough. And if done, it should go into the Jakarta-Commons. And then we have an external lib - same as the first ... I´m not sure whether we can bundle the lib (if it´s available as a standalone lib) - depends on the license. Autodownload ... another topic ... Jan
