Apache Wicket: a component framework where Java code and HTML stay separated

The pitch in one paragraph

Apache Wicket is an open source, Java, component based web application framework. With proper markup and logic separation, a POJO data model and a refreshing lack of XML, the project claims it makes developing web apps simple and enjoyable again, and the argument is to swap the boilerplate, complex debugging and brittle code for reusable components written with plain Java and HTML.

That is a real design position rather than a slogan. The two halves are the component model, where a page is a Java object with a model and a markup file, and the separation, where the HTML lives in its own file and the Java lives in the class. The POJO data model means your domain objects are not wrapped in framework-specific types.

The licensing is the Apache Software Foundation licence, version 2.0, the homepage is wicket.apache.org, and the last push to the repository was on 2026-10-21. The repository has no GitHub releases, and the project keeps a CHANGELOG-10.x file, a release.sh script, a build-versions.py script and a build-changelog.sh script at the top level, which is the shape of a project that cuts releases through its own tooling rather than through a tag and a publish action.

The repository also carries AGENTS.md, CLAUDE.md and JAVASCRIPTTESTING.md, which is a mix of Apache governance files and modern working notes.

The learning resources the project points at

The getting started section lists four resources, and the choice of four tells you what the project considers the learning problem to be.

The Wicket user guide is the primary resource, described as learning Wicket from scratch with a gradual introduction to the features and many real world examples. The JavaDoc is the API reference on the project site. The examples project shows all components in short usage examples, and it is also available live on a hosted site. The Wicket Quickstart provides a skeleton project for use in NetBeans, Eclipse, IntelliJ IDEA and other major IDEs without having to configure anything yourself, since you copy and paste a generated command line and Maven does the job.

The quickstart point is worth emphasising for anyone evaluating a Java framework today. The claim is that the entry cost is a copy and paste, and that is a real difference from the frameworks whose first hour is spent on configuration files.

The examples site being live rather than only in the repository matters too, because a component library is best learned by reading small pieces of code that run, and the alternative is a static documentation page.

One more artefact sits alongside the guide, and it is the thing that most distinguishes Wicket from other frameworks. The source distribution contains the source code and the jars of the core projects, and if you are just starting out you probably only need wicket-util, wicket-request and wicket-core, where x stands for the version. The rule given is to use just the jars you need.

Two dozen modules, and what each one is for

The source tree listing in the README is effectively the module catalogue, and it is long. The core project is wicket-core, which includes the framework and the basic components. wicket-request is a lightweight project containing all the classes dealing with request handlers. wicket-util is the utility project.

The testing story is three modules. wicket-tester contains common classes for unit testing, wicket-core-tests contains the test cases for the core module, and wicket-extensions-tester is the equivalent for the extensions.

The integrations are where the optional dependencies live. wicket-spring supports using Spring with Wicket and including Spring managed dependencies through @SpringBean annotations, and wicket-guice does the same for Google Guice. wicket-ioc is the base project for IoC implementations that those two build on, and it is the module that pulls in byte-buddy and asm-util. wicket-cdi provides the context and dependency injection of the JEE standard, and wicket-cdi-tests is its test project.

Then there is the list of features that are extensions rather than integrations. wicket-auth-roles is a basic authorization package based on roles. wicket-jmx registers JMX beans for managing things like the Wicket configuration and the markup cache. wicket-bean-validation validates beans with annotations based on javax.validation. wicket-native-websocket is the native web sockets integration for several servers. wicket-metrics collects data from a running Wicket application, and wicket-http2 is http/2 push support. wicket-velocity renders Velocity templates using Wicket components, and wicket-devutils provides small utilities for the development and debugging phase. wicket-objectssizeof-agent helps make better estimates of object sizes in the JVM, and the README notes most people probably never need it.

The interesting part of that list is the direction of travel. The experimental module holds experimental implementations, and the migration module exists for moving between versions, which tells you a Wicket application has a real upgrade story rather than a rewrite story.

Dependencies without Maven, and the SLF4J trap

The dependencies section starts with the easy path. The easiest way of getting the dependencies right is to use Apache Maven with the wicket dependencies you want as outlined in the wicket-quickstart, and Maven takes care of including the appropriate dependencies. The complete and precise reference is the wicket-parent pom.xml in the root folder.

