Re: Task for the new Pack200 format

[Costin Manolache]

Jose Alberto Fernandez wrote:
What do people think? I will wait to see what are we interested
on doing before aproaching Bill. I know him from my time at Maryland,
hope he still remembers me.
I'm very interested.
If we do get an implementation for JDK1.2 - then it makes sense to have 
it in the core, so we can unpack antlibs with it :-)

( a better target would be CDC - not JDK1.2 :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Wed, 11 Feb 2004, Jose Alberto Fernandez 
> <[EMAIL PROTECTED]> wrote:
> 
> > With respect on providing a version of pack200 usable by 
> lesser JDKs I 
> > think than rather trying to reproduce the thing from 
> scratch, we could 
> > just as well ask Bill Puig if he would be willing to 
> contribute such a 
> > task or at least the code (either to Apache or as 3rd party).
> 
> If he'd donate it to the ASF that would certainly be great.  
> When we talk about 3rd party, which certainly includes the 
> option of him publishing it himself, it would all depend on 
> the license.
> 

On the third party issue, I certaintly would like him to provide
an ASF style license, but I do not think that is needed.
What I mean by a 3rd party, is that they will provide on their
servers an antlib JAR file containing the tasks, and that
we will publish the task availability on our external tasks page.

It means we do not have to maintain them at all. If he instead donates
the work, well then all future maintenance falls in our lap.

The way I see it,  for JDK1.5 should be in core
and supported by us. On the other hand,  task for lesser
JDKs could be provided and maintained aby someone else.

What do people think? I will wait to see what are we interested
on doing before aproaching Bill. I know him from my time at Maryland,
hope he still remembers me.

Let me know,

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Wed, 11 Feb 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> With respect on providing a version of pack200 usable by lesser JDKs
> I think than rather trying to reproduce the thing from scratch, we
> could just as well ask Bill Puig if he would be willing to
> contribute such a task or at least the code (either to Apache or as
> 3rd party).

If he'd donate it to the ASF that would certainly be great.  When we
talk about 3rd party, which certainly includes the option of him
publishing it himself, it would all depend on the license.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Breaking Ant into several modules (was RE: Task for the new Pack200 format)

[Jose Alberto Fernandez]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> 
> > I agree with the goal to make as many things antlibs as possible, I 
> > could even be convinced that we start to break up our 
> current set of 
> > core/optional tasks into antlibs with independent release cycles.
> 
> Then we´ll earn the whole inter-project-dependency-problems. 
> We have to ensure that an AntLib works with all AntCore 
> releases or fails with a defined error.
> 

Which means having some sort of version dependency infrastructure.

> I agree that breaking Ant into several modules would improve the 
> development process, especially for the optional tasks. An 
> AntLib for the task implementation AND the correct version of 
> the 3rd party lib.
> 
> 
> But I see two things:
> 1. Plugging in AntLibs should be very easy - especially if they were
>part of earlier Ant releases. Or we have to use namespaces 
> everywhere...
> xmlns:script="org/apache/tools/ant/antlib-script.xml"
> ...>
>is a little bit too long, I think.
> 
>So dropping the AntLibs into a directory and they will be 
> "auto-deployed"
>into Ant (I like that feature of JBoss :-) will be fine.
> 

Agreed. What I would like is for this to be done by antlib itself
and not by core. So what I envision is some sort of 
directive that allows one antlib to import into its namespace
definitions of other antlibs.

a) Being able to add to the antlib.xml file something like:

 
   
 
   
 

Where the import directive will look on each JAR file for and antlib.xml
and load the jar into its classloaders and the antlib.xml definitions
into its own.

b) once we have such a mechanism, third parties can provide their 
own cluster of related files that can be load globally or in a more
per project organization. 

> 2. It should be easy for the user to get a "complete" working 
> version of
>Ant. So we should provide a bundle of the AntCore and a 
> set of AntLibs.
> 

That would be simple.

Jose Alberto


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Jose Alberto Fernandez]

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> Sent: 11 February 2004 14:59
> To: 'Ant Developers List'
> Subject: RE: Task for the new Pack200 format
> 
> 
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > If we stick with JDK 1.5 only, this would become a two very simple 
> > tasks, so I'm not sure about the antlib approach.
> 
> Why not support pack200/unpack200 directly from the  and 
> , whenever running on JDK 1.5?
> 

+1 

> In /, it would add a pack200="true/false" 
> attribute, and / would automatically check for 
> the PACK200 comment in the ZIP/JAR file, and do the right 
> thing automatically.
> 
> Sounds to me that it's a much nicer integration that having 
> separate tasks.
> 

Either pack200="true/false" or compression="pack200" (leaving room
for improvements).

