Duchess

In my search for new frameworks to try out, I came across a little web framework called Wicket. The idea to really separate the logic from the markup appealed to me, as well as the fact that you wouldn’t need as much JavaScript anymore. So I went looking for a book about the subject and found Wicket in Action written by some of the core contributors to Wicket. It was a tough job summarizing the book as it is crammed with lots of examples about what you can do with it. So please forgive me if the following is a bit dry, I can assure you that the book itself isn’t!

Part 1 Getting started with Wicket
This part of the book contains a quick introduction to Wicket so you can get started.

What is Wicket
Wicket is an open source web-application framework for the Java platform, which bridges the impedance mismatch between the stateless HTTP and stateful server-side programming in Java by providing a programming model that hides the fact that you’re working on a stateless protocol. With Wicket, you program in just Java and just HTML using meaningful abstractions.

The architecture of Wicket
The architecture of Wicket revolves around several objects that play a central role in request processing: Application, Session, SessionStore, Request, Response, RequestCycle, RequestCycleProcessor and RequestTarget. When Wicket determines that it should handle a request, it delegates the processing to a request-cycle object. The processing is done in four consecutive steps: decode request, determine request target, process events and respond.
In order to build applications, you would like to reuse as much as possible, so you don’t have to reinvent everything. To this end there are many Wicket components. Each of these components consists of three parts, also known as the component triad: the markup, the Java component and the model. The markup is only concerned with presentation, you’ll find no logic in it. The UI logic is encoded in the Java components. Models are optional and are an indirection for how to get the data that drives the Java components. Typically, components are meant for one purpose. Labels render text. Text fields handle text input. Repeaters repeat elements, and so forth. But in many cases, you want to use a certain component but add functionality that isn’t related to its core function. This is where behaviors come in, they allow you to extend components using composition. Behaviors are mainly used for —but aren’t limited to— modifying attributes of HTML tags and responding to events or calls to the components they’re bound to (their host components).

Building a cheesy Wicket application
In this chapter the presented knowledge is used to build a first application.

Part 2 Ingredients for your Wicket applications
In this part of the book several components, models and behaviors are introduced.

Understanding models
Models separate your domain layer from things in the view layer, but also bind them together to make a cohesive and neatly layered structure. Models are arguably the most crucial part of Wicket to understand because they can significantly affect your application’s performance and memory requirements. Because Wicket models mediate between the view and domain layer, they enable you to apply transformations on your data before you display it, or before you accept user input and propagate it to your domain layer. All components have a model property. Not all components do something with their model: several components work fine with no model value. From the point of view of the component, IModel acts as a bean property: it has a getter and a setter. Depending on the model implementation, the value can be local and self-contained within the model, or it can be looked up dynamically and come from a domain object. Conversely, from our point of view, the model acts as the actual value of the component. The most commonly used model classes provided by Wicket are: Model, PropertyModel, CompoundPropertyModel, LoadableDetachableModel, ResourceModel and StringResourceModel. The choice between these models depends on the requirements on the model, should it be static or dynamic, does it need to be solve serialization issues, are there lots of properties that use a model, do you need to serialize all the data in the model. Finally models can be nested to combine the advantages of several types of models.

Working with components: labels, links, and repeaters
There are many Wicket components that can be used to build your applications. This chapter discusses the most basic ones. There are several components for displaying text of which the two most important ones are Label and MultiLineLabel. Then there are three components for navigation using links, ExternalLink, BookmarkablePageLink and the special markup tag <wicket:link>. Another category of components are those to respond to client actions, namely Link, AjaxLink and AjaxFallbackLink. And the final category of the chapter contains the components for repeating markup: RepeatingView and ListView. All of these components can be hidden when necessary. The markup attributes can also be changed.

Processing user input using forms
The Form component groups controls that take user input and processes them when they’re submitted. A form has an HTML part and a Java (Wicket) part. A form is used to get input from users in the form of text fields, selection boxes, radio buttons, check boxes, buttons, and more. The form groups input controls and processes all of them together when the form is submitted. Unless told otherwise, Wicket uses the post method by default to submit forms. Wicket supports three strategies for handling form submissions, configured at the application level: no redirect, redirect to buffer, redirect to render. On the server the form submission is processed in five steps: checking required input, converting the input from string to the model type, validating the converted input, pushing the converted value to the model. A failure in any of these steps stops further processing for the field that failed. When even one field has failed any step, the last step (push input) isn’t performed for any of the fields and onError is called. After the five steps have been executed either onSubmit or onError is called.
There are many Components that can be used to let the user provide input to the form. First there are the text input components: TextField, Password and TextArea. Then there are the components that let the user select from a list of items: ListChoice, DropDownChoice, RadioChoice, ListMultipleChoice and CheckBoxMultipleChoice. For this last category it is quite common to bind the components to a model that fetches the data from some other source than the Java code. In such a case it might be convenient to use a ChoiceRenderer to bind the value and the display text to certain properties of a Java Object that represents the object. Finally there is also the CheckBox to represent boolean properties. A third category of components contains components for submitting the form data. This category contains Button, SubmitLink and AjaxSubmitLink. In order to make a cancel button, you will have to tell it to skip form processing, or in case you want to keep the values, only the validation. Then there is the validation itself. Fields can be required, and validators can be added to them. Wicket supplies a large number of validators, among them the NumberValidator, StringValidator, PatternValidator, EmailValidator, UrlValidator, EqualPasswordInputValidator. It’s also very easy to write your own validators.
The last aspect of forms is the feedback. Wicket comes with many feedback messages in various languages. The messages are provided in resource bundles and can be customized. Besides the validation messages you can add your own messages at different levels of severity (info, warn, and error). To display these messages you have to add a FeedbackPanel. The feedback panel also lets you filter for certain kinds of messages.

