Вы можете использовать Apache / IVY в автономном режиме.
http://ant.apache.org/ivy/history/latest-milestone/standalone.html
Мне нужно подчеркнуть режим «в одиночестве». Если вы поищете в Google примеры .... вы найдете множество (не автономных).
В принципе, IVY работает в этой предпосылке.
Вы публикуете двоичные файлы (или любой другой файл, но я скажу двоичные файлы с этого момента) ..... как маленькие бинарные пакеты.
Ниже приведен код PSEUDO, не полагайтесь на мою память.
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.4 (<< где .xml относится к N числу файлов, составляющих один пакет.)) </p>
«Пакет» означает группу файлов. Вы можете включить в пакет файлы .dll и .xml и .pdb (что я делаю со сборкой сборок DotNet). Или что угодно. IVY не зависит от типа файла. Если вы хотите разместить WordDocs там, вы могли бы, но sharepoint лучше для документов.
Когда вы исправляете ошибки в своем коде, вы увеличиваете ревизию.
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.5
потом вы можете получить из IVY то, что хотите.
java.exe ivy.jar -retrieve PackagesINeed.xml
PackagesINeed.xml будет содержать информацию о пакетах, которые вы хотите.
что-то вроде
«Я хочу версию MyBinaryPackageOne версии 1.2+»
(определено в xml)
По мере того, как вы строите свои бинарные файлы фреймворка ... вы ПУБЛИКАЕТЕ IVY
Затем, когда вы разрабатываете и создаете свой код ... вы ПОЛУЧАЕТЕ из IVY.
В NUTSHELL IVY - это хранилище для ФАЙЛОВ (не исходный код).
Плющ становится окончательным источником ваших двоичных файлов.
Ни один из типов "Эй, у разработчика-Джо нет необходимых нам двоичных файлов".
.......
Преимущества:
1. Вы НЕ держите свои двоичные файлы в системе контроля версий. (и, таким образом, не взрывайте свой источник контроля).
2. У вас есть ОДИН окончательный источник для двоичных файлов.
3. Через конфигурацию XML вы говорите, какие версии вам нужны для библиотеки.
(В приведенном выше примере, если версия 2 (2.0.0.0) MyBinaryPackageOne опубликована в IVY (допустим, с изменениями версии 1.2.xy) ... тогда вы в порядке, потому что вы определили в своем извлечении (файл конфигурации xml) ..., что вам нужно только "1.2+". Таким образом, ваш проект будет игнорировать что-либо 2 + ..., если вы не измените пакет конфигурации.
Дополнительно:
Если у вас есть машина для сборки (например, CruiseControl.NET) .... вы можете написать логику для публикации ваших (новых) двоичных файлов в IVY после каждой сборки.
(Что я и делаю).
Я использую ревизию SVN в качестве последнего номера в номере сборки.
Если бы моя SVN-ревизия была «3333», я бы запустил что-то вроде этого:
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.3333
Таким образом, при каждом извлечении пакета для ревизии "1.2.3+" .... я получу последнюю сборку.
В этом случае я бы получил версию пакета 1.2.3.3333.
Печально, что IVY был запущен в 2005 году (ну, это хорошая новость) ... но что NUGET не вышел до 2010 года? (2011?)
ИМХО отстала от Microsoft на 5-6 лет.
Я бы никогда не вернулся к переводу двоичных файлов в систему контроля версий.
IVY очень хорошо. Это время доказано. Решает проблему управления ЗАВИСИМОСТЬЮ.
Требуется ли немного времени, чтобы освоиться с этим?
Да.
Но это того стоит.
Мои 2 цента.
.................
Но идея № 2
Узнайте, как использовать NUGET с локальным (например, локальным для вашей компании) репозиторием.
Это примерно то же самое, что и IVY.
Но, посмотрев на NUGET, я все еще люблю IVY.