Alex, Don't worry too much about the code being in the archive module, I agree that it makes sense to keep the Pack200 code separate so that it can be reused in Eclipse/Classpath/whatever and putting it into archive does not preclude that.
The harmony archive component keeps it separated for access control reasons (based on people's prior access as declared in the contributor questionnaire) and for harmony corresponds to a packaging/modularity story (the code will go into archive.jar). As you know, you have a separate package space in archive (o.a.h.a.i.pack200) and there is no reason why that package (or any others that you need with that prefix) cannot be extracted, built and packaged separately for sharing. Obviously you have to continue to ensure that you implement with Java APIs that will be found elsewhere, and harmony will ensure that there is loose coupling into the pack200 implementation. So keep going! If you would prefer to see a separate target in the archive build.xml that produces just a pack200.jar then I'm sure that could be arranged too. Thanks for the continued contribution. Regards, Tim Alex Blewitt wrote: > On 21/06/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: >> On 6/21/06, Alex Blewitt wrote: >> >> We agreed to separate providers implementation [1]. But I'm not sure the >> same should be done for a concrete class implementation. In you case it >> is implementation of java.util.jar.Pack200 but there are lots of other >> cases >> ,for example, java.security.Policy. So we'll got a lot of modules with >> only >> one class inside. > > It's not just a concrete class, though. The API basically boils down > to two methods: > > unpack() > pack() > > The thing is, that an implementation of this JSR isn't just a simple > class that provides a couple of methods. There's a lot of detail in > the coding, decoding, and subsequent parsing that goes on. There's > also a few other utilities that would be useful for performing > compression on data streams if people would be interested in using > them. > > So don't confuse a simple API with a simple solution :-) The > providers/ would be exactly the right place for this kind of code to > live (at least, for the implementation). There are stub classes that > are needed in the archive/ module, such as java.util.jar.Packer along > with the factory code to instantiate the provider; but the factory > instantiating the provider is actually specified as part of the > Packer's static access methods. > > Alex. > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