> Optionally, instead of using a pack200 attribute, it could be 
> a  sub-element of , which would allow to plugin 
> more easily a non-JDK1.5 specific implementation (from 
> Jakarta-commons or stefanbodewig.org ;-)
> 
> Having them as separate tasks is fine, but if this new 
> compression is half as good as described, then it's going to 
> be in widespread use very soon, and direct integration in 
>  would be much more user-friendly IMHO. --DD
> 

With respect on providing a version of pack200 usable by lesser JDKs
I think than rather trying to reproduce the thing from scratch,
we could just as well ask Bill Puig if he would be willing to contribute
such a task or at least the code (either to Apache or as 3rd party).

I do not see why not. I could ask him if you want.

Jose Alberto


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Wed, 11 Feb 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >> If we stick with JDK 1.5 only, this would become a two very simple
> >> tasks, so I'm not sure about the antlib approach.
> >
> > Why not support pack200/unpack200 directly from the  and ,
> > whenever running on JDK 1.5?
> 
> I rather thought about making  create the packed files
> without intermediat jars, so the task would be 
> without changing  itself and clobber it with reflection and all
> that.

That works too.

> > / would automatically check for the PACK200 comment in
> > the ZIP/JAR file, and do the right thing automatically.
> 
> Uhm, AFAIU the comment is in the archive *after* unPACK200ing them so
> that you know it is not the original jar but one that has been
> modified on its way.

That's not the way I read it, but it's likely I read it wrong. I thought
pack still produced a JAR file, albeit with this special comment, and with
all .class files inside it heavily massages and/or transmogrified into
something else smaller... So that deployment tool can read the JAR comment,
notice the comment, and unpack200 the JAR into a real JAR. But again, I
probably misunderstood. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Wed, 11 Feb 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>> If we stick with JDK 1.5 only, this would become a two very simple
>> tasks, so I'm not sure about the antlib approach.
> 
> Why not support pack200/unpack200 directly from the  and ,
> whenever running on JDK 1.5?

I rather thought about making  create the packed files
without intermediat jars, so the task would be 
without changing  itself and clobber it with reflection and all
that.

> / would automatically check for the PACK200 comment in
> the ZIP/JAR file, and do the right thing automatically.

Uhm, AFAIU the comment is in the archive *after* unPACK200ing them so
that you know it is not the original jar but one that has been
modified on its way.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> If we stick with JDK 1.5 only, this would become a two very simple
> tasks, so I'm not sure about the antlib approach.

Why not support pack200/unpack200 directly from the  and ,
whenever running on JDK 1.5?

In /, it would add a pack200="true/false" attribute, and
/ would automatically check for the PACK200 comment in the
ZIP/JAR file, and do the right thing automatically.

Sounds to me that it's a much nicer integration that having separate tasks.

Optionally, instead of using a pack200 attribute, it could be a 
sub-element of , which would allow to plugin more easily a non-JDK1.5
specific implementation (from Jakarta-commons or stefanbodewig.org ;-)

Having them as separate tasks is fine, but if this new compression is half
as good as described, then it's going to be in widespread use very soon, and
direct integration in  would be much more user-friendly IMHO. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On 11 Feb 2004, Denis N. Antonioli <[EMAIL PROTECTED]> wrote:

> The specification is in the jsr itself, you'll need to get the zip.
> See the 'Download' link on:
> 

This is what you get for setting "Accept images that come from the
originating server only" in Mozilla.  There has been no 'Download'
link for me 8-)

Thanks

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Denis N. Antonioli]

On Wed, 11 Feb 2004, Stefan Bodewig wrote:

> On Tue, 10 Feb 2004, Alexey N. Solofnenko <[EMAIL PROTECTED]>
> wrote:
>
> > http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html
>
> I can't seem to find a link describing the pack algorithm (detailed
> enough that I'd be able to reimplement it) that has finally been
> implemented for Tiger from there.  Could you please help me?
>
> William Pugh's article is marked as a starting point. but I'm not sure
> that this is identical to the algorithm finally used.  And I don't see
> an example implementation at his homepage (as hinted in the conclusion
> of his article) either.

The specification is in the jsr itself, you'll need to get the zip.
See the 'Download' link on:


Happy implmentation ;-)
dna

-- 
  Life is too short to use anything but a Mac;
  Windows is just not a human environment.
-- Roger Ebert in Los Angeles Times, Thursday, February 15, 2001


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Wed, 11 Feb 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> William Pugh's article is marked as a starting point. but I'm not
> sure that this is identical to the algorithm finally used.  And I
> don't see an example implementation at his homepage (as hinted in
> the conclusion of his article) either.

OK, here is this 
to download his implementation, but his disclaimer

