Доброго времени суток, товарищи!

Хочется собрать информацию, узнать у более опытных коллег и найти реальные кейсы,чтобы не изобретать велосипед как организуется грамотно работа над Java проектом.
Мои мысли такие. 1) Нужно описать формально проект в IDE-независимом виде — это Maven. 2) Хранить зависимости в репозитории типа Nexus 3) IDE — тут выбор небольшой Netbeans и Eclipse 4) Нужна source code management система+багтрекер. Тут есть неопределенность, что выбрать по удобству и простоте подъема своего сервера и интеграции с IDE/багтрекером. Какие есть проверенные варианты Netbeans+<SCM>+<багтрекер>? 5) Статические анализаторы кода FindBug + визуализация проекта ( LOC/классы/etc ) + codestyle checker'ы 6) Jenkins, continuous integration ( билды по изменению кода )

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

Спасибо!

Здравствуйте, SK_Egoryan, Вы писали:

SK_>Был бы очень рад услышать мнения или увидеть ссылки/материалы на то как это грамотно организуется.

Мы используем Eclipse + Jazz.NET (https://jazz.net/). Последнее и багтрэкинг и контроль версий.

Здравствуйте, SK_Egoryan, Вы писали:

SK_> 1) Нужно описать формально проект в IDE-независимом виде — это Maven.

Для нового проекта сойдет. Для существующего лучше что-нибудь типа Gradle.

SK_> 2) Хранить зависимости в репозитории типа Nexus

Зависимости в VCS. Все равно управлять зависимостями нужно руками.

SK_> 3) IDE — тут выбор небольшой Netbeans и Eclipse

IDEA вне конкуренции.

SK_> 4) Нужна source code management система+багтрекер. Тут есть неопределенность, что выбрать по удобству и простоте подъема своего сервера и интеграции с IDE/багтрекером. Какие есть проверенные варианты Netbeans+<SCM>+<багтрекер>?

Jira + FishEye + git

SK_> 5) Статические анализаторы кода FindBug + визуализация проекта ( LOC/классы/etc ) + codestyle checker'ы

Sonar

SK_> 6) Jenkins, continuous integration ( билды по изменению кода )

Bamboo

SK_>Был бы очень рад услышать мнения или увидеть ссылки/материалы на то как это грамотно организуется.

В общем-то ты сам нормально расписал.

Здравствуйте, Miroff, Вы писали:

SK_>> 2) Хранить зависимости в репозитории типа Nexus
M>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.

Здравствуйте, ., Вы писали:

.>Здравствуйте, Miroff, Вы писали:

SK_>>> 2) Хранить зависимости в репозитории типа Nexus
M>>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
.>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.

Почему что? Зависимости в VCS? Потому что проект после чекаута должен собираться одной командой. Зависимости это неотъемлемая часть проекта. Проект протестирован на определенном наборе библиотек и любое изменение это8го набора потребует хотя бы тестирования. Поэтому, кстати, и управлять зависимостями должен человек, а не репозиторий. Представьте, что что будет когда в зависимостях популярного тиражируемого продукта автоматически подтянется библиотека c лицензией 4-clause BSD license.

Бинарники в современных VCS не мешают мерджам, во всяком случае я о таком не слышал. Просто мерджить их нужно не по содержимому, а по версии. Мердж это достаточно редкая операция, чтобы это было проблемой.

Здравствуйте, Miroff, Вы писали:

SK_>>>> 2) Хранить зависимости в репозитории типа Nexus
M>>>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
.>>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
M>Почему что? Зависимости в VCS? Потому что проект после чекаута должен собираться одной командой. Зависимости это неотъемлемая часть проекта. Проект протестирован на определенном наборе библиотек и любое изменение это8го набора потребует хотя бы тестирования. Поэтому, кстати, и управлять зависимостями должен человек, а не репозиторий. Представьте, что что будет когда в зависимостях популярного тиражируемого продукта автоматически подтянется библиотека c лицензией 4-clause BSD license.
Не понимаю зачем. Репозиторий делает это лучше. У нас около сотни библиотек, человек легко запуается или нужно выделять одного человека, который во всем этом разбирается. Набор библиотек описывается в pom.xml, который текстовый файл и замечательно мержится.
Большинство либ в публичном репозитории, остальные — прописываются в том же pom.xml и всё собирается одной командой.
Древовидный список либ можно поглядеть, глазками, он довольно компактен. Пробежаться по именам либ и прикинуть что к чему.