Composing your pages
Another issue where Wicket has lots of components to help you out is the issue of grouping and distributing components to maximize reuse and minimize maintenance costs. For grouping on pages there are three options: grouping using a WebMarkupContainer, grouping using a Panel, and grouping using a Fragment. A WebMarkupContainer groups components directly in the markup and Java code. No extra files are necessary. It should be used when the grouped components aren’t reusable, but they need to act together for Ajax updates or visibility changes. This approach is also helpful to modify attributes of a markup tag. A Panel groups components in a separate markup file and Java class. It should be used when the grouped components are to be reused in different pages, or contributions to the header are necessary. And finally a Fragment groups components in a separate component hierarchy outside the normal hierarchy, but inside the markup file. Also known as an inline panel. It should be used when the grouped components are inherent to the page/panel they’re part of and aren’t reusable in other pages/panels.
The other half of the equation in this chapter is page composition. There are three options for composition: using plain pages, using markup inheritance, and using panels. The main disadvantage of using plain pages is that all things that are on both pages have to be duplicated. With inheritance you can create a base page that contains all the components common to all pages. This base page can then put a special tag “wicket:child” in the place where the specific components have to be put for all the pages that extend the base page. All the pages that extend the base page have an element “wicket:extend” to indicate that everything between those tags has to be put in the child element. All the elements from the child page are added to the base page. This leads to problems when the child tag is wrapped in another tag, like a form. You would expect the components of the child page to be added to the form in that case, but that is not the case. This can be achieved however by turning the container into a transparent resolver. The final option is to put the common functionality in a single page and using panels to swap parts of the page with new content. To decide on which of these strategies to use there are four criteria that should be considered: previewability, duplication, navigation and bookmarkability. Since neither of the three strategies fulfills all criteria, there is no clear preferred solution.

Part 3 Going beyond Wicket basics
In this part of the book they show how to build your own components.

Developing reusable components
Wicket has a lot of abstract classes that can be used to create custom components. Making these reusable is as easy as putting the implementation code in it’s own class. Compound components can be easily created by placing components on a Panel. In order to make a compound component into a form component the FormComponentPanel has to be extended. To keep the models of the nested components and the top component synchronized, we need to override two methods: onBeforeRender, which prepares for rendering, and convertInput, which handles receiving input. onBeforeRender is defined at the level of the Component base class.

Images, CSS, and scripts: working with resources
There are some things you can’t do with Components. For example, you can’t render PDFs with them, and they don’t provide a direct answer to how images or CSS files should be handled. Therefor Wicket supports adding resources to your project. Packaged resources are resource that are packaged along with all the rest of your code, without the configuration hassle that marks most other frameworks. Packaged resources can be added to a page using auto-linking (i.e. using the wicket:link tag in the markup). WebResource is a base resource class that can be used to work with streams. To host such a resource, a ResourceLink has to be added to the page, or the resource has to be turned into a SharedResource. To implement streaming, there is also the alternative solution to set the target of an onSubmit method directly ot the ResourceStreamRequestTarget. Resources can handle requests independently and stream responses back to the client any way they like. This makes them suitable for streaming content that isn’t rendered by Wicket, but by third party libraries.

