Хочется собрать информацию, узнать у более опытных коллег и найти реальные кейсы,чтобы не изобретать велосипед как организуется грамотно работа над 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 ( билды по изменению кода )
Был бы очень рад услышать мнения или увидеть ссылки/материалы на то как это грамотно организуется.
Спасибо!
Re: Организация экосистемы для работы над Java проектом
Здравствуйте, 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>+<багтрекер>?
Здравствуйте, Miroff, Вы писали:
SK_>> 2) Хранить зависимости в репозитории типа Nexus M>Зависимости в VCS. Все равно управлять зависимостями нужно руками.
Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
.>Здравствуйте, Miroff, Вы писали:
SK_>>> 2) Хранить зависимости в репозитории типа Nexus M>>Зависимости в VCS. Все равно управлять зависимостями нужно руками. .>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
Почему что? Зависимости в VCS? Потому что проект после чекаута должен собираться одной командой. Зависимости это неотъемлемая часть проекта. Проект протестирован на определенном наборе библиотек и любое изменение это8го набора потребует хотя бы тестирования. Поэтому, кстати, и управлять зависимостями должен человек, а не репозиторий. Представьте, что что будет когда в зависимостях популярного тиражируемого продукта автоматически подтянется библиотека c лицензией 4-clause BSD license.
Бинарники в современных VCS не мешают мерджам, во всяком случае я о таком не слышал. Просто мерджить их нужно не по содержимому, а по версии. Мердж это достаточно редкая операция, чтобы это было проблемой.
Re[4]: Организация экосистемы для работы над Java проектом
Здравствуйте, 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", то мержи частые.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Организация экосистемы для работы над Java проектом
А людей сколько в проекте будет или уже есть? Если есть, то можно у комманды проще спросить, что бы им было бы удобнее.
пункты 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_>Спасибо!
Re[2]: Организация экосистемы для работы над Java проектом
M>Почему что? Зависимости в VCS? Потому что проект после чекаута должен собираться одной командой.
Верно. И этой командой вполне может быть mvn compile.
M>Зависимости это неотъемлемая часть проекта. Проект протестирован на определенном наборе библиотек и любое изменение это8го набора потребует хотя бы тестирования. Поэтому, кстати, и управлять зависимостями должен человек, а не репозиторий.
Репозитории существуют ровно для одного — для организованного хранения зависимостей. Управляет зависимостями в проекте в любом случае человек. VCS никак не поможет вам в случае изменения набора библиотек, равно как и репозиторий, потому что это вы должны выстроить свои бизнес-процессы таким образом, чтобы проект был устойчив к подобным изменениям: правильно организовать апгрейды, тестирование, лицензирование. Вы, видимо, не понимаете одной простой вещи: то, что в случае VCS вам придется делать руками — организовывать в папочки десятки и сотни jar-файлов с классами и исходниками, системы управления библиотеками в Maven или Ivy делают автоматически.
M>Представьте, что что будет когда в зависимостях популярного тиражируемого продукта автоматически подтянется библиотека c лицензией 4-clause BSD license.
Управление лицензиями — отдельный вопрос, не связанный с тем, где именно хранятся зависимости.
Re[5]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
.>Не понимаю зачем. Репозиторий делает это лучше.
Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять. Или что вы внезапно должны открыть исходники своего сервиса, потому что в зависимостях затесалась библиотека под AGPL. Это даже с людьми бывает с удручающей регулярностью. Но люди существа наблюдательные и иногда замечают проблемы до того как они привели к серьезным последствиям. Если вы положитесь на робота, вы будете узнавать о лицензионных проблемах от своего юриста, а о технических от пользователей.
Re[5]: Организация экосистемы для работы над Java проектом
Здравствуйте, Baudolino, Вы писали:
M>>Вы, видимо, не понимаете одной простой вещи: то, что в случае VCS вам придется делать руками — организовывать в папочки десятки и сотни jar-файлов с классами и исходниками, системы управления библиотеками в Maven или Ivy делают автоматически.
Я это прекрасно понимаю, как и то, что цена за эту автоматизацию либо поддержка собственного репозитория (что оправданно только в случае очень больших компаний), либо увеличение рисков связанных с внешними репозиториями (из репозитория приедет что-нибудь не то; репозиторий свалится; репозиторий будет скомпроментирован и т.п.) Для open source библиотек я вполне успешно использую maven, но для коммерческого Java проекта с количеством библиотек порядка сотни эта цена слишком велика.
Re[6]: Организация экосистемы для работы над Java проектом
M>Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять.
Вы все верно пишете. Просто хочу отметить, что далеко не все пишут по-настоящему серьезные и тиражируемые "коробочные" продукты. Хуже того, по моим наблюдениям, большинство программистов заняты во всяческих "внутренних автоматизациях" и прочих "оперднях", и у них нет вообще никакого представления о мире коробочного софта. Ни о лицензиях, ни о соглашениях. Часто и о дедлайнах-то понятий нет.
В общем, то, о чем пишете вы — это серьезные меры и серьезные варианты решения не самых простых проблем. Тогда как значительная часть (ИМХО большинство) занимается куда менее серьезными вещами. Если угодно, — копается в песочнице. Так ведь не всем же коробочный софт писать...
Re[6]: Организация экосистемы для работы над Java проектом
Здравствуйте, Miroff, Вы писали:
.>>Не понимаю зачем. Репозиторий делает это лучше. M>Репозиторий не умеет читать лицензии и разруливать противоречия с несовместимыми библиотеками. Когда у вас за сутки до дедлайна обнаружится что какая-нибудь фича отвалилась из-за того что репозиторий подсунул несовместимую версию библиотеки, будет весело. Или когда выяснится, что вы зарелизили проект c библиотекой, которую не имели права распространять. Или что вы внезапно должны открыть исходники своего сервиса, потому что в зависимостях затесалась библиотека под AGPL. Это даже с людьми бывает с удручающей регулярностью. Но люди существа наблюдательные и иногда замечают проблемы до того как они привели к серьезным последствиям. Если вы положитесь на робота, вы будете узнавать о лицензионных проблемах от своего юриста, а о технических от пользователей. Умеет немного. Maven позволяет избавиться от ручных проверок. А что не умеет, можно допилить, если в вашем проекте это очень важно. Как уже кто-то сказал, подавляющее большинство проектов не парятся по этому поводу. Так что такие советы вредны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Организация экосистемы для работы над Java проектом
M>Я это прекрасно понимаю, как и то, что цена за эту автоматизацию либо поддержка собственного репозитория (что оправданно только в случае очень больших компаний)
Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?
Re[7]: Организация экосистемы для работы над Java проектом
Здравствуйте, Baudolino, Вы писали:
B>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus?
А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.
Re[3]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
SK_>>> 2) Хранить зависимости в репозитории типа Nexus M>>Зависимости в VCS. Все равно управлять зависимостями нужно руками. .>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам.
Как уже было сказано, мержить бинарники нужно по версиям, а не по содержимому.
И после этого тщательно тестировать. Потому как все равно может поломаться.
Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: Организация экосистемы для работы над Java проектом
Здравствуйте, Miroff, Вы писали:
B>>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus? M>А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.
Да, но по велению мавена. Один раз скачаются и будут там всегда лежать. Автоматически и поэтому надёжнее и быстрее, в отличие от твоего варианта — ходить по куче сайтов с либами и качать всё вручную, подбирая подходящие версии и осторожно всё коммитя.
Если очень хочется, то можно и бэкапы для nexus настроить, если страшно, что публичные репозитории и локальные репозитории на всех машинах разработчиков могут вдруг сразу совсем умереть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
B>>>Вот это уже по-настоящему смешно. Вы действительно видите какие-то сложности в этом, чтобы поднять на том же сервере, где у вас VCS, ещё и Nexus? M>>А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны. .>Да, но по велению мавена. Один раз скачаются и будут там всегда лежать. Автоматически и поэтому надёжнее и быстрее, в отличие от твоего варианта — ходить по куче сайтов с либами и качать всё вручную, подбирая подходящие версии и осторожно всё коммитя.
Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам.
Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[4]: Организация экосистемы для работы над Java проектом
Здравствуйте, Aikin, Вы писали:
.>>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам. A>Как уже было сказано, мержить бинарники нужно по версиям, а не по содержимому.
Скажем, лежит у тебя в разных ветках файлик hornetq-core.jar. Начинаешь мерж — а он разный, вылез конфликт. И что дальше? Где какая версия? А от каких других либ оно зависит и какие у них версии?
А если в имя файла ставить номер версии, например, antlr-2.7.6.jar, то после мержей у тебя в одной ветке вдруг может оказаться две разных версии одной либы, а обнаружишь это только когда где-то ВНЕЗАПНО грохнется какой-нибудь LinkageError. Мавен же умеет разруливать это.
A>И после этого тщательно тестировать. Потому как все равно может поломаться.
Это да, тщательно тестировать всегда надо.
A>Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход.
Можно и отвёрткой забивать гвозди, но лучше пускай зависимостями управляет система управления зависимостями, а система управления исходниками управляет исходниками.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Организация экосистемы для работы над Java проектом
Здравствуйте, Aikin, Вы писали:
A>Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам. A>Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS.
Так это для .NET, аналог мавена. Мавена нет, вот и приходится по старинке в VCS — выбора-то нет. Или я не понял и это и для java-мира как-то можно использовать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Организация экосистемы для работы над Java проектом
A>Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам.
В Java-мире разумные люди не хранят бинарники в VCS. Серьёзно. Потому что для этого есть более подходящие инструменты. Если в .Net инструментарий не развит, очень жаль.
Re[8]: Организация экосистемы для работы над Java проектом
M>А пакеты в нем возьмутся, надо полагать, по щучьему велению? Ах, будут браться из внешних репозиториев. Ну так поздравляю, проблемы никуда не делись, но успешно спрятаны.
Специально для вас повторю другими словами: репозитории избавляют вас от большого объема ручной работы, связанной с организацией хранения зависимостей, потому что они именно для этого и создавались.
Сказки про "спрятанные проблемы" рассказывать нам тут не надо. Из внешнего репозитория в локальный библиотека будет загружена ровно один раз. При этом будет проверен хэш. Именно это вы проделываете вручную (если вообще проверяете хэш загрузки), перед тем как добавить вашу зависимость в VCS. И все вопросы, связанные с достоверностью и безопасностью источника, решаются так же, как и в случае ручной загрузки, поэтому приводить падение или взлом внешнего репозитория как аргумент в пользу VCS бессмысленно. Если X одинаково для А, и для B, то А не может быть лучше B по причине X.
Re[11]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
A>>Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам. A>>Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS. .>Так это для .NET, аналог мавена. Мавена нет, вот и приходится по старинке в VCS — выбора-то нет. Или я не понял и это и для java-мира как-то можно использовать?
Чёйт я не понял. Аналог мавена есть, а приходится по старинке. С какого перепугу?
Я говорю про то, что лично мне удобнее с помощью менеджера (nuGet) зависимости обновлять. Но хранить их удобнее в VCS (лично для меня).
.>>>Почему? Имхо, бинарники лучше не класть в VCS, мешает мержам. A>>Как уже было сказано, мержить бинарники нужно по версиям, а не по содержимому. .>Скажем, лежит у тебя в разных ветках файлик hornetq-core.jar. Начинаешь мерж — а он разный, вылез конфликт. И что дальше? Где какая версия? А от каких других либ оно зависит и какие у них версии?
Где какая версия можно посмотреть. Это не проблема.
Потом выбираешь подходящую версию и выполняешь: Update-Package NHibernate -Version XXXXXXX
Все нужные зависимости подтянулись.
Комитишь изменения в репозиторий.
Я не говорю что Мавен или nuGet встроенный в билд это плохо и я это никогда юзать не буду. Я говорю, что можно работать подругому в полуавтоматическом режиме. Вполне возможно, что я свое мнение поменяю. Но пока меня устраивает мой подход.
В любом случае человек управляет зависимостями, мавены всего лишь выполняют написанную тобой инструкцию (pom.xml). Будет это правка pom.xml или выполнение команды nuget не столь важно
.>А если в имя файла ставить номер версии, например, antlr-2.7.6.jar, то после мержей у тебя в одной ветке вдруг может оказаться две разных версии одной либы, а обнаружишь это только когда где-то ВНЕЗАПНО грохнется какой-нибудь LinkageError. Мавен же умеет разруливать это.
В .net c с этим проще. В проектном файле уже хранятся все зависимости проекта. Поэтому аналог pom.xml уже есть (файл где хранятся зависимости проекта). Разрулится в момент мержа, а если проспишь и не исправишь, то или упадет в момент билда, или будет работать но хз на какой версии (то же самое с pom.xml).
СУВ, Aikin
P.S. A>>Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход. .>Можно и отвёрткой забивать гвозди, но лучше пускай зависимостями управляет система управления зависимостями, а система управления исходниками управляет исходниками.
Ну мы же взрослые люди. Зачем эти "литературные приемы"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[5]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
A>>Единственная проблема с бинарниками в репозитории -- размер. Если он не критичен, то можно даже не парится, а использовать старый провереный подход. .>Можно и отвёрткой забивать гвозди, но лучше пускай зависимостями управляет система управления зависимостями, а система управления исходниками управляет исходниками.
Не заметил выделеного. Инструмент называется "Система управления версиями".
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[12]: Организация экосистемы для работы над Java проектом
Здравствуйте, Aikin, Вы писали:
A>>>Хранение бинарников в VCS вовсе не означает, что эти бинарники нужно собирать вручную по сайтам. A>>>Я "собираю" (collect, а не build) бинарники с помощью NuGet, а потом комичу в VCS. .>>Так это для .NET, аналог мавена. Мавена нет, вот и приходится по старинке в VCS — выбора-то нет. Или я не понял и это и для java-мира как-то можно использовать? A>Чёйт я не понял. Аналог мавена есть, а приходится по старинке. С какого перепугу?
Значит такой вот хреновый аналог, раз приходится по-старинке. Но я не знаю точно, т.к. nuGet никогда не видел, может и не обязательно по-старинке.
A>Я говорю про то, что лично мне удобнее с помощью менеджера (nuGet) зависимости обновлять. Но хранить их удобнее в VCS (лично для меня).
Может с nuGet так и правда удобнее, т.к. по другому нельзя. С maven удобнее не так, хотя так тоже можно, если очень хочется берёшь и коммитишь локальный mvn-repo, только нафиг не надо.
A>Где какая версия можно посмотреть. Это не проблема.
Где и как? Для pom.xml прямо во время резолва конфликта.
A>Потом выбираешь подходящую версию и выполняешь: Update-Package NHibernate -Version XXXXXXX A>Все нужные зависимости подтянулись.
Эти зависимости могут несогласовываться с другими.
A>Я не говорю что Мавен или nuGet встроенный в билд это плохо и я это никогда юзать не буду. Я говорю, что можно работать подругому в полуавтоматическом режиме. Вполне возможно, что я свое мнение поменяю. Но пока меня устраивает мой подход. A>В любом случае человек управляет зависимостями, мавены всего лишь выполняют написанную тобой инструкцию (pom.xml). Будет это правка pom.xml или выполнение команды nuget не столь важно
Есть принципиальная разница. pom.xml — часть исходников, есть история, есть мержи, всё аккуратно — эта циферка в версии была заменена на эту циферку, всё видно в диффах. А выполнение команд nuget забудется через день — невоспроизводимо.
.>>А если в имя файла ставить номер версии, например, antlr-2.7.6.jar, то после мержей у тебя в одной ветке вдруг может оказаться две разных версии одной либы, а обнаружишь это только когда где-то ВНЕЗАПНО грохнется какой-нибудь LinkageError. Мавен же умеет разруливать это. A>В .net c с этим проще. В проектном файле уже хранятся все зависимости проекта. Поэтому аналог pom.xml уже есть (файл где хранятся зависимости проекта). Разрулится в момент мержа, а если проспишь и не исправишь, то или упадет в момент билда, или будет работать но хз на какой версии (то же самое с pom.xml).
Непонятно кто и как управляет зависимостями?
Скажем у тебя в приложении используется NHibernate-2.3 и BLToolkit-3.4. NHibernate тянет за собой log4net-1.10, а BLToolkit тянет log4net-1.20. Какая либа будет в итоге использоваться? maven выберет последнюю и в отчёте ещё можно посмотреть список таких конфликтов. Ещё можно плагинчик воткнуть для контроля непротиворечивости зависимостей в момент сборки, можно посмотреть зависимости в виде симпатичного графа.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали:
A>>Потом выбираешь подходящую версию и выполняешь: Update-Package NHibernate -Version XXXXXXX A>>Все нужные зависимости подтянулись. .>Эти зависимости могут несогласовываться с другими.
За этим следит nuGet
A>>Я не говорю что Мавен или nuGet встроенный в билд это плохо и я это никогда юзать не буду. Я говорю, что можно работать подругому в полуавтоматическом режиме. Вполне возможно, что я свое мнение поменяю. Но пока меня устраивает мой подход. A>>В любом случае человек управляет зависимостями, мавены всего лишь выполняют написанную тобой инструкцию (pom.xml). Будет это правка pom.xml или выполнение команды nuget не столь важно .>Есть принципиальная разница. pom.xml — часть исходников, есть история, есть мержи, всё аккуратно — эта циферка в версии была заменена на эту циферку, всё видно в диффах.
MyApplication.csproj тоже часть исходников.
.>А выполнение команд nuget забудется через день — невоспроизводимо.
Есть автокомплит и встроеная справка. А самое главное то, что эти команды не часто выполняются -- можно и погуглить.
.>Скажем у тебя в приложении используется NHibernate-2.3 и BLToolkit-3.4. NHibernate тянет за собой log4net-1.10, а BLToolkit тянет log4net-1.20. Какая либа будет в итоге использоваться? maven выберет последнюю и в отчёте ещё можно посмотреть список таких конфликтов.
За этим следит nuGet
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: Организация экосистемы для работы над Java проектом
Здравствуйте, Aikin, Вы писали:
A>>>Я не говорю что Мавен или nuGet встроенный в билд это плохо и я это никогда юзать не буду. Я говорю, что можно работать подругому в полуавтоматическом режиме. Вполне возможно, что я свое мнение поменяю. Но пока меня устраивает мой подход. A>>>В любом случае человек управляет зависимостями, мавены всего лишь выполняют написанную тобой инструкцию (pom.xml). Будет это правка pom.xml или выполнение команды nuget не столь важно .>>Есть принципиальная разница. pom.xml — часть исходников, есть история, есть мержи, всё аккуратно — эта циферка в версии была заменена на эту циферку, всё видно в диффах. A>MyApplication.csproj тоже часть исходников.
Как я понял, MyApplication.csproj это не часть исходников, которые ты пишешь, а файлик, слава богу хотя бы текстовый, в котором MSVS и его плагины сохраняют свои настройки, нащёлканные мышой или хитрыми командами из командной строки. Т.е. тупо из тулзы мержа его не смержить при конфликте, как я понял. Если возник конфликт в этом файле — как и где он нарисуется и чем его резолвить? Как отреагирует на это MSVS?
А что делать с при конфликте закоммиченных бинариков?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[15]: Организация экосистемы для работы над Java проектом
Здравствуйте, ., Вы писали: A>>MyApplication.csproj тоже часть исходников. .>Как я понял, MyApplication.csproj это не часть исходников, которые ты пишешь, а файлик, слава богу хотя бы текстовый, в котором MSVS и его плагины сохраняют свои настройки, нащёлканные мышой или хитрыми командами из командной строки. Т.е. тупо из тулзы мержа его не смержить при конфликте, как я понял. Если возник конфликт в этом файле — как и где он нарисуется и чем его резолвить? Как отреагирует на это MSVS?
Это именно часть исходников. Да, он генерится студией. Но это не настройки студии и ее плагинов (они хранятся в другом месте). Это XML и там никокой магии. Это build-скрипт для сборки проекта с помощью msbuild.
Студия хорошо реагирует на ручной допил файла проекта.
