On 11/22/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
On 22/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Alex Blewitt wrote:
> > I'd also like to get the pack200 code moved out of the archive module
> > and into its own module, and after applying this patch sounds like a
> > good time to do this. If someone can help me with the creation of a
> > new module (e.g. archive-pack200), that would be good.
>
> Once the patch is applied I can help with separating the pack200 code. I
> don't think it requires a separate module, but we can pull it out into a
> separate source folder in archive, build it with source 1.4 flags, and
> create a target to produce a separate jar etc.
It would make my life much easier if it were a separate module, and it
would be much easier to generate patches for the code (which really
have sucked up until now) if it were. I'm developing on Mac OS X, and
it doesn't have a J9, so I'm developing the pack200 code against the
Mac OS X 10.4 Java libraries. In order to do this, I have to
completely kill the Harmony Manifest.MF, as well as hand-editing the
.svn entries files to remove traces of java/util/archive and others.
Why would you need to do anything to the SVN meta files (.svn)? DRLVM
doesn't run on MacOS either, so how do you verify your code builds and
test run within the Harmony codebase?
Have you tried just doing an SVN export (no meta files) delete what
you want to ignore, work on what you want to work on in the IDE of
choice. Once you're ready for a update, check out/update the latest
archive module code, in a separate folder, do a manual merge/overlay.
Any new files/folders you'd do an 'svn add' and anything that needs to
be deleted you'd do an 'svn del'. Then run the Harmony builds to
verify your working copy is as expected. Once you're set, run an 'svn
diff'.
-Nathan
If it were in a separate module, I'd just be able to check out that
module and work on it on its own, without doing any of this hackery.
Secondly, the goal is to be able to have a separate implementation for
the pack200 code, both as a bundle and as a Jar; so it's going to need
its own Manifest.MF. Does it really make sense to have the code in the
archive, and use that to create another sub-bundle from inside, when
the module system provides that at the moment?
In any case, given that patches are supposed to be from the module
root, it would be good if there was a little work area that I could
use for developing the pack200 stuff (and avoid using internal Harmony
classes) by just relying on the standard Java API. Lastly, it would
allow the pack200 messages to be separated from the other archive
messages.
Perhaps there's problems with creating a new module that I'm not aware
of; can you explain the problems with that approach?
Alex.
