Yeah, it would be easy enough to do :-) I've added some comments in the header of each file to that effect. As for the (indirect) ties with o.a.h.k.VM, that's just an implementation issue with the Messages class; it should be fairly easy to roll out a less specific one for the pack200 messages.
Alex. On 15/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I'm assuming that the person just didn't know... Please put a readme into the root of the codebase so that these special circumstances are known by others (assuming someone doesn't have a big problem with it...) geir Alex Blewitt wrote: > On a related note, it seems that some changes have been committed that > are using generics in the pack200 code. These will prevent it from > being run on pre Java 1.5 systems, which again was one of my goals in > writing this. I'll have to revert those changes, too ... > > Alex. > > On 15/10/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: >> I was in the process of trying to put together a patch for the new >> stuff that I've added recently, and it turns out that someone's gone >> through and pulled out all of the hard-coded strings in the code and >> added a dependency on >> org.apache.harmony.archive.internal.nls.Messages, which in turn has a >> dependency on org.apache.harmony.kernel.VM. This causes a few >> problems: >> >> 1) There's now a tighter dependency from the pack200 code to the >> Harmony VM. As I've noted previously, I was wanting to develop this as >> a portable implementation of pack200 so that others could use it >> outside of Harmony; for example, on JVMs prior to 1.5 that don't have >> it built in. >> >> 2) The messages for Pack200 are now mixed up with the messages for the >> remainder of the archive code, when they don't need to be. That means >> exporting/building a separate Pack200 is going to have extra detritus >> in it that doesn't n eed to be there. >> >> 3) There were a bunch of messages that I was leaving in the code (in >> Error messages) reminding me to implement certain facets of the code, >> that were never meant to be extracted. These have now been extracted >> into a messages file with less than helpful 'archive.1C' messages left >> behind. >> >> I'd really like to undo this set of changes and leave message >> externalisation until later, once the implementation is complete. I >> also want to avoid getting the pack200 stuff tied up any more than is >> necessary with the Harmony VM, because it should be possible to use >> this on other VMs (or even the standard Java Sun VM ... the pack200 >> code is switchable based on a property in any case). >> >> I'd also like to move the pack200 into its own module, so that when >> messages do get externalised, they can be processed just for that >> particular set of code and not lumped in with the remainder of the >> archive code. I did suggest this in the past, although there was a >> conclusion at the time that it wasn't worth doing at that time. I feel >> that this is now the justification to separate the pack200 and archive >> modules before it gets any more joined together. >> >> I'll hold off updating and submitting a patch until we can figure out >> what's best to do with the code. >> >> Alex. >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