Rich components and Ajax
Ajax is an acronym for Asynchronous JavaScript and XML. It stands for a whole range of techniques that have the same goal: letting browsers perform server round-trips in the background so that web pages can be updated without doing a full reload. Wicket ships with a specialized Ajax engine designed to be used with Wicket’s server-side components and behaviors. It is designed to be as minimal as possible and thus isn’t as feature rich as some other Ajax engines. The engine is geared toward the following: message-handling between the client and the server, repainting and hiding components, executing custom JavaScript sent by Ajax responses, dynamically adding JavaScript and CSS to the page, providing the meanse to debug/track the engine’s workings, and throttling and timeout functionality. Wicket ships with quite a few high-level Ajax components, such as: AjaxLink, AjaxSubmitLink, AjaxSubmitButton, AjaxCheckBox, AjaxEditableLabel, and AutoCompleteTextField. Beside these components there are also Ajax behaviors. Ajax behaviors are created by extending AbstractAjaxBehavior. There are also some standard implementations that are shipped with wicket like: AjaxSelfUpdatingTimerBehavior, AjaxFormComponentUpdatingBehavior, AjaxFormSubmitBehavior and AjaxFormValidatingBehavior.
Contributing to the header section of pages is crucial for many components. This ability of individual components and behaviors to contribute to the page’s header is called a header contribution. One option to make a header contribution is by adding a HeaderContributor. Another option is by overriding the renderHead method in an Ajax behavior. The third option is to add the wicket:head tag to the markup.
If you want to use a third-party Ajax engine, you typically start by creating an abstract base class for that engine. That base class should extend AbstractAjaxBehavior. The minimal thing the base class then does is ensure that the proper JavaScript is contributed when the host component is rendered. You also want to be sure the common JavaScript is contributed only once for all behaviors that use the same engine, and you want to encapsulate these contributions so clients don’t have to know anything about them.

Part 4 Preparing for the real world
This final part of the book deals with some final aspects to get your application ready for the big, bad world that is out there.

Securing your application
With Wicket, if you don’t code using bookmarkable pages, you use session-relative pages. Page instances are kept on the server, and you ask Wicket (through your browser) for a certain page by providing the page number, the version, and the component that is the target of the request.
A good place to store authorization information is in the Wicket session object, because it’s available throughout the user’s session. Wicket creates sessions for users automatically. A simple form of authentication uses a sign-in page with a user name and password field in a form. It is good practice to have this form extend StatelessForm, so that the page doesn’t expire. The onSubmit method of the form should then handle the actual authentication.
Wicket uses authorization strategies to implement authorization as a cross-cutting concern. In order to create your own strategy, you have to implement IAuthorizationStrategy. One option of using such a strategy is by creating a base secured class that protected pages must extend. Another option is using annotations to mark the protected pages.
Finally the wicket-auth-roles and the WASP/SWARM projects are mentioned. Both are projects that have built standardized security mechanisms to support Wicket.

Conquer the world with l10n and i18n
Localization refers to the adaptation of your application for one or more specific locales. A related term is internationalization, which encompasses all techniques that enable applications to be localized: being able to conveniently maintain different languages, handling different date and number formats, using the proper encoding type, and so forth. For the sake of simplicity, the authors use only the term localization, even if it sometimes would be more precise to talk about internationalization. The most important aspects of localization are alphabets and scripts, and formats. To support multiple languages you can put all the locale-dependent parts in separate files and then using the wicket:message tag to look up those parts. The pattern for looking up these files is:

session = The current user session
component = The component that initiated the resource lookup
name = The name of the class of the component that is currently input for the search, starting with the name of component
style = [component.variation" "_" "[session.style" "_" "]]
ext = (”.properties” /”.xml”)
path = name["_"style["_" language["_" country]["_variant"]]]ext

Instead of using <wicket:message> tags, you could use normal Label components with a ResourceModel. Another option is to use localized markup files. The disadvantage of this however is that there will probably be a lot of duplication.
Wicket has a mechanism for handling objects that have different string representations depending on the locale. The objects responsible for such conversions in Wicket are called converters. Wicket’s default configuration is probably good for 95% of use cases. But the default configuration may be insufficient at times. If that is the case you can write a custom converter. This can be done by overriding the getConverter method in a field. Or you can create a converter locator that knows where to get converter instances for the appropriate types.

Multitiered architectures
This chapter gives an overview of how to set up Spring and Hibernate to create a multitiered architecture for your application.

Putting your application into production
Before you can put your application in production you have to test it, create a site map that is optimized for your users and search engines, and configure the application for production. Then finally you’ll want to keep an eye on it once it is in production.
In order to test you Wicket application you can use the WicketTester class combined with JUnit. This class has methods like startPage, assertLabel and onClick to test-drive the pages and components as if they were called during a normal request.
The regular session-relative requests aren’t very nice for your users, as they won’t be able to bookmark them. Search engines in particular can’t deal with them, which means that all the information in your application can’t be found. While that is sometimes a good thing, at other times it is not what you want. That is why they have provided the BookmarkablePageLink. This still doesn’t provide a URL that looks nice, but at least search engines can handle them. If you want a URL that looks nice as well, which is something that will help you score better in some search engines too, you will have to use mounting and URL encoding. Mounting is the process of converting the BookmarkablePageLink with a fully qualified classname into a specific path. Transforming something like:

http://cheesr.com/shop?wicket:bookmarkablePage=%3Acom.cheesr.shop.CheeseDetailsPage&cheese=edam

into something like:

http://cheesr.com/cheeses/cheese/edam/

