Sie sehen sich Hilfeinhalte der folgenden Version an:

Überblick

In diesem Dokument wird beschrieben, wie Sie ein AEM-Projekt einrichten, das auf Apache Maven basiert. 

Apache Maven ist ein Open-Source-Werkzeug für die Verwaltung von Software-Projekten, das Builds automatisiert und hochwertige Projektinformationen bereitstellt. Wir empfehlen es zur Build-Verwaltung für AEM-Projekte.

Wenn Sie Ihr AEM-Projekt mit Maven erstellen, haben Sie mehrere Vorteile:

  • Eine IDE-agnostische Entwicklungsumgebung
  • Verwendung von Maven-Archetypen und Artefakten, die von Adobe bereitgestellt werden
  • Verwendung der Werkzeugsets Apache Sling und Apache Felix für Maven-basierte Entwicklungsumgebungen
  • Einfacher Import in ein IDE, z. B. Eclipse und/oder IntelliJ
  • Einfache Integration mit kontinuierlichen Integrationssystemen

API-Abhängigkeiten von Experience Manager

Was ist das UberJar?

„UberJar“ ist der informelle Name für eine bestimmte Java Archive (JAR)-Datei die von Adobe bereitgestellt wird. Diese JAR-Datei enthält alle öffentlichen Java-APIs, die von Adobe Experience Manager bereitgestellt werden. Sie enthält außerdem einige externe Bibliotheken, und zwar alle öffentlichen APIs, die in AEM verfügbar sind und aus Apache Sling, Apache Jackrabbit, Apache Lucene oder Google-Guave stammen, sowie zwei Bibliotheken, die für die Bildverarbeitung verwendet werden (Werner Randelshofers CYMK-JPEG-ImageIO-Bibliothek und die TwelveMonkeys-Bildbibliothek). Das UberJar enthält nur API-Schnittstellen und -Klassen, was bedeutet, dass es nur Schnittstellen und Klassen enthält, die über ein OSGi-Paket in AEM bereitgestellt werden. Es enthält außerdem eine MANIFEST.MF-Datei mit der richtigen Paketexportversion für diese exportierten Pakete. Dadurch wird sichergestellt, dass Projekte, die mit dem UberJar entwickelt werden, die richtigen Paketimportbereiche haben.

Warum hat Adobe das UberJar erstellt?

Früher mussten Entwickler recht viele einzelne Abhängigkeiten von verschiedenen AEM-Bibliotheken verwalten. Jedes Mal, wenn sie eine neue API verwendeten, mussten sie eine oder mehrere einzelne Abhängigkeiten zum Projekt hinzufügen. Bei einem Projekt führte die Einführung des UberJar dazu, dass 30 verschiedene Abhängigkeiten aus dem Projekt entfernt werden konnten.

Wie verwende ich das UberJar?

