BlackBerry - избегайте дублирования имен пакетов при использовании общей библиотеки

Question

Мы пишем приложения для контракта - у нас есть много приложений, и все они используют нашу библиотеку. Но мы не можем контролировать, когда они будут выпущены, это зависит от клиентов, поэтому у них у всех разные версии нашей библиотеки (которая всегда добавляется).

Я хотел бы знать, как правильно использовать одно и то же имя пакета для библиотеки в каждом проекте? Я верю, что это имеет смысл для более опытных разработчиков BB здесь.

Для моих сборок дистрибутива я реорганизую библиотеку, чтобы использовать уникальное имя пакета для этого проекта (обычно путем помещения имени клиента в структуру пакета). Но это добавляет время, неприятности и путаницу с SVN-клиентами Eclipse. Кажется, совершенно неправильно делать это таким образом (но это работает).

Должен быть правильный способ сделать это, даже какой-нибудь инструмент или сценарий, так как каждый раз заставлять идти по этому пути кажется неправильным. Как правильно избежать этой проблемы.

---

Объяснение, почему это проблема:

• Если вы устанавливаете много приложений, используя где-то одинаковую структуру пакетов, то устройство перезаписывает пакеты. например Если я использую com.ric.sdk в качестве своей библиотеки, то каждое приложение, использующее мой SDK, будет перезаписывать любую версию.

Это здорово, если мы будем только каждое обновление. Для нас некоторые проблемы сталкиваются одновременно, создавая проблему для нас:

1. Мы пишем приложения для множества разных клиентов, и нам нравится использовать наш общий код для каждого клиента.
2. Мы новая компания, и наша SDK растет. Каждое приложение обычно добавляет несколько методов к тому или иному классу. Таким образом, каждое новое приложение нуждается в новейшей SDK. Старые приложения будут по-прежнему работать с новым SDK. Новые приложения порвутся со старым sdk.
3. У нас нет управления выпуском, поэтому мы не можем быть уверены, что все приложения всегда имеют последнюю версию SDK.

например. у нас есть приложение для потокового радио, которое было создано 8 месяцев назад. И приложение для потокового видео (не связанный клиент) от 3 месяцев назад. Приложение отслеживания транспортных средств за этот месяц. Если кто-то устанавливает приложение для отслеживания, а затем после того, как находит и устанавливает приложение для радиосвязи, новый SDK перезаписывается старым, и приложение для отслеживания перестает работать, поскольку оно несовместимо со старым SDK.

(этот вопрос касается тех же проблем: Делятся ли приложения, загруженные из App World, с общими проектами? )

Мы выучили урок и теперь перед финальной сборкой каждого приложения реорганизуем sdk с уникальным именем, например. radio.ric.sdk или video.ric.sdk.

Но это ужасный процесс, портящий SVN, теряющий время, допускающий человеческие ошибки и т. Д. - есть ли инструмент, который делает это для меня? Я не верю, что мы делаем это правильно.

Answer 1

jarjar - инструмент, который вы хотите использовать.Это позволяет вам взять файл jar и переименовать все классы, чтобы они не конфликтовали с другими пользователями файла jar.В вашем случае вы бы добавили имя клиента в пакет.Краткое описание jarjar:

Jar Jar Links - это утилита, которая позволяет легко упаковать библиотеки Java и встроить их в свой собственный дистрибутив.Это полезно по двум причинам:

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

Answer 2

Основываясь на том, что я прочитал за последние несколько месяцев, я обнаружил, что инструмент для использования, BlackBerry Ant Tools , может быть полезен. Я думаю, что ответ заключается в том, чтобы использовать его для основной сборки, а затем использовать jarjar (см. Принятый ответ Майкла Донахью) для переименования пакета.

---

С сайта:

Что такое bb-ant-tools?

Blackberry Ant Tools - это набор задач для создания приложений Blackberry. Он разработан так, чтобы быть максимально простым, но при этом достаточно мощным, чтобы полностью заменить RIM JDE. Однако копия JDE должна быть установлена ​​для jar-файлов инструментов rapc и signature.

Answer 3

Как правило, если у вас есть что-то, использующее PersistentStore, вам нужно изменить предоставленный ключ, если вы хотите избежать этой ошибки дублирующегося пакета. Я тоже это испытал, и простое увеличение числа на 1 позволило мне использовать один и тот же пакет в нескольких проектах.