By using URL encoding strategies, this can be optimized even further. Wicket provides several strategies like: QueryStringUrlEncodingStrategy, BookmarkablePageRequestTargetUrlCodingStrategy, IndexedParamUrlCodingStrategy, MixedParamUrlCodingStrategy, HybridUrlCodingStrategy and IndexedHybridUrlCodingStrategy.
Wicket applications can run in two modes: Development mode, which provides maximum developer support, and Deployment mode, which provides maximum performance and security for production. By default Wicket starts in development mode. Before going to production the mode should be switched, either through a system property, a servlet/filter-initialization parameter or a context-initialization parameter. All of the options that are turned off by switching to deployment mode, can be turned back on again in the Application’s init method. Another part of the configuration of an application that should be done before production is providing meaningful error pages. Wicket does provide default error pages, but these don’t look very nice, so you might want to customize them. Beside the error page, the access-denied page, the internal-error page and the page-expired error page can also be customized.
Once your application is running on your server and delivering pages to visitors, you need to ensure that the application keeps running. This means monitoring the application and, when things go wrong, figuring out what happened and how to fix it. The request logger provides this information, but it does have to be enabled and configured. Another feature that Wicket has is that through the Java Management Extendsions (JMX) it allows you to look inside a running server and adjust parameters on the fly, so you can change the markup files in production without restarting the application for example.

Conclusion
Wicket in Action is the perfect book if you want to get started with Wicket. It gently guides you past all the important concepts in Wicket and gives you tons of examples to play around with. It points you in the direction of all the most important components that you might need. The code of the examples is also provided on a site accompanying the book, so you won’t have to type it all yourself. It’s also a good book if you’ve already been playing with the framework for a little while and want to really understand what it is you’re working with.

I had heard a lot about Maven and it sounded like a nice addition to the toolbox of a developer and thus I decided to dive into the subject. I quickly found the book “Maven: The definitive guide” by Tim O’Brien, John Casey, Brian Fox, Bruce Snyder, Jason Van Zyl, and Eric Redmond. This review/summary is based on version 0.22. The book is still a living book, so it is still under construction. On their website: http://www.sonatype.com/books/maven-book/pdf/maven-definitive-guide.pdf there is already a version 0.5 (which is apparently a later version). In the next few pages I have attempted to summarize the book, to allow you to decide for yourself whether you think the book is worth your time. I must note however that in some places I have left stuff out, as the summary would get too long. This is specifically in the areas where the book went into great detail. So if you want to know anything specific about Maven, go ahead and have a look at the website and take a look at the index to see if your subject might not be treated after all.

Introducing Apache Maven

The first chapter describes that Maven is a project management tool that relies heavily on convention over configuration. This means that a lot of things about your project do not have to be specified, such as the location of the source code. However most of these default can be customized. All these defaults together offer a common interface to building software, where a user can install a certain piece of software with a two word comman (mvn install). And while the core of Maven doesn’t do very much beside parsin a few XML documents and keeping track of a lifecycle and a few plugins, it can be extended very easily with a lot of plugins. Each of these plugins can be downloaded from a remote repository, where they are maintained centrally, so you don’t have to continually upgrade Maven to get new functionality. Everything about your project is described in the project object model, the coordinates, the license, the developers, etcetera. This model enables features like dependency management, remote repositories, reuse of build logic, tool portability, and easy searching of artifacts.

Installing and Running Maven

The next chaptergives detailed instructions on how install Maven and verify that it works. The paragraphs here are all pretty short, seeing how it is relatively easy to do. There are instructions for different operating systems, and also for upgrading and even uninstalling Maven.

Part I. Maven by Example

After these two introductory chapters Maven is “introduced by doing”. The chapters in this part are a long string of examples showing exactly how to use Maven.

A Simple Maven Project

The first example shows how to create a simple project from scratch using the Maven Archetype plugin. Guided by this example they show the default Maven file structure and explain that the project object model (aka POM) is stored in the file named pom.xml. They also give the commands that you can use to build, package and install the software. And finally they explain some of the core concepts of Maven, like plugins and goals, the lifecycle, coordinates, repositories, dependency management and site generation and reporting.

Customizing a Maven Project

The second example is a weather project, which is used to show customization. Contrary to the first example, this example is dependent on some other projects, and so these dependencies are added to the POM. The project also has some resources that need to be added to the classpath. By putting these files in the right directory (src/main/resources), no further configuration is needed, as Maven picks them up automatically. Then the application should be tested, unit tests are made and again put in the right directory (src/test/java) so no configurations is needed for the tests to be found, as testing is part of the lifecycle. The tests that are written do have some dependencies, and so the test-scoped dependencies are explained. Tests can also have resources (src/test/resources). Packaging and installing incur testing, but the lifecycle can also be made to stop after the test phase by calling mvn test. Finally the assembly plugin is demonstrated to put together a distribution that can be deployed on a server.

A Simple Web Application

