ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Task for the new Pack200 format
Date Tue, 10 Feb 2004 16:03:35 GMT
> >>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

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 ...


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message