Konfigurera en lokal AEM utvecklingsmiljö

Guide to setting up a local development for Adobe Experience Manager, AEM. Omfattar viktiga ämnen som rör lokal installation, Apache Maven, integrerade utvecklingsmiljöer samt felsökning/felsökning. Utveckling med Eclipse IDE, CRXDE Lite, Visual Studio Code och IntelliJ diskuteras.

Ökning

Att konfigurera en lokal utvecklingsmiljö är första steget i utvecklingen för Adobe Experience Manager eller AEM. Ta dig tid att konfigurera en kvalitetsutvecklingsmiljö för att öka produktiviteten och skriva bättre kod snabbare. Vi kan bryta ned en AEM lokal utvecklingsmiljö i fyra områden:

Installera lokala AEM

När vi syftar på en lokal AEM talar vi om en kopia av Adobe Experience Manager som körs på en utvecklares personliga maskin. Utvecklingen av Alla AEM börja med att skriva och köra kod mot en lokal AEM.

Om du inte har använt AEM tidigare kan du installera två grundläggande körningslägen: Författare och Publish. Författaren runmode är den miljö som digitala marknadsförare använder för att skapa och hantera innehåll. När du oftast utvecklar kod distribuerar du kod till en Author-instans. På så sätt kan du skapa sidor och lägga till och konfigurera komponenter. AEM Sites är ett CMS för WYSIWYG-redigering och därför kan merparten av CSS och JavaScript testas mot en redigeringsinstans.

Det är också kritisk testkod mot en lokal Publish-instans. Instansen Publish är den AEM miljö som besökare på webbplatsen interagerar med. Även om Publish-instansen är samma teknikstack som Författaren -instansen finns det vissa viktiga skillnader när det gäller konfigurationer och behörigheter. Koden måste testas mot en lokal Publish-instans innan den befordras till miljöer på högre nivå.

Steg

~/aem-sdk
    /author
    /publish

~/aem-sdk
    /author
        + aem-author-p4502.jar
        + license.properties
    /publish
        + aem-publish-p4503.jar
        + license.properties

Dubbelklicka på filen aem-publish-p4503.jar för att installera Publish -instansen. Detta startar Publish-instansen som körs på port 4503 på den lokala datorn.

Använda kommandorad

Ett alternativ till att dubbelklicka på JAR-filen är att starta AEM från kommandoraden eller skapa ett skript (.bat eller .sh) beroende på den lokala operativsystemsvarianten. Nedan visas ett exempel på exempelkommandot:

$ java -Xmx2048M -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=30303 -jar aem-author-p4502.jar -gui -r"author,localdev"

Här är -X JVM-alternativ och -D är ytterligare ramverksegenskaper. Mer information finns i Distribuera och underhålla en AEM och Fler alternativ finns i QuickStart-filen.

Installera Apache Maven

Apache Maven är ett verktyg för att hantera bygg- och distributionsproceduren för Java-baserade projekt. AEM är en Java-baserad plattform och Maven är standardsättet att hantera kod för ett AEM projekt. När vi säger AEM Maven Project eller bara ditt AEM Project syftar vi på ett Maven-projekt som innehåller all anpassad kod för din webbplats.

Alla AEM ska byggas av den senaste versionen av AEM Project Archetype: https://github.com/adobe/aem-project-archetype. AEM Project Archetype innehåller en startdel för ett AEM med exempelkod och innehåll. AEM Project Archetype innehåller även AEM WCM Core Components som konfigurerats för användning i ditt projekt.

Steg

$ mvn --version
Apache Maven 3.3.9
Maven home: /Library/apache-maven-3.3.9
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8

Konfigurera en integrerad utvecklingsmiljö