The third example shows how to configure a web application. First of all the packaging tag needs to contain the value war instead of the default jar. Then they add the jetty plugin, so the application doesn’t have to be manually deployed. Thirdly a servlet is added and configured (in web.xml). To get the servlet working the servlet api is added as a dependency.

A Multi-module Project

A multimodule project consists of a parent module and several submodules. The parent module contains mainly the parent POM that references the submodules. For the fourth example they combine the weather project and the web application of the previous two chapters. The parent POM states that the packaging type is POM, defines the modules that the project consists of, and defines some setting which will be inherited by all submodules. All the submodules get an extra definition of the parent module. While building a multi-module project, the order in which the submodules are listed in the parent POM is maintained unless changes need to be made. For instance if one of the modules is dependent on the other.

Multi-module Enterprise Project

In this chapter they give an example of a small multi-module enterprise project that shows what a larger real life project might look like. They integrate Hibernate and Spring to show how this might be done. A lot of the chapter is in fact not spent on Maven at all, which shows the simplicity of Maven.

Optimizing and Refactoring POMs

In the final chapter of part I, the authors have a look at what they are left with after the last example. The first step in cleaning up a multimodule project’s POM is looking for duplication. The first duplication that is encountered is in the dependencies. This is cleared up by moving these dependencies to the dependencyManagement section in the parent POM. Then the versions of these dependencies in the submodules are removed, as they would otherwise override the dependencyManagement. The next step is to put the versions of several related dependencies into a property, so that they will never differ. After that the sibling dependencies inside the project itself are resoled by using ${project.groupId} and ${project.version} to denote the communal groupId and version.
After the dependencies, the plugins are optimized. Most complex Maven multimodule projects ten to define all versions in the top level POM. Then there is the pluginManagement section where duplicate plugins can be defined. To find used dependencies that are undeclared, the Maven Dependency plugin can be used (mvn dependency:analyze). It can also be used to find unused, declared dependencies, but this is a little trickier due to for example scoped dependencies.

Part II. Maven Reference

In this part of the book the blanks are filled in and the authors really dig into the details.

The POM

A Maven project is defined by the presence of a pom.xml file. While most of the examples in the book are geared towards Java applications, there is nothing Java-specific in the definition of a Maven POM. A POM contains four categories of description and configuration: General project information (name, URL, developers, etc.), Build settings (the behavior of the default Maven build), Build environment (profiles that can be activated for use in different environments), and POM relationships (as a project rarely stands alone). All Maven POMs implicitly extend the Super POM which defines a set of defaults shared by all projects, including the central Maven repository, the default plugin repository, the directories in the Maven Standard Directory layout, and the default versions of the core plugins. As all these defaults are specified (and therefor inherited by every POM), the simplest POM contains only the coordinates of the project (groupId, artifactId and version). Since POMs can inherit configuration from other POMs, you must always think of a Maven POM in terms of combination of the Super POM, plus any parent POMs, and finally the current project’s POM, where the lower level overrides the higher level (the Super POM being the highest level).
The dependencies described in the POM can both be internal (your own projects) and external (3^rd party libraries) dependencies. Each dependency has one of five scopes: compile (default), provided (when the JDK or container provide them), runtime (required to execute and test, but not to compile), test (required for testing only) and system (native jars). Dependencies can also be declared optional, when you don’t want them showing up as transitive dependencies in the project depending on this project. This does have the consequence that they have to be included in the project that is depending on this one. Further more, it is also possible to specify a range of versions that would satisfy a given dependency. Very convenient when a certain functionality you need has been added to a specific version, but been discontinued in a later version. Transitive dependencies are dependencies of dependencies. In Maven1 you had to specify all of these explicitly, but Maven2 is able to sort these out on it’s own, by building a graph of dependencies and dealing with any conflicts and overlaps that might occur. When a conflict does occur, they can be solved by for example excluding certain transitive dependencies (explicitly) and replacing them by another dependency (implicitly). Finally the versions of the dependencies can be managed in the parent POM by dependencyManagement.

The Build Lifecycle

The Maven lifecycle is the mechanism that allows Maven to act upon the objects in the POM. Such a lifecycle consists of a sequence of named phases. There are three standard lifecycles in Maven: clean, default and site. The clean lifecycle is the simplest, it deletes the output of a build by deleting the build directory. It consists of 3 phases, pre-clean, clean and post-clean. The default lifecycle is also called the build lifecycle. It consists of 21 phases, starting with validate, running through compile, test and package and ending with deploy. The third lifecycle is the site lifecycle, which consists of the four phases pre-site, site, post-site and site-deploy. This cycle produces the project documentation and generates a site for it.
The specific goals bound to each phase default to a set of goals specific to a project’s packaging. A project with packaging jar has a different set of default goals from a project with a packaging of war, pom, plugin, ejb or ear. But there are a lot of similar goals in many of the packaging lifecycles. Most of the lifecycles have goals for managing resources, running tests, and compiling source code.

