[classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

Good news, everyone!

I've managed to get multiple interfaces extracted from a Pack200
archive, along with methods, exceptions, interfaces and constant
values (char etc.) The next step is to decode bytecodes, but there's a
fair bit of work involved in reconstituting the bytecode part of it
(so non-abstract methods or non-constant initialisers still don't
work).

Anyway, the current code is in Harmony-2246 but I'm likely to take a
brief hiatus. It would be good if the patch could be applied
(successfully this time :-) before I pick up the next bit of work.

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.

Alex.

Re: [general] Patch preparation workflow Was: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

Let's be clear; the problems aren't me being able to keep up with
changes in Harmony. There's not that much work in the pack200 package
other than what I'm doing anyway.

The big problem is that the refactoring and on-going development
results in the SVN copy not being able to generate a patch which other
Harmony commiters can then use. My local repository is fine, and I can
develop with it; the problem is getting this data out and into
Harmony.

Alex.

On 24/11/06, Salikh Zakirov <Sa...@intel.com> wrote:
> Alex Blewitt wrote:
> > I think patching is a great way of making the occasional change to
> > existing code. I don't think it works well for new development.
>
> Alex,
>
> have you tried any of the modern distributed version control systems?
> Here are some:
>   Monotone: http://monotone.ca
>   Mercurial(hg): http://www.selenic.com/mercurial
>   Git: http://git.or.cz
>
> Any of the above is capable of storing and managing multiple patches and
> branches in the local repository, all of them support file renames (although in
> different ways) and advanced merging.
>
> The basic techniques of preparing patches for Harmony is:
>
> 1) create a separate "tracking" branch as an exact copy of Harmony SVN
>    (you can do 'svn checkout' and commit to a local version control,
>     or use some importer like Tailor http://www.darcs.net/DarcsWiki/Tailor)
>
> 2) create a local branch for your development
>
> 3) when you want to merge with SVN trunk, first update the tracking branch
>    (without your local modifications), and then merge tracking branch
>    into your working branch.
>
> 4) produce updated patch as the difference between updated tracking branch
>    and updated working branch.
>
> It looks like this is a quite common workflow, and googling may get many
> descriptions and success stories.
>
> So I think, "patching" is good as a means of exchanging code modifications,
> but you may need some additional tools to manage patches while you develop
> them.
>
>

[general] Patch preparation workflow Was: [classlib][pack200] Status update (again)

[Salikh Zakirov <Sa...@Intel.com>]

Alex Blewitt wrote:
> I think patching is a great way of making the occasional change to
> existing code. I don't think it works well for new development.

Alex,

have you tried any of the modern distributed version control systems?
Here are some:
  Monotone: http://monotone.ca
  Mercurial(hg): http://www.selenic.com/mercurial
  Git: http://git.or.cz

Any of the above is capable of storing and managing multiple patches and
branches in the local repository, all of them support file renames (although in
different ways) and advanced merging.

The basic techniques of preparing patches for Harmony is:

1) create a separate "tracking" branch as an exact copy of Harmony SVN
   (you can do 'svn checkout' and commit to a local version control,
    or use some importer like Tailor http://www.darcs.net/DarcsWiki/Tailor)

2) create a local branch for your development

3) when you want to merge with SVN trunk, first update the tracking branch
   (without your local modifications), and then merge tracking branch
   into your working branch.

4) produce updated patch as the difference between updated tracking branch
   and updated working branch.

It looks like this is a quite common workflow, and googling may get many
descriptions and success stories.

So I think, "patching" is good as a means of exchanging code modifications,
but you may need some additional tools to manage patches while you develop
them.

Re: Re: Re: Re: Re: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

On 23/11/06, Nathan Beyer <nb...@gmail.com> wrote:
> Depends how you create the patch. I know using the command-line "svn
> diff" it only uses the relative path, but any time I've every done a
> diff with the Eclipse team tools (CVS, Subclipse) it puts an absolute
> path in the file every time. Modifying the paths in these files after
> diff creation is pretty safe -- usually one Find/Replace fixes
> everything.

