Вопросы Теги

Что лучший способ состоит в том, чтобы заставить TFS производить каждый проект к своему собственному каталогу?

Эти статьи дают хорошее объяснение:

Первая ссылка отмечает, что

«Есть варианты использования где вам может понадобиться получить объект Request внутри Sling Model или вы хотите адаптировать вашу Sling Model с помощью объекта SlingHttpServletRequest (где вы не хотите создавать объект ресурса). "

blockquote>

Во второй ссылке упоминается

«Многие проекты Sling хотят иметь возможность создавать объекты модели - POJO, которые автоматически сопоставляются с объектами Sling, обычно ресурсами, но также запрашивают объекты. Иногда этим POJO нужны службы OSGi, как хорошо. "

blockquote>

То есть, используете ли вы один адаптируемый или другой (или оба сразу), зависит от того, что вам нужно в вашей модели. В этом примере он создает модель, которая должна считывать некоторые значения из ресурса, а другие - из запроса, поэтому адаптируемость, которую вы будете использовать, зависит от того, какие значения вам нужны в вашей модели. Вот пример класса в этой первой ссылке, который показывает «сообщение», которому нужны данные из ресурса (имя и фамилия) и данные из запроса (путь): 

package com.aem.core.models;

import javax.annotation.PostConstruct;
import javax.inject.Inject;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.resource.Resource;
import org.apache.sling.models.annotations.Model;
import org.apache.sling.models.annotations.Via;
import org.apache.sling.models.annotations.injectorspecific.SlingObject;
import org.apache.sling.models.annotations.DefaultInjectionStrategy;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Model(adaptables = {SlingHttpServletRequest.class, Resource.class}, defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class AdaptationModel { 

    Logger logger = LoggerFactory.getLogger(this.getClass());

    private String message;

    @SlingObject
    private SlingHttpServletRequest request;

    @Inject @Via("resource")
    private String firstName;

    @Inject  @Via("resource")
    private String lastName;

    @PostConstruct
    protected void init() {

        message = "Hello World\n";

        if (request != null) {
            this.message += "Request Path: "+request.getRequestPathInfo().getResourcePath()+"\n";
        }

        message += "First Name: "+ firstName +" \n";
        message += "Last Name: "+ lastName + "\n";

        logger.info("inside post construct");
    }

    public String getMessage() {
        return message;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return lastName;
    }
}

58
задан Tom Kidd 30 March 2009 в 20:15
поделиться

7 ответов

Я только что опубликовал здесь другой метод:

http://mikehadlow.blogspot.com/2009/06/tfs-build-publishedwebsites-for-exe-and.html но если вас не беспокоит переход по ссылке, то вот ее полный текст:

Обычно рекомендуется собирать весь код, находящийся под контролем вашей команды, в одном универсальном решении, как описано в этом PDF-документе «Шаблоны и практики», Командная разработка с помощью TFS Guide. Если вы затем сконфигурируете сервер сборки TFS для сборки этого решения, по умолчанию он будет помещать выходные данные сборки в одну папку «Release».

Все проекты веб-приложений в вашем решении также будут выводиться в папку с именем _PublishedWebsites. \. Это очень хорошо, потому что это означает, что вы можете просто развернуть веб-приложение с помощью robocopy.

К сожалению, нет аналогичного поведения по умолчанию для других типов проектов, таких как WinForms, консоль или библиотека. Было бы очень хорошо, если бы у нас была подпапка _PublishedApplications \ с выходными данными любого выбранного проекта (ов). К счастью, это не так уж и сложно.

Принцип работы _PublishedWebsites довольно прост. Если вы посмотрите на файл проекта своего веб-приложения, вы заметите импорт внизу: 

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

На моей машине свойство MSBuildExtensionsPath оценивается как C: \ Program Files \ MSBuild, если мы откроем файл Microsoft.WebApplication.targets мы можем видеть, что это довольно простой файл MSBuild, который распознает, когда сборка не является сборкой рабочего стола, то есть это сборка TFS, и копирует вывод в: 

$(OutDir)_PublishedWebsites\$(MSBuildProjectName)

Я просто скопировал файл Micrsoft.WebApplication.targets, поместил его в исходный элемент управления с относительным путем из файлов моего проекта и изменил _PublishedWebsites на _PublishedApplications и переименовал файл CI.exe.targets. Для каждого проекта, который я хочу вывести в _PublishedApplications, я просто добавил этот импорт в конец файла проекта: 

<Import Project="<your relative path>\CI.exe.targets" />

Вы можете редактировать CI.exe.targets (или как хотите его называть), чтобы выполнять свои ставки. В моем случае единственным изменением на данный момент является добавление пары строк для копирования файла App.config: 

<Copy SourceFiles="$(OutDir)$(TargetFileName).config" DestinationFolder="$(WebProjectOutputDir)\bin" SkipUnchangedFiles="true" />

В Microsoft.WebApplication.targets много всего, что относится только к веб-приложениям и может быть удалено для другие типы проектов, но я оставлю это в качестве упражнения для читателя.

44
ответ дан 24 November 2019 в 18:56
поделиться

У Вас мог быть один buildscript на проект, который сделает точно, что Вы хотите. Просто создайте новый файл TFSBuild, добавьте проекты, которые Вы хотите разработать к itemgroup (в порядке, Вы хотите их созданный), установите, где Вы хотите, чтобы вывод был. Это сделано путем переопределения - свойство в файле TFSBuild.

Но я также соглашаюсь с предыдущим плакатом - почему Вы только не работаете с единственным сценарием сборки и добавляете задачу zip в конце? Поддержание buildscript на проект действительно добавляет обслуживание наверху...

0
ответ дан Erling Paulsen 24 November 2019 в 18:56
поделиться

Вы достигаете этого путем переопределения целевой реализации CoreDropBuild по умолчанию.

В Вашем файле TFSBuild.proj (по умолчанию сохраненный под TeamBuildTypes / <Тип Сборки>) добавляют следующую цель:

    <!-- Override default implementation -->
    <Target 
       Name="CoreDropBuild"
       Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
       DependsOnTargets="$(CoreDropBuildDependsOn)">
...
    </Target>

В этой цели можно управлять выводом, поскольку Вы хотите это. Значение по умолчанию должно просто скопировать все с $ (BinariesRoot) \$ (BuildType) к $ (DropLocation) \$ (BuildNumber).

Я обычно использую Microsoft. Sdc. Проект задач для возможностей копирования файла.

-2
ответ дан John Saunders 24 November 2019 в 18:56
поделиться

Простое решение:

Замените все узлы <SolutionToBuild> <SolutionToPublish>. Это будет, конечно, только работать на пригодные для печати проекты (например, веб-проекты и приложения), не для проектов библиотеки.

Настолько простой :)