Build Profiles

Profiles allow for the ability to customize a particular build for a particular environment; profiles enable portability between different build environments. Portability is a measure of how easy it is take a particular project and build it in different environments. A Maven profile is an alternative set of configuration which set or override default values. You can even conditionally activate a profile, if the decision whether to use it or not depends on some system variable, like the presence of a Java 6 compiler. As Maven profiles can be defined in a variety of sources there is no good way to keep track of shich profiles are available. Therefor the Maven Help plugin defines a goal, active-profiles, which lists all the active profiles and where they have been defined.

Maven Assemblies

Sometimes you’ll need to create an archive or directory with a custom layout. Such custom archive are called Maven Assemblies. They can be made with the Assembly plugin. With this plugin you can create your own archive recipe, called assembly descriptor, but there are also several built-in descriptors, such as bin, jar-with-dependencies, project, and src.

Properties and Resource Filtering

Properties are a convenient method of keeping your projects consistent. Maven has some implicit properties that are available in any project: project.* (used to reference values in a POM), settings.* (used to reference values from your Maven Settings), env.* (used to reference environment variables), and System Properties (used to reference any property that can be retrieved from the System.getProperty() method). In addition to these implicit properties there is also a set of arbitrary, user-defined properties.
In addition to these defintions, you can also use resource filtering to perform variable replacement on project resources. This feature has to be enabled first. This feature combines nicely with profiles, for example to reference an external resource such as a database for different systems.

Maven and Eclipse: m2eclipse

This chapter is replaced by an entire book: http://www.sonatype.com/books/m2eclipse-book/reference/

Site Generation

Maven can be used to create a project web site to capture information which is relevant to both the end-user and the developer audience. The most simple POM would generate a website that is mostly empty and not very useful. In order to fix this problem the site descriptor will have to be customized. You can easily alter for example the default menu and the logo of the site. All the files for the site should be placed under src/site, where there are different directories for different file formats like APT, FML and XDoc. Maven uses a documentation-processing engine called Doxia which reads multiple source formats into a common document model. To write document for your project, you will need to write your content in a format which can be parsed by Doxia, like the aforementioned APT, FML and XDoc. To deploy your site you’ll use the Maven Site plugin which can take care of deploying your project’s site to a remote server using a number of methods including FTP, SCP, and DAV.
The easiest way to affect the look and feel of your project’s web site is through the project’s site.css file (under src/site/resources). To change the page structure that is rendered by default, we can configure the site plugin in our POM to use a custom page template.

Repository Management with Nexus

This chapter is replaced by an entire book: http://www.sonatype.com/books/nexus-book/reference/

Writing Plugins

99 out of 100 Maven users will never need to write a custom plugin to customize Maven; there is an abundance of configurable plugins, and unless your project has particularly unique requirements, you will have to work to find a reason to write a new plugin. A Maven Plugin is a Maven artifact which contains a plugin descriptor and one or more Mojos. A Mojo can be thought of as a goal in Maven, and every goal corresponds to a Mojo. A Maven plugin contains a road-map for Maven that tells Maven about the various Mojos and plugin configuration, called a plugin descriptor. When you are writing custom Maven plugins, you will almost never need to think about writing a plugin descriptor. The lifecycle goals bound to the maven-plugin packaging type show that the plugin:descriptor goal is bound to the generate-resources phase. This goal generates a plugin descriptor off of the annotations present in a plugin’s source code. There are three parts to a plugin descriptor: the top-level configuration of the plugin which contains elements like groupId and artifactId, the declaration of mojos, and the declaration of dependencies.

Writing Plugins in Alternative Languages

Mojos can be written in Java, or in an alternative language. Maven has support for a number of implementation languages, and this chapter shows how to create plugins in three languages: Groovy, Ant, and Ruby.

Using Maven Archetypes

An archetype is a template for a Maven project which is used by the Maven Archetype plugin to create new projects. Archetypes are useful for open source projects such as Apache Wicket or Apache Cocoon which want to present end-users with a set of baseline projects that can be used as a foundation for new applications. Archetypes can also be useful within an organization that wants to encourage standards across a series of similar and related projects. Archetypes can be used by invoking the generate goal of the Archetype plugin via the command-line or with m2eclipse. There are already many archetypes out there, including the default Maven archetypes for creating a simple project with JAR packaging and a single dependency on JUnit, a web application, and a mojo. Then there are a lot of third-party archetypes, like AppFuse, Confluence and JIRA, and Wicket.

Conclusion

All in all, it is a very comprehensive book that is well worth your time to read it. The first part is perfect for beginners as it guides you gently into the Maven domain. The second part is perfect for the more advanced user who wants to know the details on some subject.

Keynote – Agile@Atlassian – How do we do it?

Good keynote by Sherali Karimov that not only told how Atlassian employs agility, but also gave some pointers on how to implement it in your own company. (Unfortunately I can’t find any slides, but their website seems to offer some of the same content.)