M>Бинарники в современных VCS не мешают мерджам, во всяком случае я о таком не слышал.
Когда мержится с конфликтом в бинарике, нельзя понять по бинарику что же случилось. Только как-то копать что же именно не так.
А ещё DVCS качают репо целиком, а значит все бинарники всех версий будут клонироваться — растёт размер репо.
Если используется maven repo, то при сборке скачаются только текущие версии.

M> Просто мерджить их нужно не по содержимому, а по версии. Мердж это достаточно редкая операция, чтобы это было проблемой.
Смотря какой workflow. Если нормальная VCS и "branch by feature", то мержи частые.

Здравствуйте, SK_Egoryan, Вы писали:

А людей сколько в проекте будет или уже есть? Если есть, то можно у комманды проще спросить, что бы им было бы удобнее.

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

SK_>Доброго времени суток, товарищи!

SK_> Хочется собрать информацию, узнать у более опытных коллег и найти реальные кейсы,чтобы не изобретать велосипед как организуется грамотно работа над Java проектом.
SK_> Мои мысли такие. 1) Нужно описать формально проект в IDE-независимом виде — это Maven. 2) Хранить зависимости в репозитории типа Nexus 3) IDE — тут выбор небольшой Netbeans и Eclipse 4) Нужна source code management система+багтрекер. Тут есть неопределенность, что выбрать по удобству и простоте подъема своего сервера и интеграции с IDE/багтрекером. Какие есть проверенные варианты Netbeans+<SCM>+<багтрекер>? 5) Статические анализаторы кода FindBug + визуализация проекта ( LOC/классы/etc ) + codestyle checker'ы 6) Jenkins, continuous integration ( билды по изменению кода )

SK_>Был бы очень рад услышать мнения или увидеть ссылки/материалы на то как это грамотно организуется.

SK_>Спасибо!

M>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
Каменный век какой-то.

M>Почему что? Зависимости в VCS? Потому что проект после чекаута должен собираться одной командой.
Верно. И этой командой вполне может быть mvn compile.

M>Зависимости это неотъемлемая часть проекта. Проект протестирован на определенном наборе библиотек и любое изменение это8го набора потребует хотя бы тестирования. Поэтому, кстати, и управлять зависимостями должен человек, а не репозиторий.
Репозитории существуют ровно для одного — для организованного хранения зависимостей. Управляет зависимостями в проекте в любом случае человек. VCS никак не поможет вам в случае изменения набора библиотек, равно как и репозиторий, потому что это вы должны выстроить свои бизнес-процессы таким образом, чтобы проект был устойчив к подобным изменениям: правильно организовать апгрейды, тестирование, лицензирование. Вы, видимо, не понимаете одной простой вещи: то, что в случае VCS вам придется делать руками — организовывать в папочки десятки и сотни jar-файлов с классами и исходниками, системы управления библиотеками в Maven или Ivy делают автоматически.

M>Представьте, что что будет когда в зависимостях популярного тиражируемого продукта автоматически подтянется библиотека c лицензией 4-clause BSD license.
Управление лицензиями — отдельный вопрос, не связанный с тем, где именно хранятся зависимости.

Здравствуйте, ., Вы писали:

.>Не понимаю зачем. Репозиторий делает это лучше.

Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять. Или что вы внезапно должны открыть исходники своего сервиса, потому что в зависимостях затесалась библиотека под AGPL. Это даже с людьми бывает с удручающей регулярностью. Но люди существа наблюдательные и иногда замечают проблемы до того как они привели к серьезным последствиям. Если вы положитесь на робота, вы будете узнавать о лицензионных проблемах от своего юриста, а о технических от пользователей.

Здравствуйте, Baudolino, Вы писали:

M>>Вы, видимо, не понимаете одной простой вещи: то, что в случае VCS вам придется делать руками — организовывать в папочки десятки и сотни jar-файлов с классами и исходниками, системы управления библиотеками в Maven или Ivy делают автоматически.

Я это прекрасно понимаю, как и то, что цена за эту автоматизацию либо поддержка собственного репозитория (что оправданно только в случае очень больших компаний), либо увеличение рисков связанных с внешними репозиториями (из репозитория приедет что-нибудь не то; репозиторий свалится; репозиторий будет скомпроментирован и т.п.) Для open source библиотек я вполне успешно использую maven, но для коммерческого Java проекта с количеством библиотек порядка сотни эта цена слишком велика.

