Jar упаковка и распространение - PullRequest
0 голосов
/ 22 июля 2011

У нас есть некоторый общий код, разложенный в пакетах, как и ожидалось.Некоторые из этих пакетов handler, processor, util, registration и т. Д.

Общие здесь означают, что они будут повторно использоваться в нескольких проектах Java / Java EE , которые не связаны друг с другом.

Вопрос касается упаковки для распространения.

Каждый пакет состоит из различных функциональных блоков, но вместе они представляют собой API.

Если мы объединяем отдельные функции в JARи в итоге скажем 8 - 10 банок.например: jar-обработчик, jar-файл регистрации и т. д.

или

Следует ли использовать метод наименьшего общего знаменателя, который представляет собой базовую сборку из 5 обязательных пакетов в одном банке.Любой другой нуждается в этом jar в качестве основы и может выбрать дополнительные jar.

Наша система сборки - Ant + Ivy, и эти зависимости будут разрешены во время компиляции и сборки.

Ответы [ 3 ]

5 голосов
/ 22 июля 2011

Если у вас не так много классов API (например, Spring) или вы не знаете о каких-либо помехах между ними, я считаю, что есть очень мало причин разбивать их на отдельные банки.Единственная другая причина разбить API в отдельных банках - это позволить различным командам работать независимо друг от друга.

Управление одним банком упрощает многие вещи и не стоит исправлять несуществующую проблему.

0 голосов
/ 22 июля 2011

Если API огромен, лучше разбить его на несколько банок, в противном случае создайте несколько банок

Преимущества одной банки Если какое-либо приложение хочет использовать более одной банки, например, регистрацияа также утил.он / она должен включать только 1 банку.

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

0 голосов
/ 22 июля 2011

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

Одна большая банка имеет преимущество более легкого распределения. Например, если ваши пользователи загружают банку из интернета и устанавливают их вручную, проще справиться с одной банкой, чем со многими. Но если это не так, я бы порекомендовал вам использовать решение с несколькими банками. Но не забудьте проштамповать каждую банку с ее версией. По крайней мере, поместите версию в файл manifest.mf. Maven также помещает версию как часть имени фляги. Это очень хорошая практика.

...