En integrerad utvecklingsmiljö eller IDE är ett program som kombinerar en textredigerare, syntaxstöd och byggverktyg. Beroende på vilken typ av utveckling du håller på med kan en utvecklingsmiljö vara att föredra framför en annan. Oavsett vilken utvecklingsmiljö det gäller är det viktigt att du regelbundet kan push-kod till en lokal AEM för att kunna testa den. Det är viktigt att ibland pull-konfigurationer från en lokal AEM till ditt AEM projekt för att kunna finnas kvar i ett källkontrollshanteringssystem som Git.

Nedan visas några av de populäraste IDE:erna som används för AEM med motsvarande videofilmer som visar integrationen med en lokal AEM.

$ mvn clean install -PautoInstallSinglePackage -Pclassic

Kontrollera classic på fliken Maven-profil när du använder en IDE.

IntelliJ Maven-profil

Eclipse IDE

Eclipse IDE är en av de populäraste IDE:erna för Java™-utveckling, till stor del eftersom den har öppen källkod och gratis! Adobe tillhandahåller ett plugin-program, AEM Developer Tools, för Eclipse som gör det enklare att utveckla med ett bra användargränssnitt att synkronisera kod med en lokal AEM. Den integrerade utvecklingsmiljön Eclipse rekommenderas för utvecklare som inte AEM till stor del på grund av det grafiska användargränssnittet i AEM Developer Tools.

Installation och installation

IntelliJ IDEA

IntelliJ IDEA är en kraftfull IDE för professionell Java™-utveckling. IntelliJ IDEA finns i två versioner, en kostnadsfri Community-utgåva och en kommersiell (betald) Ultimate-version. Den kostnadsfria Community-versionen av IntellIJ IDEA räcker för mer AEM utveckling, men Ultimate utökar sin funktionsuppsättning.

Installation and Setup

Visual Studio Code

Visual Studio-kod har snabbt blivit ett favoritverktyg för gränssnittsutvecklare med utökat stöd för JavaScript, Intellisense och webbläsarfelsökning. Visual Studio Code är kostnadsfri med öppen källkod och många kraftfulla tillägg. Visual Studio Code kan konfigureras för integrering med AEM med hjälp av ett Adobe-verktyg, repo. Det finns också flera tillägg som stöds av communityn som kan installeras för integrering med AEM.

Visual Studio Code är ett bra val för gränssnittsutvecklare som primärt skriver CSS/LESS och JavaScript-kod för att skapa AEM klientbibliotek. Det här verktyget kanske inte är det bästa alternativet för nya AEM eftersom noddefinitioner (dialogrutor, komponenter) måste redigeras i rå XML. Det finns flera Java™-tillägg tillgängliga för Visual Studio Code, men om du primärt gör Java™-utveckling Eclipse IDE eller IntelliJ kan det vara att föredra.

Viktiga länkar

CRXDE Lite

CRXDE Lite är en webbläsarbaserad vy av AEM. CRXDE Lite är inbäddad i AEM och gör att en utvecklare kan utföra standardutvecklingsuppgifter som att redigera filer, definiera komponenter, dialogrutor och mallar. CRXDE Lite är inte avsedd som en fullständig utvecklingsmiljö, men är effektivt som felsökningsverktyg. CRXDE Lite är användbart när du vill utöka eller helt enkelt förstå produktkod utanför kodbasen. CRXDE Lite ger en kraftfull vy över databasen och ett sätt att effektivt testa och hantera behörigheter.

CRXDE Lite ska användas med andra IDE:er för att testa och felsöka kod, men aldrig som det primära utvecklingsverktyget. Den har begränsat syntaxstöd, inga funktioner för automatisk komplettering och begränsad integrering med system för källkodshantering.

Felsökning

Hjälp! Min kod fungerar inte! Precis som med all utveckling finns det tillfällen (förmodligen många) där koden inte fungerar som förväntat. AEM är en kraftfull plattform, men med stor kraft … är mycket komplicerad. Nedan visas några viktiga startpunkter när du felsöker och spårar problem (men långt ifrån en fullständig lista över saker som kan gå fel):

Verifiera koddistribution

