On 09/01/07, Alexei Zakharov <[EMAIL PROTECTED]> 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.
