In the Java SE realm, GUI components are based on Java classes with the help of libraries such as AWT, Swing or the newer JavaFX. As such, they can be shared across projects, to be inherited and composed.
Things are entirely different in the Java EE world, as GUI components are completely heterogeneous in nature: they may include static HTML pages, JavaScript files, stylesheets, images, Java Server Pages or Java Server Faces. Solutions to share these resources must be tailored to each type.
- Since Servlet 3.0 (Java EE 6), static resources, such as HTML, JavaScript, CSS and images can be shared quite easily.
Those resources need to be packaged into the
META-INF/resourcesfolder of a JAR. At this point, putting the JAR inside theWEB-INF/libfolder of a webapp will make any such resource available at the webapp’s context root.A disadvantage of this approach is that shared resources are also exposed publicly, including JSP that are not meant to be.
- An alternative to share resources protected under
WEB-INF, which is also available before Servlet 3.0, is to leverage the build tool. In this case, Maven offers a so-called overlay feature through the Maven WAR plugin. This requires both adding the WAR containing resources and dependencies as well as some POM configuration.<project...> ... <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <overlays> <overlay> <groupId>ch.frankel.blog</groupId> <artifactId>resources</artifactId> </overlay> </overlays> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>ch.frankel.blog</groupId> <artifactId>resources</artifactId> <version>1.0.0</version> <type>war</type> <scope>runtime</scope> </dependency> </dependencies> </project>
At this point, resources belonging to the dependent WAR artifact will be copied to the project at build-time. Not resources existing in the project may be overwritten… on purpose or by accident. The biggest disadvantage of WAR overlays, however, is that resources have to be packaged in the WAR artifact while corresponding classes have to be in another JAR artifact.
- I’ve not much experience in Java Server Faces technology, but it seems sharing pages across different webapps requires the use of
ResourceResolver. - Finally, some frameworks are entirely built toward sharing GUI resources.
For example, with Vaadin, GUI components are based on Java classes, as for Java SE, thus making those components inheritable and composable.
Furthermore, using images can be achieved in a few lines of code and is easy as pie:
Image image = new Image("My image", new ClassResource("ch/frankel/blog/resources/image.png")); ui.setContent(image);
I think Java EE is sadly lacking regarding reuse of front-end resources. Of course, one can choose client-based frameworks to overcome this limitation though they bring their own pros and cons. In all cases, ease of reuse should be an important criteria for choosing front-end technologies.