Het modelleren van een canoniek datamodel mbv XML Schema (Modelling a canonical data model using XML Schema)

Dutch presentation by Linda Terlouw about what a canonical data model is and how to implement it with XML Schema. In short a canonical data model is a shared data format for exchanging data between services. It is meant to prevent the rise of lots of translations between all the individual data formats, allowing you to only need to translate your own data to the canonical format. We were also warned that a canonical data model, which models only what is necessary to share information, isn’t the same as a corporate data model, which models all information in the company. A distinction was made between hierarchical and relational models, and it was explained how XML Schema supported both of these options, along with all the pros and cons.

Geef je code wat liefde (Give your code some love)

Dutch presentation by Rob Westgeest and Willem van den Ende from QWAN about how code becomes more maintainable if you give it some love by refactoring. The bottom line is that with small refactorings in the order of ten minutes work, can save you the five minutes you need to read a method. (Which you would need to do again and again.) Presentations by QWAN are always highly entertaining and informative.

Keynote – Mod4j: Open Source Modelling for Java Developers

Another good keynote that introduced Mod4j, presented by Jos Warmer. I was almost surprised to hear that a partner at Ordina still got his hands dirty on code. So it was the right kind of sales pitch, and for an open source product too! Mod4j stands for Modeling for Java, and it is an open source DSL-based environment for developing administrative enterprise applications. (Again there were unfortunately no slides, so I had to take that quote off their website.) At the time of speaking the product wasn’t finished yet, as they weren’t offering all the functionality they wanted, but they had a working version and it looked cool.

Software Quality Automatically Measured

Nice presentation by Gert-Jan Schouten about a cool Maven2 plugin to measure quality and express it with a number. Too bad about the small font of the slides. And the code that was shown was completely illegible due to the small font. But the worst letdown was that the code that was shown wasn’t open source or even for sale. Fortunately somebody from the audience mentioned Sonar, which does more or less the same.

Pragmatic model driven development in Java with smart use cases and domain driven design

This presentation by Sander Hoogendoorn and Rody Middelkoop was slightly too slick for my taste. But as I say, it’s a matter of taste, I bet lots of other people loved it for the exact same reason. In fact, the presentation went so fast, that even with the slides, I can’t quite figure out all that was said.

–

I skipped the last session, as I was pretty tired and didn’t see anything that I thought could hold my attention during this last track. Instead I sat on the lounge chairs on the first floor and talked with some people until they opened the bar. (And kept right on talking afterwards as well of course.)

Dinner

It’s become quite a tradition already that the ladies of Duchess have dinner afterwards, and so seven Duchesses, Diane Etman from VXCompany and two men (since we now allow each woman to bring one male guest) headed off towards ‘de 3 Vrienden’ in the city center. There we met up with the third man, since he had misrembered the time and was already there enjoying the sunshine. VXCompany was very gracious to sponsor the food, so we only had to pay for our drinks. After our first dish we all scooted over three seats so we could talk to more people than just those who were sitting close in the first place. All in all a very successful ending to a great day.

From the NL-JUG newsletter:

In het IT-landschap anno 2009 kunnen we eigenlijk niet meer om Cloud Computing heen. Het is te gemakkelijk om Cloud Computing af te doen als een hype, al was het alleen maar om de lange aanlooptijd en de mate waarin Cloud Computing inmiddels al wordt toegepast. Nu is de definitie van Cloud computing snel genoeg gevonden. Maar wat betekent Cloud Computing in de praktijk? Met name in de praktijk van Java-ontwikkelaars en -architecten?

Tijdens het Profict Java Spring Camp 2009 proberen we antwoord te geven op die vraag. Aan de hand van twee praktijkimplementaties geven we je een idee van wat je nu al kunt doen met Cloud Computing als Java-ontwikkelaar of -architect. Zoals gebruikelijk doen we dat in de inspirerende omgeving van een van onze kantoorlocaties. Ditmaal in ’s Graveland bij Hilversum, op vrijdag 19 juni vanaf 13:00. Na afloop is er de traditionele barbecue, waar bezoekers en sprekers informeel verder kunnen praten onder het genot van een smakelijk hapje. Jij kunt hierbij zijn. DEELNAME IS GEHEEL GRATIS!

Sprekers

Jerome Bernard heeft ruime ervaring met het ontwikkelen van gedistribueerde systemen en is committer op diverse open source projecten. Momenteel werkt hij aan Elastic Grid, een open source project dat Java-ontwikkelaars in staat stelt hun applicatie implementatie-onafhankelijk aan de cloud te koppelen. Het maakt dus voor de applicatie niet uit of er een openbare cloud (zoals Amazon EC2) of een private cloud gebruikt wordt. Tijdens zijn presentatie vertelt Bernard (en demonstreert hij) hoe je je Java-applicaties kunt deployen, beheren en scalen op de cloud met Elastic Grid.