M>Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять.

Вы все верно пишете. Просто хочу отметить, что далеко не все пишут по-настоящему серьезные и тиражируемые "коробочные" продукты. Хуже того, по моим наблюдениям, большинство программистов заняты во всяческих "внутренних автоматизациях" и прочих "оперднях", и у них нет вообще никакого представления о мире коробочного софта. Ни о лицензиях, ни о соглашениях. Часто и о дедлайнах-то понятий нет.
В общем, то, о чем пишете вы — это серьезные меры и серьезные варианты решения не самых простых проблем. Тогда как значительная часть (ИМХО большинство) занимается куда менее серьезными вещами. Если угодно, — копается в песочнице. Так ведь не всем же коробочный софт писать...

Здравствуйте, Miroff, Вы писали:

.>>Не понимаю зачем. Репозиторий делает это лучше.
M>Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять. Или что вы внезапно должны открыть исходники своего сервиса, потому что в зависимостях затесалась библиотека под AGPL. Это даже с людьми бывает с удручающей регулярностью. Но люди существа наблюдательные и иногда замечают проблемы до того как они привели к серьезным последствиям. Если вы положитесь на робота, вы будете узнавать о лицензионных проблемах от своего юриста, а о технических от пользователей.
Умеет немного. Maven позволяет избавиться от ручных проверок. А что не умеет, можно допилить, если в вашем проекте это очень важно. Как уже кто-то сказал, подавляющее большинство проектов не парятся по этому поводу. Так что такие советы вредны.

M>Я это прекрасно понимаю, как и то, что цена за эту автоматизацию либо поддержка собственного репозитория (что оправданно только в случае очень больших компаний)
Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?

Здравствуйте, Baudolino, Вы писали:

B>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?

А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.

Здравствуйте, ., Вы писали:

SK_>>> 2) Хранить зависимости в репозитории типа Nexus
M>>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
.>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
Как уже было сказано, мержить бинарники нужно по версиям, а не по содержимому.
И после этого тщательно тестировать. Потому как все равно может поломаться.

Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход.

СУВ, Aikin

Здравствуйте, Miroff, Вы писали:

B>>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?
M>А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.
Да, но по велению мавена. Один раз скачаются и будут там всегда лежать. Автоматически и поэтому надёжнее и быстрее, в отличие от твоего варианта — ходить по куче сайтов с либами и качать всё вручную, подбирая подходящие версии и осторожно всё коммитя.
Если очень хочется, то можно и бэкапы для nexus настроить, если страшно, что публичные репозитории и локальные репозитории на всех машинах разработчиков могут вдруг сразу совсем умереть.

Здравствуйте, ., Вы писали:

B>>>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?
M>>А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.
.>Да, но по велению мавена. Один раз скачаются и будут там всегда лежать. Автоматически и поэтому надёжнее и быстрее, в отличие от твоего варианта — ходить по куче сайтов с либами и качать всё вручную, подбирая подходящие версии и осторожно всё коммитя.
Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам.
Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

.>>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
A>Как уже было сказано, мержить бинарники нужно по версиям, а не по содержимому.
Скажем, лежит у тебя в разных ветках файлик hornetq-core.jar. Начинаешь мерж — а он разный, вылез конфликт. И что дальше? Где какая версия? А от каких других либ оно зависит и какие у них версии?
А если в имя файла ставить номер версии, например, antlr-2.7.6.jar, то после мержей у тебя в одной ветке вдруг может оказаться две разных версии одной либы, а обнаружишь это только когда где-то ВНЕЗАПНО грохнется какой-нибудь LinkageError. Мавен же умеет разруливать это.

A>И после этого тщательно тестировать. Потому как все равно может поломаться.
Это да, тщательно тестировать всегда надо.

A>Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход.
Можно и отвёрткой забивать гвозди, но лучше пускай зависимостями управляет система управления зависимостями, а система управления исходниками управляет исходниками.

Здравствуйте, Aikin, Вы писали:

A>Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам.
A>Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS.
Так это для .NET, аналог мавена. Мавена нет, вот и приходится по старинке в VCS — выбора-то нет. Или я не понял и это и для java-мира как-то можно использовать?