Wenn Sie Apache Maven als Build-System verwenden (dies ist der Fall bei den meisten AEM-Java-Projekte), müssen Sie nur ein oder zwei Elemente zu Ihrer pom.xml-Datei hinzufügen. Das erste Element ist ein Abhängigkeits-Element, das Ihrem Projekt die eigentliche Abhängigkeit hinzufügt:

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.3.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Wenn Ihr Unternehmen bereits einen Maven Repository Manager wie Sonatype Nexus, Apache Archiva oder JFrog Artifactory verwendet, fügen Sie die entsprechende Konfiguration zum Projekt hinzu, um auf diesen Repository-Manager zu verweisen, und fügen Sie das Maven-Repository von Adobe (https://repo.adobe.com/nexus/content/groups/public/) zu Ihrem Repository-Manager hinzu. 

Hinweis:

Sie finden die nicht verschleierten jar-Dateien unter folgenden Adressen:

Wenn Sie keinen Repository-Manager verwenden, müssen Sie ein Repository-Element zu Ihrer pom.xml-Datei hinzufügen:

<repositories>
    <repository>
        <id>adobe-public-releases</id>
        <name>Adobe Public Repository</name>
        <url>https://repo.adobe.com/nexus/content/groups/public/</url>
        <layout>default</layout>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>adobe-public-releases</id>
        <name>Adobe Public Repository</name>
        <url>https://repo.adobe.com/nexus/content/groups/public/</url>
        <layout>default</layout>
    </pluginRepository>
</pluginRepositories>

CODE AUF GITHUB

Den Code dieser Seite finden Sie auf GitHub

Hinweis:

Sie können diese Repositorys auch in Ihrer Maven-Datei settings.xml konfigurieren.

Nutzer anderer Build-Systeme (z. B. Apache Ant, Gradle) sollten ähnliche Schritte befolgen und die Syntax an ihr jeweiliges System anpassen.

Was ist mit dem UberJar möglich?

Mit dem UberJar können Sie Projektcode kompilieren, der von AEM-APIs (und den APIs der oben erwähnten Projekte) abhängt. Sie können auch Informationen zu OSGi Service Component Runtime (SCR) and OSGi Metatype generieren. Mit einigen Einschränkungen können Sie auch Unit-Tests schreiben und ausführen.

Was ist mit dem UberJar nicht möglich?

Da das UberJar nur APIs enthält, ist es nicht ausführbar und kann nicht verwendet werden, um Adobe Experience Manager auszuführen. Um AEM auszuführen, benötigen Sie AEM Quickstart – entweder eigenständig oder als Web Application Archive (WAR).

Sie haben Einschränkungen zu Unit-Tests erwähnt. Erläutern Sie das bitte genauer.

Unit-Tests interagieren im Allgemeinen mit Produkt-APIs auf drei verschiedene Arten, die jeweils etwas unterschiedlich vom UberJar beeinflusst werden.

Anwendungsfall 1: benutzerdefinierter Code, der eine API-Schnittstelle aufruft

In diesem Fall, der am häufigsten auftritt, führt benutzerdefinierter Code Methoden auf einer Java-Schnittstelle aus, die von der AEM-API definiert wird. Die Implementierung dieser Schnittstelle kann entweder direkt bereitgestellt oder mithilfe des Abhängigkeitsinjektionsmusters eingeführt werden. Dieser Anwendungsfall kann mit dem UberJar durchgeführt werden.

Ein Beispiel für den ersteren Fall:

public class ClassWhichHasAEMInterfacePassedIn {
    /**
     * Get the first length characters of the page title.
     */
    public String getTrimmedTitle(Page page, int length) {
         String title = page.getTitle();
         return StringUtils.left(title, length);
    }
}

Ein Beispiel für den letzteren Fall:

@Component
@Service
public class ComponentWhichHasAEMInterfaceInjected implements TitleTrimmer {
    @Reference
    private PageManagerFactory pageManagerFactory;
  
    /**
     * Get the first length characters of the title of the page containing the provided Resource.
     */
    public String getTrimmedTitle(Resource resource, int length) {
        PageManager pageManager = pageManagerFactory.getPageManager(resource.getResourceResolver());
        Page page = pageManager.getContainingPage(resource);
        if (page == null) {
           return null;
        }
        String title = page.getTitle();
        return StringUtils.left(title, length);
    }
}

Für den Unit-Test einer dieser Methoden würden Entwickler ein Mocking-Framework wie JMockitMockitoJMock oder Easymock verwenden, um ein Modellobjekt für die referenzierte AEM-API zu erstellen. Diese Beispiele verwenden JMockit, aber für diesen Verwendungsfall liegt der Unterschied zwischen diesen Frameworks hauptsächlich in der Syntax.

@RunWith(JMockit.class)
public class ClassWhichHasAEMInterfacePassedInTest {
 
    @Tested
    private ClassWhichHasAEMInterfacePassedIn instance;
 
 
    @Mocked
    private Page page;
 
 
    @Test
    public void test_that_long_string_is_trimmed() {
        new Expectations() {{
            page.getTitle();
            result = "a really really really really really long string";
        }};
        assertEquals("a really", instance.getTrimmedTitle(page, 8));
    }
}
@RunWith(JMockit.class)
public class ComponentWhichHasAEMInterfaceInjectedTest {
 
 
    @Tested
    private ComponentWhichHasAEMInterfaceInjected instance;
 
 
    @Mocked
    private Page page;
 
 
    @Mocked
    private PageManager pageManager;
 
 
    @Injectable
    private PageManagerFactory pageManagerFactory;
 
 
    @Mocked
    private Resource resource;
 
 
    @Mocked
    private ResourceResolver resourceResolver;
 
    @Test
    public void test_that_long_string_is_trimmed() {
        new Expectations() {{
            resource.getResourceResolver();
            result = resourceResolver;
            pageManagerFactory.getPageManager(resourceResolver);
            result = pageManager;
            pageManager.getContainingPage(resource);
            result = page;
            page.getTitle();
            result = "a really really really really really long string";
        }};
        assertEquals("a really", instance.getTrimmedTitle(resource, 8));
    }
}

Anwendungsfall 2: benutzerdefinierter Code der eine API-Implementierungsklasse aufruft

Bei diesem Anwendungsfall wird ein Aufruf an eine statische oder Instanzmethode einer Klasse in der AEM-API getätigt. Dabei referenzieren Sie anders als in Anwendungsfall 1 eine konkrete Klasse. 

public class ClassWhichUsesAStaticMethodFromAPI {
     
    /**
     * Get a map of asset titles to asset objects.
     *
     * @param resource either an asset resource or a folder containing assets.
     * @return an map of titles to assets. if an asset doesn't have a title, the name is used instead.
     */
    public Map<String, Asset> getAssetTitles(Resource resource) {
        Iterator<Asset> assets = DamUtil.getAssets(resource);
        Map<String, Asset> result = new HashMap<String, Asset>();
        while (assets.hasNext()) {
            Asset asset = assets.next();
            String title = asset.getMetadataValue(DamConstants.DC_TITLE);
            if (title == null) {
                title = asset.getName();
            }
            result.put(title, asset);
        }
        return result;
    }
}
public class ClassWhichUsesAnInstanceMethodFromAPI {
     
    /**
     * Count the number of paragraphs in a parsys.
     *
     * @param resource the parsys resource
     * @return the count
     */
    public int countParagraphs(Resource resource) {
        return new ParagraphSystem(resource).paragraphs().size();
    }
}

 Dieser Anwendungsfall kann mit dem UberJar durchgeführt werden. Allerdings wird ein API-Modell nach Möglichkeit dennoch empfohlen, um die Testleistung zu verbessern.

@RunWith(JMockit.class)
public class ClassWhichUsesAStaticMethodFromAPITest {
 
 
    @Tested
    private ClassWhichUsesAStaticMethodFromAPI instance;
 
 
    @Mocked(stubOutClassInitialization = true)
    private DamUtil unusedDamUtil = null;
 
 
    @Mocked
    private Resource resource;
 
    @Test
    public void test_that_empty_iterator_produces_empty_map() {
        new Expectations() {
            {
                DamUtil.getAssets(resource);
                result = Collections.<Asset> emptySet().iterator();
            }
        };
        Map<String, Asset> result = new ClassWhichUsesAStaticMethodFromAPI().getAssetTitles(resource);
        assertNotNull(result);
        assertEquals(0, result.size());
    }
    @Test
    public void test_with_reference_search() {
        assertTrue(true);
    }
}
@RunWith(JMockit.class)
public class ClassWhichUsesAnInstanceMethodFromAPITest {
 
 
    @Tested
    private ClassWhichUsesAnInstanceMethodFromAPI instance;
 
    @Mocked
    private Resource parsys;
 
 
    @Mocked
    private Paragraph firstPar;
 
 
    @Mocked
    private Paragraph secondPar;
 
 
    @Test
    public void test_empty_parsys_returns_zero() {
        new MockUp<ParagraphSystem>() {
            @Mock
            public void $init(Resource resource) {
                assertEquals(parsys, resource);
            }
            @Mock
            public List<Paragraph> paragraphs() {
                return Collections.<Paragraph> emptyList();
            }
        };
        assertEquals(0, instance.countParagraphs(parsys));
    }
}

Anwendungsfall 3 – Benutzerdefinierter Code, der eine Basisklasse aus der API erweitert

Wie bei SCR Generation müssen Sie Code, der eine Basisklasse (abstrakt oder konkret) aus der AEM-API erweitert, mit dem UberJar testen.

Häufige Entwicklungsaufgaben mit Maven

Hinzufügen von Pfaden zum Content-Modul

Das Content-Modul enthält die Datei src/main/content/META-INF/vault/filter.xml, die die Filter für das von Maven erstellte AEM-Paket definiert. Die vom Maven-Archetyp erstellte Datei sieht wie folgt aus:

src/main/content/META-INF/vault/filter.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
</workspaceFilter>

Diese Datei wird auf verschiedene Arten verwendet:

  • durch das content-package-maven-plugin, um zu bestimmen, welcher Content im Paket enthalten sein soll
  • durch das VLT-Werkzeug, um zu bestimmen, welche Pfade berücksichtigt werden sollen
  • Wenn das Paket in AEM Package Manager neu erstellt wird, wird dabei auch die Liste der einzubeziehenden Pfade definiert.

Abhängig von den Anforderungen Ihrer Anwendung sollten Sie weitere Pfade hinzufügen, um weitere Inhalte hinzuzufügen, z. B.:

  • Rollout-Konfigurationen
  • Blueprints
  • Workflow-Modelle
  • Design-Seiten
  • Beispielinhalt

Um weitere Pfade hinzuzufügen, fügen Sie <filter>-Elemente hinzu:

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
    <filter root="/etc/msm/rolloutconfigs/myrolloutconfig"/>
    <filter root="/etc/blueprints/mysite/globalsite"/>
    <filter root="/etc/workflow/models/myproject"/>
    <filter root="/etc/designs/myproject"/>
    <filter root="/content/myproject/sample-content"/>
</workspaceFilter>

Hinzufügen von Pfaden zum Paket ohne Synchronisierung

Wenn Sie Dateien haben, die dem von content-package-maven-plugin erstellten Paket hinzugefügt, aber nicht zwischen dem Dateisystem und dem Repository synchronisiert werden sollen, können Sie .vltignore-Dateien verwenden. Diese Dateien haben die gleiche Syntax wie .gitignore-Dateien.

Beispielsweise verwendet der Archetyp eine .vltignore-Datei, um zu verhindern, dass die JAR-Datei, die mit dem Bundle installiert wird, zurück zum Dateisystem synchronisiert wird:

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar

Synchronisieren von Pfaden ohne Hinzufügen zum Paket

In einigen Fällen möchten Sie vielleicht bestimmte Pfade zwischen dem Dateisystem und dem Repository synchronisieren, aber nicht in das Paket aufnehmen, das in AEM installiert werden soll.

Ein typischer Fall ist der Pfad /libs/foundation. Zu Entwicklungszwecken können Sie den Inhalt dieses Pfades in Ihrem Dateisystem zur Verfügung stellen, sodass z. B. Ihr IDE JSP-Inklusionen auflösen kann, die JSPs in /libs einbeziehen. Sie möchten jedoch wahrscheinlich diesen Teil nicht in das Paket aufnehmen, das Sie erstellen, da der /libs-Teil Produktcode enthält, der von benutzerdefinierten Implementierungen nicht geändert werden darf.

Zu diesem Zweck können Sie eine Datei src/main/content/META-INF/vault/filter-vlt.xml bereitstellen. Wenn diese Datei vorhanden ist, wird sie vom VLT-Werkzeug verwendet, z. B. wenn Sie vlt up und vlt ci ausführen oder vlt sync eingerichtet haben. Das content-package-maven-plugin verwendet weiterhin die Datei src/main/content/META-INF/vault/filter.xml beim Erstellen des Pakets.

Um beispielsweise /libs/foundation lokal zu Entwicklungszwecken zur Verfügung zu stellen, aber nur /apps/myproject in das Paket einzubinden, verwenden Sie die folgenden beiden Dateien.

src/main/content/META-INF/vault/filter.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
</workspaceFilter>

src/main/content/META-INF/vault/filter-vlt.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/libs/foundation"/>
    <filter root="/apps/myproject"/>
</workspaceFilter>

Außerdem müssen Sie das maven-resources-plugin neu konfigurieren, damit diese Dateien nicht in das Paket eingebunden werden – die filter.xml-Datei wird nicht angewendet, wenn das Paket installiert ist, sondern nur, wenn das Paket erneut mit dem Package Manager erstellt wird.

Ändern Sie den Abschnitt <resources> im Inhalts-POM entsprechend:

src/main/content/pom.xml

<!-- ... -->
<resources>
	<resource>
		<directory>src/main/content/jcr_root</directory>
		<filtering>false</filtering>
		<excludes>
			<exclude>**/.vlt</exclude>
			<exclude>**/.vltignore</exclude>
			<exclude>libs/</exclude>
		</excludes>
	</resource>
</resources>
<!-- ... -->

Arbeit mit JSPs

Bei der bisher beschriebenen Maven-Einrichtung wird ein Inhaltspaket erstellt, das auch Komponenten und ihre entsprechenden JSPs enthalten kann. Allerdings behandelt Maven sie wie jede andere Datei, die zum Inhaltspaket gehört, und erkennt sie nicht einmal als JSPs.

Die resultierenden Komponenten funktionieren dennoch in AEM, aber es hat zwei große Vorteile, Maven auf die JSPs hinzuweisen:

  • Maven kann fehlschlagen, wenn die JSPs Fehler enthalten, sodass diese während des Builds und nicht erst beim ersten Kompilieren in AEM entdeckt werden
  • Für IDEs, die Maven-Projekte importieren können, werden außerdem Codevervollständigung und Unterstützung für Tag-Bibliotheken in den JSPs ermöglicht

Zwei Schritte sind hierfür erforderlich:

  1. Tag-Bibliotheks-Abhängigkeiten hinzufügen
  2. Die JSPs im Rahmen des Maven-Kompilierungsvorgangs kompilieren

Hinzufügen von Tag-Bibliotheks-Abhängigkeiten

Die folgenden Abhängigkeiten müssen dem POM des Inhaltsmoduls hinzugefügt werden.

Hinweis:

Wenn Sie die Produktabhängigkeiten nicht importieren, wie oben unter Importieren von AEM-Produktabhängigkeiten beschrieben, müssen diese auch zum übergeordneten POM hinzugefügt werden. Außerdem muss die Version hinzugefügt werden, die Ihrem AEM-Setup entspricht, wie oben unter Hinzufügen von Abhängigkeiten beschrieben. Die Kommentare in jedem folgenden Eintrag zeigen das Paket, nach dem Sie in der Abhängigkeitssuche suchen müssen.

Hinweis:

Das com.adobe.granite.xssprotection-Artefakt ist nicht im POM cq-quickstart-product-dependencies enthalten und benötigt vollständige Maven-Koordinaten, die Sie in der Abhängigkeitssuche erhalten.

myproject/content/pom.xml

<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.jcr.jcr-wrapper</artifactId>
    <!-- javax.jcr -->
</dependency>
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.api</artifactId>
</dependency>
<dependency>
    <groupId>com.day.cq</groupId>
    <artifactId>cq-commons</artifactId>
    <!-- com.day.cq.commons -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-commons</artifactId>
    <!-- com.day.cq.wcm.commons -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-api</artifactId>
    <!-- com.day.cq.wcm.api -->
</dependency>
<dependency>
    <groupId>com.day.commons</groupId>
    <artifactId>day-commons-jstl</artifactId>
    <!-- javax.servlet.jsp.jstl.core -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-taglib</artifactId>
    <!-- com.day.cq.wcm.tags -->
</dependency>
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.scripting.jsp.taglib</artifactId>
    <!-- org.apache.sling.scripting.jsp.taglib -->
</dependency>
<dependency>
    <groupId>com.adobe.granite</groupId>
    <artifactId>com.adobe.granite.xssprotection</artifactId>
    <!-- com.adobe.granite.xss -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-core</artifactId>
    <!-- com.day.cq.wcm.core.components -->
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <!-- org.apache.commons.lang3 -->
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
</dependency>

Kompilierung von JSPs während der Maven-Kompilierungsphase

Um JSPs in der Kompilierungsphase von Maven zu kompilieren, verwenden wir das Maven JspC-Plug-in für Apache Sling, wie unten gezeigt:

  • Wir richten eine Ausführung für das jspc-Ziel ein (diese ist standardmäßig an die Kompilierungsphase gebunden, sodass wir die Phase nicht explizit festlegen müssen)
  • Wir legen fest, dass es alle JSPs in ${project.build.directory}/jsps-to-compile kompiliert
  • und das Ergebnis in ${project.build.directory}/ignoredjspc ausgibt (dies entspricht myproject/content/target/ignoredjspc)
  • Wir richten ein, dass maven-resources-plugin die JSPs in der generate-sources-Phase nach ${project.build.directory}/jsps-to-compile kopiert, und konfigurieren es so, dass es den libs/-Ordner nicht kopiert (dieser Ordner enthält AEM-Produktcode und wir möchten die Abhängigkeiten für die Kompilierung nicht zu unserem Projekt hinzufügen und müssen auch nicht prüfen, ob er kompiliert).

Unser Hauptziel besteht darin, wie oben beschrieben, die JSPs zu validieren und sicherzustellen, dass der Build-Vorgang fehlschlägt, wenn sie Fehler enthalten. Daher kompilieren wir sie in einem separaten Verzeichnis, das ignoriert wird (und sofort anschließend gelöscht wird, wie Sie in einem Moment sehen werden).

Das Ergebnis des Maven-JspC-Plug-ins kann auch als Teil eines OSGi-Pakets gebündelt und bereitgestellt werden, aber dies hat andere Auswirkungen und Nebeneffekte und geht über unser Ziel der Validierung der JSPs hinaus.

Um die aus den JSPs kompilierten Klassen zu löschen, richten wir das Maven-Clean-Plug-in wie unten gezeigt ein. Wenn Sie das Ergebnis des Maven-JspC-Plug-ins untersuchen möchten, führen Sie mvn compile in myproject/content aus. Anschließend finden Sie das Ergebnis in myproject/content/target/ignoredjspc.

myproject/content/pom.xml

<build>
  <!-- ... -->
  <plugins>
    <!-- ... -->
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <executions>
        <execution>
          <id>copy-resources</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${project.build.directory}/jsps-to-compile</outputDirectory>
            <resources>
              <resource>
                <directory>src/main/content/jcr_root</directory>
                <excludes>
                  <exclude>libs/**</exclude>
                </excludes>
              </resource>
            </resources>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <groupId>org.apache.sling</groupId>
      <artifactId>maven-jspc-plugin</artifactId>
      <version>2.0.6</version>
      <executions>
        <execution>
          <id>compile-jsp</id>
          <goals>
            <goal>jspc</goal>
          </goals>
          <configuration>
            <jasperClassDebugInfo>false</jasperClassDebugInfo>
            <sourceDirectory>${project.build.directory}/jsps-to-compile</sourceDirectory>
            <outputDirectory>${project.build.directory}/ignoredjspc</outputDirectory>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <artifactId>maven-clean-plugin</artifactId>
      <executions>
        <execution>
          <id>remove-compiled-jsps</id>
          <goals>
            <goal>clean</goal>
          </goals>
          <phase>process-classes</phase>
          <configuration>
            <excludeDefaultDirectories>true</excludeDefaultDirectories>
            <filesets>
              <fileset>
                <directory>${project.build.directory}/jsps-to-compile</directory>
                <directory>${project.build.directory}/ignoredjspc</directory>
              </fileset>
            </filesets>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Hinweis:

Je nachdem, ob Sie tatsächlich JSP-Code in /libs verwenden (d. h. JSPs von dort aus einbeziehen), müssen Sie genauer festlegen, welche JSPs zur Kompilierung kopiert werden.

Beispiel: Wenn Sie /libs/foundation/global.jsp einbeziehen, können Sie die folgende Konfiguration für das maven-resources-plugin anstatt der oben beschriebenen Konfiguration nutzen, die /libs komplett überspringt.

  <resource>     <directory>src/main/content/jcr_root</directory>     <includes>         <include>apps/**</include>         <include>libs/foundation/global.jsp</include>    </includes> </resource>  

Arbeit mit SCM-Systemen

Beim Arbeiten mit Quellkonfigurationsmanagement (SCM) sollten Sie Folgendes sicherstellen:

  • Das VCS ignoriert Nichtquellartefakte im Dateisystem
  • VLT ignoriert Artefakte des VCS und checkt sie nicht in das Repository ein

Hinweis:

In dieser Beschreibung wird die Konfiguration von Maven für Kompatibilität mit Ihrem SCM nicht erläutert. Dies wird ausführlich in der Maven-POM-Referenz und der Dokumentation zum Maven-SCM-Plug-in erläutert.

Von SCM auszuschließende Muster

Hier ist eine typische Liste der Muster, die aus SCM ausgeschlossen werden sollten. Falls Sie beispielsweise git verwenden, können Sie sie zur .gitignore-Datei Ihres Projekts hinzufügen.

.gitignore-Beispiel

# Ignore VLT files
.vlt
.vlt-sync.log
.vlt-sync-config.properties

# Ignore Quickstart launches in the source tree
license.properties
crx-quickstart

# Ignore compilation results
target

# Ignore IDE and Operating System artifacts
.idea
.classpath
.metadata
.project
.settings
maven-eclipse.xml
*.iml
*.ipr
*.iws
.DS_Store

Ignorieren von SCM-Steuerdateien in VLT

In einigen Fällen haben Sie möglicherweise SCM-Steuerdateien in der Content-Quellbaumstruktur, die nicht in das Repository eingecheckt werden sollen.

Betrachten Sie die folgende Situation:

Der Archetyp hat bereits eine .vltignore-Datei erstellt, um zu verhindern, dass die installierte Bundle-jar-Datei wieder mit dem Dateisystem synchronisiert wird:

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar

Selbstverständlich möchten Sie diese Datei auch nicht in Ihrem SCM haben. Wenn Sie also z. B. git verwenden, müssen Sie eine entsprechendegitignore-Datei hinzufügen:

src/main/content/jcr_root/apps/myproject/install/.gitignore

*.jar

Da die .gitignore-Datei auch nicht zum Repository hinzugefügt werden soll, muss die .vltignore-Datei erweitert werden, um die .gitignore-Datei einzuschließen:

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar
.gitignore

Arbeit mit Bereitstellungsprofilen

Wenn Ihr Build-Vorgang ein Teil eines umfassenden Entwicklungslebenszyklus-Managements ist, z. B. eines kontinuierlichen Integrationsvorgangs, müssen Sie oft Bereitstellungen auf anderen Geräten durchführen als nur auf der lokalen Instanz des Entwicklers.

In solchen Fällen können Sie dem POM des Projekts einfach neue Maven-Build-Profile hinzufügen.

Im folgenden Beispiel wird ein Profil-integrationServer hinzugefügt, der die Hostnamen und Ports für die Autoren- und Veröffentlichungsinstanzen neu definiert. Sie können auf diese Server bereitstellen, indem Sie Maven wie unten gezeigt im Hauptverzeichnis des Projekts ausführen.

# install on integration test author
$ mvn -PautoInstallPackage -PintegrationServer install

# install on integration test publisher
$ mvn -PautoInstallPackagePublish -PintegrationServer install

myproject/pom.xml

<profiles>

    <!-- ... -->
    
    <profile>
        <id>integrationServer</id>
        <properties>
            <crx.host>dev-author.intranet</crx.host>
            <crx.port>5502</crx.port>
            <publish.crx.host>dev-publish.intranet</publish.crx.host>
            <publish.crx.port>5503</publish.crx.port>
        </properties>
    </profile>
</profiles>

Arbeit mit AEM Communities

Bei einer Lizenzierung für Kompatibilität mit AEM Communities ist ein zusätzliches API-jar erforderlich.

Weitere Details finden Sie unter Verwendung von Maven für Communities

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie