On 17 July 2013 00:52, Chris Cunningham <cunningham.cb at gmail.com> wrote:
> So, after step 1, you also need to hunt down the various extensions - in
> FileStream and other places - that is part of the Compression package, and
> move them to one of the new packages.  Otherwise you innadvertantly remove
> those methods.  (Currently all of these are just under *Compression - no
> sub-category...)

Thanks. That's a very, very good point. So a sanity check where I
count the number of expected classes and methods in Compression would
be in order: after the split the sums of classes and methods in the
subpackages should match!

frank

> -Chris
>
>
> On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 16 July 2013 22:30, Frank Shearar <frank.shearar at gmail.com> wrote:
>> > I would like to split the Compression package into its two constituent
>> > subpackages, Compression-Archives and Compression-Streams.
>> >
>> > Files depends on things in Compression-Archives, and
>> > Compression-Streams depends on Files. If I can split the package and
>> > replace it with the two subpackages, I can untangle this cyclic
>> > dependency.
>> >
>> > But how would I actually do this? I've tried making two packages, for
>> > instance. However, the classes still remain in Compression... as you
>> > can see if you try to unload the old Compression package.
>>
>> One possible way goes something like this:
>> * Add CompressionArchives and CompressionStream packages corresponding
>> to the hyphenated system categories
>> * Push a new config map with the "new" packages
>> * Push the empty Compression package
>> * Remove the Compression package using a config map
>> * Rename CompressionArchives to Compression-Archives and same for Stream
>> * Push a third config map removing Compression and adding
>> Compression-Archives and Compression-Stream
>>
>> > frank
>>
>
>
>
>