У меня есть небольшой код для dll, который нужен двум или более проектам в eclipse. В настоящее время каждый проект имеет копию кода и отдельно строит DLL. Я хочу выделить dll-код в отдельный проект eclipse, чтобы было общее расположение. Но я хочу избежать ситуации, когда нам нужно создать dll в одном проекте, затем скопировать dll обратно в другие проекты и проверить dll для каждого соответствующего проекта. Это приведет к созданию библиотеки DLL для каждого проекта, которая не отслеживается по точному коду, с помощью которого он был построен.
Есть ли способ каким-то образом символически связать библиотеки DLL с другим проектом eclipse, который использует CVS в качестве системы управления версиями, чтобы можно было определить, какая версия кода использовалась для создания библиотеки DLL? Я делаю это слишком сложным или упускаю что-то очевидное?
Я думал о рабочих наборах в диспетчере пакетов для eclipse, но мне нужно больше узнать о том, как использовать их с CVS, чтобы не превратить его в кошмар для следующего человека, который его проверяет и не может понять, почему их проект выиграл t компилировать.
Спасибо.
Если вы работаете с одной рабочей областью, вы получаете три проекта, каждый из которых отражен в CVS: один - это dll, другие - это проекты, использующие dll (настроенные как зависимость этих проектов от проекта dll).
С тремя проектами я бы не нацелился на рабочие наборы - они хороши для управления множеством проектов в одной рабочей области, для трех проектов я считаю их излишними. Обычно я стремлюсь к нескольким рабочим местам вместо рабочих наборов.
Что касается следующего человека, работающего с этими проектами: вам необходимо иметь какую-то документацию о том, как настроить ваши проекты. Вы можете сказать, что ваши файлы проекта eclipse делают именно это (поскольку они определяют зависимость проекта от другого проекта), но это для машины - людям, как правило, нравятся другие средства связи.
Если вас беспокоит, что изменения в dll несовместимы с одним проектом (поскольку человек, применяющий эти изменения, не заботится о другом проекте), стремитесь к сервер сборки. При этом будут построены все проекты и зависимые проекты всякий раз, когда что-то в системе управления версиями изменится, будут запущены все тесты, предоставлен номер сборки и все это будет упаковано для использования. Таким образом вы можете быть уверены, что - все, что находится в вашем продукте, - можно воспроизвести, потому что сервер сборки не может вносить локальные (незафиксированные) изменения в код. Также сервер сборки будет сигнализировать об ошибке (либо сломанный API, либо неработающие тесты) в момент последней фиксации (ну, несколько минут спустя) и возложит бремя восстановления повреждений на того, кто нанес ущерб.
А как насчет создания новой папки в отдельном проекте. В расширенном разделе создания новой папки есть возможность установить ссылку на другое место в файловой системе.
Или вы также можете создать проект контейнера, который использует файл projectset.psf. Сделайте ссылку на файл набора проектов на различные проекты в вашем репозитории. Если вы хотите проверить этот проект, вместо этого извлеките контейнер и щелкните правой кнопкой мыши файл набора проектов и выберите Импортировать набор проектов ...