harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: Re: [classlib][pack200] Status update (again)
Date Thu, 23 Nov 2006 00:25:06 GMT
On 11/22/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
> On 22/11/06, Tim Ellison <t.p.ellison@gmail.com> 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


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

View raw message