Это правильный подход для структурирования кодовой базы?

Question

У нас есть кодовая база Java, которая в настоящее время является одним веб-проектом Netbeans. По мере роста нашей организации и кодовой базы становится очевидным, что мы должны разделить различные независимые части нашей системы на отдельные банки. Итак, одна библиотека Jar для слоя доступа к данным, одна для общей библиотеки, одна для доступа к специализированным знаниям и т. Д. Тогда у нас будет отдельный проект для веб-приложения, и может быть один для приложения инструментов командной строки, другой веб-приложение и т. д.

Какова рекомендуемая практика для выполнения и управления этим? Это Maven? Может ли все это быть эффективно сделано только с помощью Netbeans, просто создав отдельные проекты и установив зависимости одного проекта от jar-файлов других?

Answer 1

Я бы согласился со SteveG выше в использовании Maven2, чтобы помочь вам модульно реализовать свою кодовую базу, но я бы использовал Nexus в качестве локального хранилища для Maven вместо Archiva. У ребят из Sonatype также есть отличная (бесплатная html / pdf) книга о том, как использовать Maven, Nexus и интегрировать ее в IDE.

Будьте осторожны с тем, как вы решили разделить свои проекты. Нет смысла чрезмерно усложнять ваши зависимости только ради этого.

Answer 2

Я бы точно сказал, проверь Maven (2). Это очень хорошо для такого рода вещей. Вы можете определить отдельные модели и версию тогда очень легко. Netbeans также неплохо интегрируется с.

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

Answer 3

Звучит так, будто ваш код подходит к тому моменту, когда вы заканчиваете WAR-подход и переходите на уровень EAR.

EAR - это просто еще один архив, содержащий все другие JAR и WAR, которые объединяются для создания приложения. Внутри него могут находиться четыре типа модулей: Web, EJB, Connectors и Utilities. Большинство людей используют только Интернет и утилиты, поэтому они используют подход WEB-INF / lib.

Но если вы начинаете получать много взаимозависимостей, то, что вы делаете, создает проект EAR и делает свой веб-проект дочерним по отношению к нему. Каждый Utility JAR, который является простым Java-кодом, используемым другими модулями, также становится дочерним для EAR. Наконец, в каждом из ваших проектов должен быть файл META-INF / manifest.mf, в котором просто указано имя JAR-файла, от которого зависит JAR / WAR.

Я парень по затмениям, и большинство из них позаботятся о вас в затмении, но я уверен, что у netbeans очень похожая функциональность.

Теперь единственная проблема заключается в том, что вам нужно использовать полноценный сервер Java EE для развертывания EAR, поэтому я не думаю, что вы можете использовать Tomcat, если вы используете его сейчас.

Answer 4

Я бы создал ant сценарии для сборки частей и для развертывания. Тогда вы не зависите от вашей IDE для сборки / развертывания.