harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Tue, 09 Jan 2007 23:29:47 GMT
On 09/01/07, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
>
> On the other hand, I still don't understand how this solves the SVN
> problem described by Alex. I've missed something probably.

I don't think it will solve all of the SVN issues that I've been
having, but it certainly makes it easier to separate out the pack200
code from the non-pack200-archive code, which makes it easier for
generating/exporting as a bundle. Plus, since I'm working on this in
isolation of the remainder of the class libraries (I'm developing on a
Mac, where I'm using the Apple JVM for the public libraries) makes it
easier.

> Another  thing I can't really get why we keep pack200 in the classlib workspace
> if, as Alex has said, it has no relations (should not have relations?)
> to the rest of classlibrary code and does not implement any public
> API. May be jdktools is a better candidate indeed?

All of the pack code is its own, except for two implementations of
java.util.jar.Pack200.Packer and java.util.jar.Pack200.Unpacker
interfaces, which are (and should be) in the archive module. There's a
Pack200 factory that instantiates the appropriate library with the
equivalent of Class.forName(System.getProperty("java.util.jar.Pack200.Packer","org.apache.pack200.Pack200Adapter")),
which the harmony libraries default to the org.apache.pack200
implementation if it's not set.

So the code is pretty independent of the Java classlibs; however, the
implementation must be there at run time if it is to pass the TCK.

> And again about this SVN issue. We may establish some process
> probably. For example Alex can add a comment to critical JIRAs that he
> can't live without this JIRA is applied. I did something like it
> during my pre-committer life while working on the beans module.
> Another suggestion is to post small JIRAs if some files should be
> added to the workspace. It is easy to integrate and should simplify
> Alex's life.

Mostly, I'm easy -- the process was working, but I had a few problems
generating the patches with new files that was mostly resolved by just
dumping a Zip of the workspace  up. The only other problem was that if
there had been a lot of work, especially containing new files, it is
easier to batch up the changes and then wait for them to be applied;
but to be honest, it wasn't that much of a show stopper since I have
other things to do anyway. The only reason why I've not done anything
since my last work in November was because I didn't see much point in
having potentially unappliable fixes if the module (and therefore the
package name) was going to change in every file. Now that that's done,
I can pick up speed again.

Alex.

Mime
View raw message