Ich benutze für alle Projekte Maven. Der eine oder andere mag mit Maven auf dem Kriegsfuß stehen (was ich zwar nicht verstehe, aber akzeptiere). Bisher war ich (und an anderer Stelle war es auch nicht notwendig, darüber nachzudenken) für eine saubere Trennung von Code und Resourcen. Das bedeutet z.B. das der Code einer Wicket-Komponente z.B. im Pfad src/main/java/de/wicketpraxis/ zu finden ist und das Markup in src/main/resources/de/wicketpraxis.

Das Projekt wächst und gedeiht und es entstehen unzählige Komponenten (ein Zeichen dafür, dass man mit Wicket sehr sehr einfach eigene Komponenten erstellen kann). Im Laufe der Zeit hat es sich als unpraktisch herausgestellt, in der IDE immer zwischen diesen beiden Verzeichnissen zu wechseln. Auch beim Refactoring kann es sich als lästig erweisen, weil man an zwei Stellen die selbe Operation anwenden muss (zumindest in Eclipse).

Ich habe daher alle Projekte umgestellt und kann nun die Markup-Dateien in das selbe Verzeichnis/Package wie die Komponente legen. Die Angst, dass die Übersichtlichkeit leidet, hat sich als unbegründet erwiesen, die Produktivität ist spürbar besser. Folgende Anpassung muss man daher in einem Projekt vornehmen. In der pom.xml ist folgender Block einzufügen:

  <build>
...
    <resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
      <resource>
        <directory>src/main/java</directory>
        <excludes>
          <exclude>**/*.java</exclude>
        </excludes>
      </resource>
    </resources>
...
  </build>

Wenn man nun die Anwendung über Jetty aus dem Projekt heraus starten möchte, empfiehlt sich ein Ansatz, den ich bereits im folgenden Beitrag erwähnt habe: Wicket Resourcen mit Jetty nachladen. Allerdings müssen wir dazu den angepassten ResourceStreamLocator entsprechend erweitern. Am besten wir schreiben eine neue Klasse:

package de.wicketpraxis.wicket.util.resource;

import org.apache.wicket.util.file.File;
import org.apache.wicket.util.resource.FileResourceStream;
import org.apache.wicket.util.resource.IResourceStream;
import org.apache.wicket.util.resource.locator.ResourceStreamLocator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MavenDevResourceAndSourceStreamLocator extends ResourceStreamLocator
{
  private static final Logger _logger = LoggerFactory.getLogger(MavenDevResourceAndSourceStreamLocator.class);
  
  final static String MAVEN_RESOURCE_PATH="src/main/resources/";
  final static String MAVEN_JAVASOURCE_PATH="src/main/java/";
  
  @Override
  public IResourceStream locate(final Class<?> clazz, final String path)
  {
    IResourceStream located=getFileSysResourceStream(MAVEN_RESOURCE_PATH,path);
    if (located==null)
    {
      located=getFileSysResourceStream(MAVEN_JAVASOURCE_PATH,path);
    }
    if (located != null)
    {
      if (_logger.isInfoEnabled()) _logger.info("Locate: " + clazz + " in " + path+" -> "+located);
      return located;
    }
    located=super.locate(clazz, path);
    if (_logger.isInfoEnabled()) _logger.info("Locate: " + clazz + " in " + path+" -> "+located+"(Fallback)");    
    return located;
  }

  private static IResourceStream getFileSysResourceStream(String prefix, String path)
  {
    File f=new File(prefix+path);
    if ((f.exists()) && (f.isFile()))
    {
      return new FileResourceStream(f);
    }
    return null;
  }
}

Die Einbindung funktioniert wie beim letzten Mal:

if (DEVELOPMENT.equalsIgnoreCase(configurationType))
{
  getResourceSettings().setResourceStreamLocator(new MavenDevResourceAndSourceStreamLocator());
}

Jetzt sollte man (wenn alles andere entsprechend vorbereitet ist) mit mvn jetty:run -Dwicket.configuration=development Jetty aus dem Projekt heraus starten können. Sobald man Änderungen am Markup vorgenommen hat, werden diese neu geladen.

Um seiner Wicket-Anwendung ein geeignetes Favicon zu verleihen, erstellt man einen HeaderContributor. Als Parameter dient eine ResourceReference auf das darzustellende Icon.

public class FavIconHeaderContributor implements IHeaderContributor
{
  ResourceReference _resourceReference;

  public FavIconHeaderContributor(ResourceReference resourceReference)
  {
    _resourceReference=resourceReference;
  }

  public void renderHead(IHeaderResponse response)
  {
    CharSequence url = RequestCycle.get().urlFor(_resourceReference);
    response.renderString(getFavIconReference(url));
  }

  private CharSequence getFavIconReference(CharSequence url)
  {
    StringBuilder sb=new StringBuilder();
    sb.append("<link rel=\"shortcut icon\" href=\"");
    sb.append(url);
    sb.append("\" type=\"image/x-icon\">\n");
    return sb.toString();
  }
}

Bei großen Wicket-Projekten kann das hotdeployment des maven jetty plugins schonmal dazu führen, dass aus dem Vorteil ein Nachteil wird. Dabei ist das Ziel recht einfach: Nur die Html-Templates für die Wicket-Komponenten sollen neu geladen werden, wenn sich da was verändert hat. Alle Vorschläge aus den Foren sind mir zu aufwendig Außerdem mag ich die Html-Dateien nicht in das selbe Verzeichnis wie die Quelltexte legen. Ich habe mir daher einen für das Problem angepassten ResourceStreamLocator geschrieben:

public class MavenDevResourceStreamLocator extends ResourceStreamLocator
{
  String _prefix="src/main/resources/";

  public IResourceStream locate(final Class clazz, final String path)
  {
    IResourceStream located=getFileSysResourceStream(path);
    if (located != null)
    {
      // alles ok
      return located;
    }
    // fallback
    located=super.locate(clazz, path);
    return located;
  }

  private IResourceStream getFileSysResourceStream(String path)
  {
    File f=new File(_prefix+path);
    if ((f.exists()) && (f.isFile()))
    {
      return new FileResourceStream(f);
    }
    return null;
  }
}

Eingebaut wird das dann in die init-Methode der Application-Klasse wie folgt:

if (DEVELOPMENT.equalsIgnoreCase(configurationType))
{
  getResourceSettings().setResourceStreamLocator(new MavenDevResourceStreamLocator());
}

Und schon werden alle Änderungen an den Html-Dateien sichtbar.