Yeah, I ended up hand-editing the Indexes in the patch to remove the
absolute path reference. However, even when I did that, I still had
problems -- largely due to the refactoring that I'd done with moves.

> > So this is the problem -- in one of my recent refactorings, I moved a
> > file from the parent package to a (new) subpackage. What's the
> > workaround for these cases in the future?
>
> If you do the refactor within Eclipse (Subclipse enabled), this should
> do the "adds" for you, so when the diff is created the new files
> should be in the patch. Then just list the files to be deleted in the
> JIRA with the patch. An easy way to get the list of deleted files
> would be run "svn status" and use the output from that; everything
> with a "D" is what needs to be deleted.

Yeah, I don't think the Adds are the problem. However, the code is in
a stage where I'm refactoring quite a lot, and although intra-file
refactorings aren't likely to be an issue, refactoring to move classes
to different packages certainly sounds like a show-stopper.  What
about renaming a file? Doesn't that get treated as a move, too; in
which case, even changing a name of a file is likely to cause problems
:-(

> Depending on how you perform the refactor, a move may not work well.
> For example, if you're move a whole folder full of files to a new
> folder, then this would be translated into an SVN copy of the folder
> and delete of the folder as this is the most optimized SVN command. In
> this case, I would suggest creating the new folders and then
> performing individual files copies, so they are treated as individual
> new file adds.

This isn't an option when performing a refactoring. As you probably
know, when you do a refactor -> move in Eclipse, it does the updates
for each of the individual files on your behalf. It's not a case of me
choosing to create a directory, and then doing individual
drag-and-drops.

It seems to me that it's just not well suited for fluctuating work,
and as I've previously observed, the amount of time and effort to
create a patch (and for it to be successfully applied)  is basically
something which requires me to stop work for a week or so at a time
whilst issues like this get resolved. I certainly can't end up doing
new work, because whatever incoming changes end up obliterating any
work I've done (when you've svn add'd a file and then someone else
commits it, it shows up as a conflict on your local copy ... so doing
any mods on it until it's committed is basically a no-no).

I think patching is a great way of making the occasional change to
existing code. I don't think it works well for new development.

Alex.

Re: Re: Re: Re: [classlib][pack200] Status update (again)

[Nathan Beyer <nb...@gmail.com>]

On 11/23/06, Alex Blewitt <al...@gmail.com> wrote:
> On 23/11/06, Nathan Beyer <nb...@gmail.com> wrote:
> > Why delete the files at all, just ignore them. Just create your own
> > Eclipse project files an point exclusively to the pack200 files. You
> > can do this many ways with Eclipse; create a project and use links to
> > pull in just the pack200 files, work within the 'archive' module and
> > add exclusion filters to remove all other files.
>
> Yup, could do that. I'm not sure how the Subclipse client will deal
> with a mixture of svn- and non-svn-managed directories, and it's not
> like I've had much luck with that so far.
>
> > Have you considered just checking out the pack200 files alone? Create
> > your project folder, create source folder and then create
> > "org/apache/harmony/archive/internal" and then checkout
> > "https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/"
> > to 'pack200' under 'internal' and you're set.
>
> Yup, also could do that. But the recommended guidelines is to create a
> patch from the package root; and I couldn't do that if I was just
> checking out some of the sub-folders.

Depends how you create the patch. I know using the command-line "svn
diff" it only uses the relative path, but any time I've every done a
diff with the Eclipse team tools (CVS, Subclipse) it puts an absolute
path in the file every time. Modifying the paths in these files after
diff creation is pretty safe -- usually one Find/Replace fixes
everything.

>
> It also doesn't solve the other problems; that the messages for the
> pack200 are separate from the other java.util.* implementation; how to
> have a separate MANIFEST.MF for the pack200 code so that it could be
> used in a separate OSGi bundle; or for that matter being able to run
> the build on just that component without having the java.* code in
> there as well. I'd like to try and get to a stage where I'm able to
> build the bundle successfully with build.xml rather than just checking
> for compile-time safety.
>
> > I know that deletes and moves can't be done via diffs, but adds can
> > and moves are just deletes and adds. In these cases I would just
> > suggest notification of files that need to be deleted in JIRA issues
> > and do everything ass updates and adds.
>
> So this is the problem -- in one of my recent refactorings, I moved a
> file from the parent package to a (new) subpackage. What's the
> workaround for these cases in the future? And how do I do an ass
> update? ;-)

Sorry "ask" is what meant.

If you do the refactor within Eclipse (Subclipse enabled), this should
do the "adds" for you, so when the diff is created the new files
should be in the patch. Then just list the files to be deleted in the
JIRA with the patch. An easy way to get the list of deleted files
would be run "svn status" and use the output from that; everything
with a "D" is what needs to be deleted.

Depending on how you perform the refactor, a move may not work well.
For example, if you're move a whole folder full of files to a new
folder, then this would be translated into an SVN copy of the folder
and delete of the folder as this is the most optimized SVN command. In
this case, I would suggest creating the new folders and then
performing individual files copies, so they are treated as individual
new file adds.

>
> > I have tried this. I do this quite often in fact (here and elsewhere).
> > I've also committed patches that other people have created this way
> > and it works like a charm. Note, I do this all with the SVN command
> > line. I've been able to do this successfully with v1.3.2, v1.4.0 and
> > v1.4.2 SVN binaries for Windows.
>
> OK, well I'm on SVN 1.3.1 for Mac, but I think your point above
> regarding the delete/move is probably the wall I was running into
> repeatedly, especially as I've been doing renames too (do they survive
> the diff process, or are they just a move?)
>
> Heigh ho. Hopefully the full dump of the source tree will help out
> somewhat and once that's patched, we can start doing shuffling around.
> I'd still like to know what the problems are with (or arguments
> against) moving the pack200 stuff in its own separate module; after
> all, you don't get a JDBC driver and the JDBC APIs packaged into the
> same Jar; why should the Pack200 implementation be any different?
> Obviously the core Java classes (java.util.jar.pack200 etc.) would
> stay where they are, but the org.apache.harmony stuff could easily be
> pulled out into a separate module, thus making the build process
> simpler than checking out folders piecemeal whilst also decoupling the
> messages for the j.u.j and o.a.h.p2 classes and giving the o.a.h.p2
> its own MANIFEST.MF. But perhaps I'm missing the big picture here ...
> can someone help educate me?

That's a different discussion to me. I would like to eliminate the
issues of source code management and focus the isolation discussion on
design concerns.

-Nathan

>
> Alex.
>

Re: Re: Re: Re: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

On 23/11/06, Nathan Beyer <nb...@gmail.com> wrote:
> Why delete the files at all, just ignore them. Just create your own
> Eclipse project files an point exclusively to the pack200 files. You
> can do this many ways with Eclipse; create a project and use links to
> pull in just the pack200 files, work within the 'archive' module and
> add exclusion filters to remove all other files.

Yup, could do that. I'm not sure how the Subclipse client will deal
with a mixture of svn- and non-svn-managed directories, and it's not
like I've had much luck with that so far.

> Have you considered just checking out the pack200 files alone? Create
> your project folder, create source folder and then create
> "org/apache/harmony/archive/internal" and then checkout
> "https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/"
> to 'pack200' under 'internal' and you're set.

Yup, also could do that. But the recommended guidelines is to create a
patch from the package root; and I couldn't do that if I was just
checking out some of the sub-folders.

It also doesn't solve the other problems; that the messages for the
pack200 are separate from the other java.util.* implementation; how to
have a separate MANIFEST.MF for the pack200 code so that it could be
used in a separate OSGi bundle; or for that matter being able to run
the build on just that component without having the java.* code in
there as well. I'd like to try and get to a stage where I'm able to
build the bundle successfully with build.xml rather than just checking
for compile-time safety.

> I know that deletes and moves can't be done via diffs, but adds can
> and moves are just deletes and adds. In these cases I would just
> suggest notification of files that need to be deleted in JIRA issues
> and do everything ass updates and adds.

So this is the problem -- in one of my recent refactorings, I moved a
file from the parent package to a (new) subpackage. What's the
workaround for these cases in the future? And how do I do an ass
update? ;-)

> I have tried this. I do this quite often in fact (here and elsewhere).
> I've also committed patches that other people have created this way
> and it works like a charm. Note, I do this all with the SVN command
> line. I've been able to do this successfully with v1.3.2, v1.4.0 and
> v1.4.2 SVN binaries for Windows.

OK, well I'm on SVN 1.3.1 for Mac, but I think your point above
regarding the delete/move is probably the wall I was running into
repeatedly, especially as I've been doing renames too (do they survive
the diff process, or are they just a move?)

Heigh ho. Hopefully the full dump of the source tree will help out
somewhat and once that's patched, we can start doing shuffling around.
I'd still like to know what the problems are with (or arguments
against) moving the pack200 stuff in its own separate module; after
all, you don't get a JDBC driver and the JDBC APIs packaged into the
same Jar; why should the Pack200 implementation be any different?
Obviously the core Java classes (java.util.jar.pack200 etc.) would
stay where they are, but the org.apache.harmony stuff could easily be
pulled out into a separate module, thus making the build process
simpler than checking out folders piecemeal whilst also decoupling the
messages for the j.u.j and o.a.h.p2 classes and giving the o.a.h.p2
its own MANIFEST.MF. But perhaps I'm missing the big picture here ...
can someone help educate me?

Alex.

Re: Re: Re: [classlib][pack200] Status update (again)

[Nathan Beyer <nb...@gmail.com>]

On 11/22/06, Alex Blewitt <al...@gmail.com> wrote:
> On 23/11/06, Nathan Beyer <nb...@gmail.com> wrote:
> > 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?
>
> Because I don't want to build the java/util/* when I'm working on the
> org/apache/harmony/pack200 code. In fact, it gets in the way of doing
> the development because there are a number of other unsatisfiable
> dependencies without working on the rest of the codebase. If I delete
> the java/ directory from my system, SVN says that I've deleted the
> java/ directory, and there's the danger that any patch I've provided
> would end up deleting the java/ directory of a commiter instead. So I
> edit the .svn/entries file to make it look like there isn't a java/
> directory there at all, which keeps everyone happy.

Why delete the files at all, just ignore them. Just create your own
Eclipse project files an point exclusively to the pack200 files. You
can do this many ways with Eclipse; create a project and use links to
pull in just the pack200 files, work within the 'archive' module and
add exclusion filters to remove all other files.

Have you considered just checking out the pack200 files alone? Create
your project folder, create source folder and then create
"org/apache/harmony/archive/internal" and then checkout
"https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/"
to 'pack200' under 'internal' and you're set.

>
> As for building and tests run with Harmony -- I don't know that. I
> can't know that, either. But I can test that the code that I've
> written runs and does what it should providing that the underling
> java.io.InputStream/java.util.jar.JarEntry classes do what they say
> they should. I'm testing the pack200 code with respect to the contract
> of the public API classes, and I'm writing the tests to know whether
> they fall over or not so that if there are problems (either with my
> code or the current harmony java.util.jar* implementations) we can
> find and fix them. I'm not using the harmony build.xml or any of those
> processes; I'm just doing the compilation and relying as much as
> possible on the Java 1.3 APIs, because a key goal is being able to
> reuse this on older VMs and embedded in other (read: non-Harmony)
> projects. It's therefore essential that it *doesn't* rely on any
> Harmony-specific behaviour, though of course, it should also co-exist
> with Harmony.
>
> > 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.
>
> That's pretty much the same as I'm doing at the moment, though, except
> I'm doing in-place editing of the pack200 code and merging out of the
> files that are there. It's supposed to make it easier for doing diffs
> and patches, but I've yet to see that benefit.
>
> The thing is, I'm doing a lot of the work on pack200, and it's a
> really nice self-contained unit. If there were many others working on
> it as well, and all I was doing was adding little bits here and there,
> then yes, what you propose might be tenable. But I'm creating a fair
> number of classes and new classes in doing this, and merging between
> directories because of the current layout doesn't sound appealing.
>
> > 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'.
>
> The problem is, I've done 'svn del', 'svn add' and even 'svn move'.
> They do not show up in svn diff. The last couple of patches I've sent
> have not been able to be applied because they refer to files that
> aren't there, even though I've 'svn added' them to my local copy. It's
> nigh on impossible to do new development using svn and contributing
> patches like this, and to be honest, it's the main reason why I don't
> do lots of small commits. I generally budget for a week or more of
> downtime between when I've finished doing a chunk of work and filing a
> patch to after all the problems have been ironed out, and I've had to
> send in new patches or even complete zips of the files.

I know that deletes and moves can't be done via diffs, but adds can
and moves are just deletes and adds. In these cases I would just
suggest notification of files that need to be deleted in JIRA issues
and do everything ass updates and adds.

>
> Try it. Check out SVN using an anonymous URL, make a change. Add a new
> file. Do svn add. Do svn diff. Then try to apply that patch to another
> freshly checked out file. That's exactly what I'm doing, and it just
> doesn't work. SVN works fine for new development if you're a
> committer, and for contributing small fixes by patching. But it's
> really unsuitable for larger new pieces of work contributing as
> patches all the time.

I have tried this. I do this quite often in fact (here and elsewhere).
I've also committed patches that other people have created this way
and it works like a charm. Note, I do this all with the SVN command
line. I've been able to do this successfully with v1.3.2, v1.4.0 and
v1.4.2 SVN binaries for Windows.

-Nathan

>
> Alex.
>

Re: Re: Re: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

On 23/11/06, Nathan Beyer <nb...@gmail.com> wrote:
> 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?

Because I don't want to build the java/util/* when I'm working on the
org/apache/harmony/pack200 code. In fact, it gets in the way of doing
the development because there are a number of other unsatisfiable
dependencies without working on the rest of the codebase. If I delete
the java/ directory from my system, SVN says that I've deleted the
java/ directory, and there's the danger that any patch I've provided
would end up deleting the java/ directory of a commiter instead. So I
edit the .svn/entries file to make it look like there isn't a java/
directory there at all, which keeps everyone happy.

As for building and tests run with Harmony -- I don't know that. I
can't know that, either. But I can test that the code that I've
written runs and does what it should providing that the underling
java.io.InputStream/java.util.jar.JarEntry classes do what they say
they should. I'm testing the pack200 code with respect to the contract
of the public API classes, and I'm writing the tests to know whether
they fall over or not so that if there are problems (either with my
code or the current harmony java.util.jar* implementations) we can
find and fix them. I'm not using the harmony build.xml or any of those
processes; I'm just doing the compilation and relying as much as
possible on the Java 1.3 APIs, because a key goal is being able to
reuse this on older VMs and embedded in other (read: non-Harmony)
projects. It's therefore essential that it *doesn't* rely on any
Harmony-specific behaviour, though of course, it should also co-exist
with Harmony.

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

That's pretty much the same as I'm doing at the moment, though, except
I'm doing in-place editing of the pack200 code and merging out of the
files that are there. It's supposed to make it easier for doing diffs
and patches, but I've yet to see that benefit.

