2015-04-18 2 views
0

Я успешно создал веб-приложение Java, используя поддержку Java с помощью ant. Моя проблема заключается в том, что у меня есть несколько приложений, которые используют общий процесс сборки и хотели бы повторно использовать build.xml (с параметрами, переданными для дифференциации вывода), однако определение сборки TFS не позволяет мне ссылаться на файл build.xml файл, который находится в общем местоположении вне отображения рабочей области для моей конкретной сборки.Reuse Ant build.xml для TFS 2013 BuildDefinitions

Например, предположим следующую структуру управления Версия:

Источник
    Приложения
            Применение 1
                Главная
                    SRC
                    WebContent
            Применение 2
                Главная
                    ЦСИ
                    WebContent

Для каждого определения построения я хотел корень как основного раздела этого приложения, так что только исходные файлы копируются на сервер сборки. Я хотел бы, чтобы файл build.xml хранился, скажем, в каталоге приложений, поскольку он будет совместно использоваться в приложении 1 и приложении 2. Когда я попробую это, я получаю следующую ошибку:

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ BuildExtensions \ Microsoft.TeamFoundation.Build.Extensions.Ant.targets (306): Нет отображения рабочей папки для $/Source/Applications/build.xml

Это потому что моя папка управления версиями в определении сборки установлена ​​в дочернюю папку (Main). Если я установил папку «Исходный контроль» в папку «Приложения», я считаю, что она сработает, однако я заметил, что сборка пытается передать ВСЕ файлы в разделе «Приложения» на сервер сборки, что замедляет создание до обхода. Любые мысли о том, как я могу добиться желаемого повторного использования? Возможно, что-то в файле TFSBuild.proj, которое ограничивало бы файлы, которые передаются с использованием параметра $ {ApplicationName}/Main или что-то в этом роде?

Заранее благодарим за любую помощь.

ответ

0

Вы можете настроить рабочее пространство для включения папок и скрытия других. Я могу себе представить, что это вызовет работу, чтобы скрыть все остальное в сфере охвата. Рекомендуемая практика заключалась бы в том, чтобы общая папка находилась под собственной папкой, а не корнем приложений. Таким образом вы можете явно отобразить эту папку, а также ветку, которую вы хотите построить.

Когда сборка XAML ушла в отставку при запуске TFS 2015, новая система сборки позволяет вам выполнять задачи, которые совместно используются определениями построения.

+0

Только что обнаружил, что вы могли бы отобразить дополнительные папки, и это сработает, если я переведу файл build.xml в другом месте. Отличное решение. –

Смежные вопросы