,
| The format of the archives produced by the evaluation version will not
| be compatible with future versions
`

makes me believe that I shouldn't use his article as a base for any
algorithm that is supposed to be compatible with Tiger's Pack200
implementation.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Steve Loughran <[EMAIL PROTECTED]> wrote:

> Antlib.

If we really want to reimplement the algorithm so that it becomes
usable for JDK < 1.5 I agree with this.  It sounds like a candidate
for a Pack200 library in Commons plus Ant tasks plus command line
utilities IMHO.

If we stick with JDK 1.5 only, this would become a two very simple
tasks, so I'm not sure about the antlib approach.

I agree with the goal to make as many things antlibs as possible, I
could even be convinced that we start to break up our current set of
core/optional tasks into antlibs with independent release cycles.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Alexey N. Solofnenko <[EMAIL PROTECTED]>
wrote:

> http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html

I can't seem to find a link describing the pack algorithm (detailed
enough that I'd be able to reimplement it) that has finally been
implemented for Tiger from there.  Could you please help me?

William Pugh's article is marked as a starting point. but I'm not sure
that this is identical to the algorithm finally used.  And I don't see
an example implementation at his homepage (as hinted in the conclusion
of his article) either.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Steve Loughran]

Stefan Bodewig wrote:
Hi,
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?

Antlib. That way people w/ Ant1.6 will be able to use them, and it shows 
that we think antlibs are the future of addon stuff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Matt Benson]

(butchered for context)
--- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
wrote:
> Stefan Bodewig wrote:
> >So far I haven't found a technical spec for the
> format so I don't know
> >whether we can implement it.
> 
> It is there:
>
http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html

> Stefan Bodewig wrote:
> >A JDK 1.5 only
> implementation would be
> >trivial.

Based on the information in William Pugh's
"Compressing Java Class Files" article, reinventing
the wheel in this case sounds distinctly non-trivial. 
At the same time, I can't imagine why Pack200
wouldn't/couldn't be made available independent of
Tiger--other than the reasons alleged by Costin.  ;)

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Alexey N. Solofnenko]

It is there:
http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html
- Alexey.
Stefan Bodewig wrote:
On Tue, 10 Feb 2004, Costin Manolache <[EMAIL PROTECTED]> wrote:
 

"core tasks" would be the right solution if it could be implemented
using JDK1.3
   

1.2, you mean 8-)
So far I haven't found a technical spec for the format so I don't know
whether we can implement it.  A JDK 1.5 only implementation would be
trivial.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Costin Manolache <[EMAIL PROTECTED]> wrote:

> "core tasks" would be the right solution if it could be implemented
> using JDK1.3

1.2, you mean 8-)

So far I haven't found a technical spec for the format so I don't know
whether we can implement it.  A JDK 1.5 only implementation would be
trivial.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Jan . Materne]

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

Re: Task for the new Pack200 format

[Costin Manolache]

[EMAIL PROTECTED] wrote:
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?
Stefan
Footnotes: 
[1]  http://jcp.org/en/jsr/detail?id=200

[2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html

Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , 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.

Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Matt Benson]

--- [EMAIL PROTECTED] wrote:
> Because its based only on (new) standard classes I
> would do that as
> core tasks. And as an adoption of , so the user
> doesn´t has to
> create the JAR bofore "pack200"ing.

+1

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Antoine Lévy-Lambert]

[EMAIL PROTECTED] wrote:
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?
Stefan
Footnotes: 
[1]  http://jcp.org/en/jsr/detail?id=200

[2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html
   


Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , so the user doesn´t has to
create the JAR bofore "pack200"ing.
Jan
 

+1
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Jan Materne <[EMAIL PROTECTED]> wrote:

> And as an adoption of , so the user doesn´t has to create the
> JAR bofore "pack200"ing.

Yes, sounds useful.  In particular since the Pack200 class deals with
streams, so we could create the initial jar in memory - if it is small
enough, that is.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Task for the new Pack200 format

[Jan . Materne]

> Java 1.5 comes with support for a new archive format Pack200[1] which
> basically works by using a special compression algorithm that is very
> effective on Java class files.  The way to create such an archive is
> to create a plain old jar first and then turn ot into a Pack200
> archive - "depack200"ing again yields a jar archive.
> 
> Sine Java 1.5 comes with a straight forward utility class[2], creating
>  and  tasks would be quite simple - and first
> enhancement request are predicted to pop up soon 8-)
> 
> Do we want to make them core tasks or do we want to farm them out into
> an antlib of their own?
> 
> Stefan
> 
> Footnotes: 
> [1]  http://jcp.org/en/jsr/detail?id=200
> 
> [2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html
> 


Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , so the user doesn´t has to
create the JAR bofore "pack200"ing.

Jan