Ett bra första steg när du stöter på ett problem är att kontrollera att koden har distribuerats och installerats korrekt till AEM.

Kontrollera loggarna

AEM är en chattingplattform och loggar användbar information i error.log. error.log finns där AEM har installerats: < aem-installation-folder>/crx-quickstart/logs/error.log.

En användbar teknik för att spåra problem är att lägga till loggsatser i Java™-koden:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...

public class MyClass {
    private final Logger log = LoggerFactory.getLogger(getClass());

    ...

    String myVariable = "My Variable";

    log.debug("Debug statement of myVariable {}", myVariable);

    log.info("Info statement of myVariable {}", myVariable);
}

Som standard är error.log konfigurerad att logga INFO-satser. Om du vill ändra loggnivån kan du göra det genom att gå till Log Support: http://localhost:4502/system/console/slinglog. Du kan också upptäcka att error.log är för kattlig. Du kan använda Log Support för att konfigurera loggsatser för endast ett angivet Java™-paket. Detta är en god vana för projekt för att enkelt kunna skilja skräddarsydda kodproblem från OTB-AEM.

Paketet är i ett installerat läge bundle-active

Alla paket (exklusive fragment) ska vara i läget Active. Om du ser ditt kodpaket i läget Installed finns det ett problem som måste lösas. Det här är oftast ett beroendeproblem:

På skärmbilden ovan är WKND Core bundle ett Installed-läge. Detta beror på att paketet förväntar sig en annan version av com.adobe.cq.wcm.core.components.models än den som är tillgänglig på AEM.

Ett användbart verktyg som kan användas är Dependency Finder: http://localhost:4502/system/console/depfinder. Lägg till Java™-paketnamnet för att kontrollera vilken version som är tillgänglig på AEM:

Som fortsättning på ovanstående exempel ser vi att den version som är installerad på AEM är 12.2 vs 12.6 som paketet förväntades. Därifrån kan du arbeta baklänges och se om beroendena för Maven AEM matchar beroendena för Maven i det AEM projektet. I exemplet ovan är Core Components v2.2.0 installerat på AEM men kodpaketet skapades med ett beroende av v2.2.2, vilket är orsaken till beroendeproblemet.

Verifiera registrering av försäljningsmodeller osgi-component-sling-models

AEM måste backas upp av en Sling Model för att inkapsla eventuell affärslogik och säkerställa att HTML-återgivningsskriptet förblir rent. Om du får problem där Sling Model inte kan hittas kan det vara bra att kontrollera Sling Models från konsolen: http://localhost:4502/system/console/status-slingmodels. Detta anger om din Sling-modell har registrerats och vilken resurstyp (komponentsökvägen) den är kopplad till.

Visar registreringen av en Sling Model, BylineImpl som är kopplad till en komponentresurstyp av wknd/components/content/byline.

CSS- eller JavaScript-problem

För de flesta CSS- och JavaScript-problem är det mest effektiva sättet att felsöka webbläsarens utvecklingsverktyg. Om du vill begränsa problemet när du utvecklar mot en AEM författarinstans kan det vara bra att visa sidan"som publicerad".

Öppna menyn Page Properties och klicka på View as Published. Sidan öppnas utan AEM Editor och med en frågeparameter inställd på wcmmode=disabled. Detta inaktiverar effektivt gränssnittet för AEM och gör det mycket enklare att felsöka/felsöka frontend-problem.

Ett annat vanligt fel uppstod när front end-kod utvecklades. CSS/JS läses in. Som ett första steg måste du kontrollera att webbläsarhistoriken har rensats och vid behov starta en webbläsare som inte känner av eller en ny session.

Felsöka klientbibliotek

Med de olika metoderna för kategorier och inbäddning för att inkludera flera klientbibliotek kan det vara besvärligt att felsöka. AEM visar flera verktyg som kan hjälpa dig med detta. Ett av de viktigaste verktygen är Rebuild Client Libraries som tvingar AEM att kompilera om alla LESS-filer och generera CSS.