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: Re: Re: [classlib][pack200] Status update (again)
Date Thu, 23 Nov 2006 23:28:42 GMT
On 11/23/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
> On 23/11/06, Nathan Beyer <nbeyer@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

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


> Alex.

View raw message