The thing is, I'm doing a lot of the work on pack200, and it's a
really nice self-contained unit. If there were many others working on
it as well, and all I was doing was adding little bits here and there,
then yes, what you propose might be tenable. But I'm creating a fair
number of classes and new classes in doing this, and merging between
directories because of the current layout doesn't sound appealing.

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

The problem is, I've done 'svn del', 'svn add' and even 'svn move'.
They do not show up in svn diff. The last couple of patches I've sent
have not been able to be applied because they refer to files that
aren't there, even though I've 'svn added' them to my local copy. It's
nigh on impossible to do new development using svn and contributing
patches like this, and to be honest, it's the main reason why I don't
do lots of small commits. I generally budget for a week or more of
downtime between when I've finished doing a chunk of work and filing a
patch to after all the problems have been ironed out, and I've had to
send in new patches or even complete zips of the files.

Try it. Check out SVN using an anonymous URL, make a change. Add a new
file. Do svn add. Do svn diff. Then try to apply that patch to another
freshly checked out file. That's exactly what I'm doing, and it just
doesn't work. SVN works fine for new development if you're a
committer, and for contributing small fixes by patching. But it's
really unsuitable for larger new pieces of work contributing as
patches all the time.

Alex.

Re: Re: [classlib][pack200] Status update (again)

[Nathan Beyer <nb...@gmail.com>]

On 11/22/06, Alex Blewitt <al...@gmail.com> wrote:
> On 22/11/06, Tim Ellison <t....@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
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.
>

Re: Re: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

On 22/11/06, Tim Ellison <t....@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.

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.

Re: Re: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

Tim,

The patch has been applied to the Pack200 code, and I've raised a
separate bug for the separation of the pack200 stuff:

http://issues.apache.org/jira/browse/HARMONY-2479

I still think a separate module makes sense, because even if the
build.xml compiles against 1.4, anyone who checks out the module to
work as an Eclipse project is going to inherit the 1.5 compiler
settings and be tempted to start sticking generics all over the place.
And it won't be clear from the person editing it what the compilation
error is, because it won't show up in Eclipse, just fall over when
checked into the build.

Having a separate module would allow a separate Eclipse project to be
loaded, with separate compiler checks during editing, as well as
manipulation of the Manifest.MF separately. And then it's pretty much
an OSGi bundle ready to roll for other uses.

Alex.

On 22/11/06, Tim Ellison <t....@gmail.com> 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.

Re: [classlib][pack200] Status update (again)

[Tim Ellison <t....@gmail.com>]

Alex Blewitt wrote:
> Good news, everyone!
> 
> I've managed to get multiple interfaces extracted from a Pack200
> archive, along with methods, exceptions, interfaces and constant
> values (char etc.) The next step is to decode bytecodes, but there's a
> fair bit of work involved in reconstituting the bytecode part of it
> (so non-abstract methods or non-constant initialisers still don't
> work).
> 
> Anyway, the current code is in Harmony-2246 but I'm likely to take a
> brief hiatus. It would be good if the patch could be applied
> (successfully this time :-) before I pick up the next bit of work.
> 
> 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.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Re: [classlib][pack200] Status update (again)

[Alexey Petrenko <al...@gmail.com>]

Great job, Alex!

I'll take care on 2246.

SY, Alexey

2006/11/22, Alex Blewitt <al...@gmail.com>:
> Good news, everyone!
>
> I've managed to get multiple interfaces extracted from a Pack200
> archive, along with methods, exceptions, interfaces and constant
> values (char etc.) The next step is to decode bytecodes, but there's a
> fair bit of work involved in reconstituting the bytecode part of it
> (so non-abstract methods or non-constant initialisers still don't
> work).
>
> Anyway, the current code is in Harmony-2246 but I'm likely to take a
> brief hiatus. It would be good if the patch could be applied
> (successfully this time :-) before I pick up the next bit of work.
>
> 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.
>
> Alex.
>