не зависящее от SVN управление зависимостями - PullRequest
3 голосов
/ 04 августа 2011

Гипотетически было две компании по разработке программного обеспечения, A & B. Обе компании имеют около пары сотен проектов Eclipse. Оба имеют несколько конечных продуктов. Каждый проект конечного продукта имеет зависимость, отличную от других.

A использует maven для управления зависимостями. Он практикует замораживание кода и поэтому разъединяет проекты друг от друга и, следовательно, способен создавать зависимости.

B использует плагин Eclipse Subversive. Для любого конкретного проекта конечного продукта все проекты, от которых он зависит, будут извлечены из SVN и включены в путь сборки проекта Eclipse. Если у проекта есть зависимости от 50 проектов, все 50 проектов будут подвергаться модификации исходного кода, и поэтому они не используют Maven.

Две компании объединились в AB. Желание иметь управление зависимостями типа maven, которое также будет работать с SVN-репозиториями. То есть гипотетическое POM должно быть в состоянии указать либо зависимость jar (стиль компании A), либо зависимость исходного кода SVN (стиль компании B). Если зависимость представляет собой jar, она должна вытянуть зависимость из репозитория в maven-кеш рабочей станции разработчика. Если зависимость является исходным кодом в SVN, он должен проверить его в рабочем каталоге SVN.

Как компании AB следует придерживаться своего видения, объединяющего два подхода к построению технологически? Я указываю «технологически», чтобы избежать ответов, которые касаются микроуправления или изменения философских установок разработчиков объединенной компании.

Может ли Грэдл помочь? Если да, то как и почему? Какие еще альтернативы?

Ответы [ 2 ]

3 голосов
/ 16 апреля 2012

Предположительно, проекты, созданные компанией B, создают упакованные (jar) продукты как часть их доставки / сборки.Если это так, то компания AB может создать свой собственный репозиторий артефактов (моя компания использует Artifactory), и проекты из компании B могут быть вручную (или автоматически) добавлены в этот репозиторий как версии с версиями или как снимки.Тогда проекты компании A могли бы указывать свои зависимости в виде jar-зависимостей и извлекать из артефакта.

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

Ни одно из моих предложений выше не требует использования Gradle, но Gradle делает большую часть этого простым в реализации.

2 голосов
/ 04 августа 2011

svn: внешние решения - это техническое решение.Затем расскажите разработчикам, злоупотребляющим svn, что зависимости Maven менее опасны.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...