Jeroen Remmerswaal werkt voor GigaSpaces. GigaSpaces biedt een middleware-platform (eXtreme Application Platform, XAP) waarmee low-latency, zeer betrouwbare en schaalbare applicaties gemaakt kunnen worden, of waarmee betrouwbaarheids- of performanceboosts gegeven kunnen worden aan bestaande applicaties. Door gebruik te maken van virtuele omgevingen zoals grids en clouds komen de dynamische en elastische aspecten van beide zeer goed tot zijn recht. GigaSpaces ondersteunt zowel public clouds (zoals Amazon EC2, RightScale en GoGrid) als private clouds. In zijn presentatie vertelt Remmerswaal meer over GigaSpaces en XAP, en laat hij zien hoe het in de praktijk werkt.

Benoît Chesneau is een Franse webambachtsman. Hij heeft jarenlange ervaring met het bouwen van zowel klein- als grootschalige databasegedreven webapplicaties en is oprichter van Enki Multimedia, een bedrijf dat innovatieve web services en open source applicaties ontwikkelt. In zijn presentatie zal Chesnau kijken naar CouchDB, een gedistribueerde, fouttolerante en schemaloze documentgeoriënteerde database die via een RESTful HTTP/JSON-API te benaderen is. Het ontwerp en de replicatiefeatures van CouchDB lossen het probleem van drukbezochte websites en gedistribueerde peer-to-peer- en offline-applicaties op, allemaal tegelijk. Hij zal laten zien wat voor applicatie er in Java of andere talen met CouchDB gebouwd kan worden en hoe CouchDB kan helpen informatiesystemen schaalbaar en fouttolerant te maken. Er zal een live demonstratie worden gegeven van de administratieomgeving en van het gebruiken van CouchDB, zowel met de REST-interface als via CouchApps.

Schrijf je nu in op http://www.javaspringcamp.nl.
Wees er snel bij, want het aantal plaatsen is beperkt.

Waar/wanneer

Het adres waar we je op vrijdag 19 juni a.s. vanaf 13:00 graag verwelkomen is:
Noordereinde 56
1243 JJ ’s Graveland (Hilversum)

Je kunt parkeren op het parkeerterrein van Natuurmonumenten (aangegeven door vlaggen), Noordereinde 52.
Zie deze Google map voor de locatie en een aanduiding waar je kunt parkeren.

Programma

13:00 Aanvang
13:30 Jerome Bernard
15:30 Benoît Chesnau
17:00 Jeroen Remmerswaal
18:30 Barbecue

Dit is het voorlopige programma. Kijk voor updates op de website.

Tot 19 juni,
Het Profict Java Spring Camp organisatieteam

From the NL-JUG newsletter:

De Java community is rijk aan webframeworks. Elk jaar duiken er een aantal nieuwe, veelbelovende frameworks op. IPROFS organiseert een openbare kennissessie omtrent twee frameworks die steeds meer in de belangstelling staan: Wicket en Lift.

Wicket probeert de impedance mismatch tussen stateless HTTP en een statefull GUI op te lossen door de componenten structuur en eventhandling van een desktop framework als Swing na te bootsen.
Lift is een webframework voor Scala (de opvolger van Java?) dat voortbouwt op inzichten uit Rails, Wicket en Django.

Programma

18.00 uur Ontvangst en eten

19.00 uur Wicket door Frank van Westerop
Naast een live demo wordt tijdens deze presentatie de Wicket aanpak en architectuur bekeken: containers, componenten en event delegation, Spring integratie en meer.
Wat zijn de sterke punten? Zijn er ook nadelen?

20.00 uur Pauze

20.15 uur Lift door Peter van Rijn
In deze presentatie zal er in een live demo een applicatie voor een boekwinkel
gebouwd worden. Als Lift echt zo goed is, zal het zich in deze praktijksessie moeten
bewijzen!

21.15 uur Afsluiting met aansluitend borrel

IPROFS is volledig gespecialiseerd in het ontwikkelen van schaalbare, enterprise Java EE oplossingen. Aan de CMS/Portal kant zijn wij gespecialiseerd in Hippo. Onze missie is om het beste Java huis van Nederland te zijn, in alle fasen van een project. Alles wat wij doen staat in het teken van Kwaliteit, Passie en Warmte.

Na deze interessante avond ben je weer helemaal op de hoogte van deze onderwerpen. Je kunt je hiervoor kosteloos opgeven tot en met 7 juni 2009 door een e-mail te sturen met jouw naam, het bedrijf, jouw functie en telefoonnummer naar events@iprofs.nl.
Binnen een week sturen wij jou de bevestiging van jouw aanmelding.

LOCATIE
Gebouw “De Houthof”
Claus Sluterweg 125
2012 WS Haarlem
+31 (0)23 547 63 69