Wicket (vs. Tapestry)

Wicket, as with Tapestry, is a view technology that uses plain HTML and Java code to render web sites. However where with Tapestry you have the controlling logic split between the Java code and html/page files, Wicket thrusts all logic into the Java code and use the html pages only to define the position of its components.

In addition, there is no xml configuration needed aside from the inclusion of the Wicket servlet into the web application. Any configuration is done in Java code. As such the components in Wicket can be reused and also inherit from other components, normal Java behaviour.

After trying Wicket for a few days, it is very much easier to use than Tapestry. The split logic in Tapestry forces one to constantly refer to the html pages for what components are used and their settings and the Java for the logic behaviour. Keeping all the logic in Java enables one to have a clearer picture on what the components are and what they do, and the html pages only need their wicket ids to function.

Another thing is the strict enforcement of wicket ids referencing their respective components. If one has a wicket id that is not referencing a component somewhere in the Java code, the webapp cannot render it and gives an error page. Similarly for a component that tries to add itself to a page without an id.

Shifting from Tapestry, one had to change their coding mindset from a single Java file for a html page. Wicket also requires that, however a base page can be defined and, taking advantage of inheritance, be extended by other pages. Components in one page can be reused in another and so on.

Maven

http://maven.apache.org/

Maven can be run straight out of the archive, once the systempath variables are set. Following the 5 minutes guide, I created a 'Hello World' app, compiled, tested and finally packaged it into a jar. Going further, using 'mvn eclipse:eclipse' allowed it to be imported into the Eclipse IDE. There is also a plugin available for tight integration between Maven and Eclipse.

Dependency management is one prime reason for using Maven. The dependencies are downloaded from a remote repository and stored in a local repository that Maven creates. So for several projects, there will be only be one dependency copy. The default remote repository can be changed to an internal repository that will house a private copy of dependencies.

In regards to Ant, Maven makes for a more standardized build process, with little or no configuration needed to start creating, building and testing projects. It provides a common directory layout for each Maven project, easing orientation.