Что должна делать структура управления зависимостями? - PullRequest
3 голосов
/ 20 апреля 2011

Я начал писать бесплатную платформу для управления зависимостями с открытым исходным кодом для .NET / C ++. Задавая здесь вопрос, я стараюсь не создавать еще один, который никому не нужен. Это мое отчаянное вечернее хобби началось после того, как я безнадежно пытался принять тонны существующих, которые не могли удовлетворить мои скромные потребности в работе и хобби:

  • простой интерфейс командной строки, который просто работает, не требуя запутанных специфичных для ms развертываний и плагинов пользовательского интерфейса; чтобы можно было легко использовать его в скрипте сборки CI или в составе интерфейса NAnt или MSBuild
  • простые репозитории пакетов на основе каталогов, если вы не хотите настраивать сервер репозиториев
  • локальное кэширование пакетов
  • поддержка нескольких хранилищ и цепочек хранилищ
  • простая компиляция пакета из командной строки и публикация в определенном хранилище
  • очень простой файл конфигурации пакета
  • эффективное разрешение дерева зависимостей (т.е. зависимости зависимостей и более глубокие); обнаружение конфликтов; автоматическое обновление версий зависимостей;

Идея проста, если решение имеет следующую структуру, которая довольно стандартна для репозиториев на основе SVN:

/ (trunk?)
/include (3rdparty c++ header files)
/tools (some tools required to build your product, for example protobuf generator)
/other (random stuff which doesn't fit anywhere, like resources)
/lib (managed 3rdparty library binaries)
/src (the solution's source files)

В корне также есть файл конфигурации .xml, описывающий ваше решение и содержащий:

  • глобально уникальный идентификатор пакета
  • метаданные (версия, поставщик, заметки о выпуске и т. Д.)
  • зависимости пакета (log4?, Hibernate, boost и т. Д.), Включая шаблон версии, платформу и т. Д.
  • файлов из папки / src для создания пакета из вашего решения (если есть)

Консольный инструмент позволяет искать в хранилище пакеты, разрешать зависимости (они будут помещены в папки / include, / lib и / tools), компилировать ваш пакет и публиковать его в хранилище. Содержимое папки / lib, / include, / tools не нужно фиксировать в subversion, только config xml в корневой папке.

Инструмент поддерживает несколько репозиториев, которые настроены в xml-файле, расположенном в домашней папке пользователя (если не переопределен), где он может настраивать их приоритеты, местоположения, параметры публикации.

Написан для .NET 4, но может легко изменить рефакторинг для Mono.

Я не буду вставлять сюда URL, чтобы быть заблокированным для рекламы.

1 Ответ

1 голос
/ 27 апреля 2011

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

...