-3
ответ дан Erik A. Brandstadmoen 24 November 2019 в 18:56
поделиться

​​Для каждого узла SolutionToBuild установите для свойства OutDir значение $ (OutDir) \ SubFolder
Например: 

  <ItemGroup>
   <SolutionToBuild Include="Project1.sln" >
    <Properties>OutDir=$(OutDir)\Project1\</Properties>      
   </SolutionToBuild>
   <SolutionToBuild Include="Project2.sln" >
    <Properties>OutDir=$(OutDir)\Project2\</Properties>      
   </SolutionToBuild>
   <SolutionToBuild Include="Project3.sln" >
    <Properties>OutDir=$(OutDir)\Project3\</Properties>      
   </SolutionToBuild>
  <ItemGroup>

(работает в TF2008, но не в TF2005.)

6
ответ дан 24 November 2019 в 18:56
поделиться

По умолчанию каждый файл проекта (* .csproj, * .vbproj и т. Д.) Указывает выходной каталог по умолчанию (обычно это bin \ Debug, bin \ Release и т. Д.). Team Build фактически переопределяет это, чтобы вы не зависели от того, какие свойства устанавливает разработчик в файле проекта, но также чтобы Team Build могла делать предположения о том, где расположены выходные данные.

Самый простой способ изменить это поведение состоит в том, чтобы установить CustomizableOutDir в значение true в группе элементов SolutionToBuild, как показано здесь: 

<ItemGroup>
  <SolutionToBuild Include="$(BuildProjectFolderPath)\path\MySolution.sln" />
    <Properties>CustomizableOutDir=true</Properties>
  </SolutionToBuild>
</ItemGroup>

Это приведет к тому, что структура перетаскиваемой папки будет примерно соответствовать той, которую вы получили бы локально, если бы вы построили решение.

Этот метод определенно предпочтительнее, чем переопределение ядра * цели, которые могут вызвать проблемы с обновлением.

10
ответ дан 24 November 2019 в 18:56
поделиться

Поместите это в группу свойств: 

<CustomizableOutDir>true</CustomizableOutDir>

Это переопределит глобальное свойство CustomizableOutDir, которое по умолчанию имеет значение False. Установка этого параметра в свойствах SolutionToBuild не работает.

0
ответ дан 24 November 2019 в 18:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: