OK, sounds good. Another question: it looks like some packing renaming / code restructuring has gone on as part of this effort, unless I'm missing something. I see things like class DestroySharedGroup having a package statement at the top like
package org.apache.river.start; but it's physical location is now org/apache/river/start/destroy, and so the compiler complains that the declared and actual packages don't match. There are quite a few examples of this. Is there any simple heuristic to know which one is right? eg, a rule saying "the declared package in the code is right" OR "the actual physical location is right and the package declaration should change." Just for grins and giggles I stared down the path of doing the latter to see if I could get things to compile, and I find that that also causes issues due to things like package visibility. Some classes depend on references to fields in other classes that are not visible if you use the "altered" package declaration. For example, the aforementioned DestroySharedGroup references fields on ServiceStarter and ServiceDescriptor that were "package private". For example, the ServiceStarter.logger field. Any advice on the best way to resolve these things? Phil