The manual route is spelled out for the case where you do not want to use Maven.

For wicket and wicket-extensions you need the Jakarta Servlet API version 5, and just for compiling, the SLF4J API, and the SLF4J logging implementation you want. The README is emphatic about one point: you cannot use Wicket without adding an SLF4J logging implementation to your classpath.

That is a small warning that saves an afternoon, because a framework that refuses to start without a logging backend you did not install is a bad first experience, and the failure is not always obvious about what is missing.

The rest of the manual dependencies follow the module structure. wicket-velocity needs Apache Velocity 1.7 and its dependencies, and it ships a velocity-deps jar for convenience. wicket-ioc needs byte-buddy 1.11.12 and asm-util 9.1. wicket-spring needs wicket-ioc plus Spring and its dependencies. wicket-guice needs Google Guice. wicket-cdi needs Component Dependency Injection 2.0. And wicket-examples needs all of the above.

That structure is the practical argument for using Maven. Every optional module adds a transitive dependency tree that the framework does not have to carry itself, and the manual list is a reminder of how many combinations are possible.

Building from source and the shape of the distribution

The building section explains that the source distribution, the download package mentioned above, contains the binaries, jar files, for each of its modules or subprojects, and that you can use these directly in your applications. The project uploads the source and the JavaDoc artifacts from the same place.

The distribution layout is the classic Apache source tree:

	|-- apidocs
	|-- lib
	|-- licenses
	`-- src

Under src sit the module directories, the archetypes, the testing directory and the module subprojects themselves.

The archetypes directory matters for anyone who wants to create a new project rather than only use Wicket, since a Maven archetype is what the quickstart command generates. The testing directory and the wicket-benchmarks directory are also present, and the presence of a benchmarks module alongside a coverage module suggests the project pays some attention to its own performance numbers and test coverage.

The repository is a multi-module Maven build with a root pom.xml and a wicket-assembly-all.xml for the aggregate distribution, plus a.asf.yaml file which is the Apache Software Foundation's own project metadata. There are also a licenses directory, a NOTICE file and a SECURITY.md, which are the standard ASF governance files, and a CODEOWNERS-style pattern of a per-directory ownership scheme.

The last push to the repository was on 2026-10-21, so the framework is actively worked on, and the CHANGELOG-10.x file tells you the current line is the 10.x series.

Where Apache Wicket is the wrong choice

The first limitation is the one the framework's own design creates. Wicket owns the markup, so your HTML is a template inside a component rather than a file you own end to end. That is the point of the design and it is also the constraint: a team whose designers work in standalone HTML files, with a front end developer owning the markup, will find the separation of concerns runs the other way from what they expect.

The second is the size of the commitment. This is a large framework with two dozen modules, a large user guide, and a model where the abstractions are specific to Wicket. Moving to it is a migration, not an experiment, and the migration module in the source tree is a reminder that upgrades also have a cost.

The third is the ecosystem question, which is a judgement about a Java web framework in 2026. The alternative is to build on Spring, where the components come from a much wider pool of libraries, or on a modern JavaScript framework with a Java API layer, or on Quarkus or Micronaut for the reactive or native side. Wicket's counter-argument is exactly what its README says, that a component model with a POJO data model and no XML gives you plain Java objects and simple debugging, and for a long-lived internal application maintained by a small team that argument holds. For a greenfield product where hiring and library availability dominate, it is a harder sell.

The honest comparison is with other server-side Java frameworks that keep state on the server, such as other server-side stateful component frameworks. The differentiator is the maturity of the documentation and the examples, and the size of the community that has read it.

Editorial conclusion

Apache Wicket fits a Java team that wants a server-side component model with real Java objects behind the interface, and that is prepared to learn a framework whose abstractions differ from Spring MVC or Struts. It does not fit a team that wants to hand-write HTML files, since Wicket owns the markup, and it does not fit a project that needs the ecosystem around a newer stack. Before adopting it, read the user guide rather than the README, since the README is a directory listing rather than a guide, and plan for the fact that the framework and its modules version together, so upgrading the framework means reviewing the extension modules as well.

Frequently asked questions

Official sources

1. apache/wicket on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README