Обновление проекта, который расширяет класс, удаленный в проекте зависимостей

Question

Представьте, что у вас есть пакет MyPackage, и это зависит от другого проекта под названием Library. MyPackage имеет методы расширения в классе LibraryClass, который находится в проекте Library.

В какой-то момент Library изменен и LibraryClass переименован в NewLibraryClass или удален полностью. Вы вносите изменения в свой проект, например, применяете методы расширения до NewLibraryClass или решаете его по-другому, это не имеет большого значения.

Проблема возникает, когда у кого-то есть pre-Library -changes версия MyPackage уже установлена ​​и обновляет ее. Затем сначала загружается пакет Library, так как ваш проект зависит от него. Пока Library загружается LibraryClass удаляется, и поэтому MyPackage методы расширения, которые присутствовали в LibraryClass, удаляются. Это означает, что MyPackage является грязным, и поэтому, когда он, наконец, загружает изменения в MyPackage, пользователю предлагается разрешить слияние, даже если нет реальных конфликтов.

Как это можно решить? Потому что в конечном итоге ваш код в порядке, но пользователь, который обновляет ваш проект, столкнется с проблемами странного слияния.

Answer 1

У меня есть хак, который нельзя квалифицировать как полное решение, но помогает преодолеть эту проблему.

В конфигурации вашего проекта добавить DoIt предварительной нагрузки (раздел 1.10 Managing projects with Metacello) и вызывать этот метод:

cleanUpLibrary 

    | myPackage | 

    myPackage := (#MyPackage asPackageIfAbsent: [^self ]). 

    LibraryClass asClassIfPresent: [ :class | 
    class protocols 
     select: [ :prot | prot asLowercase beginsWith: myPackage methodCategoryPrefix ] 
     thenDo: [ :prot | class removeProtocol: prot ] ]. 

    myPackage mcWorkingCopy modified: false 

Это удалит все протоколы внутренних линий MyPackage от LibraryClass и отметьте MyPackage не изменен (чистый, не грязный ...). Тогда, когда Library будет загрузка и удалит LibraryClass, MyPackage не будут помечены как грязные, потому что в тот момент LibraryClass не будет иметь каких-либо методов расширения из MyPackage