Development Roadmap

Last updated: 2024-04-04

We're excited to share a (rough) road map for 2024 of upcoming development and an overall strategy for the project!

There are no deadlines attached, as we don't want to make any explicit commitments if we might not able to keep them due to our available resources.

Nevertheless, the road map paints a particular picture of the current state of development and what to expect in the future. And it's an invitation to discuss these features, ideas, and the general direction.

(IN PROGRESS) Jakarta EE

We hear you that this is the most pressing issue, and work is underway to make this our next big release. Instead of a hard breaking change for everyone, we decided to support both Java EE and Jakarta EE in the form of two branches:

  • The master branch becomes the Jakarta EE-compatible one
  • A new branch called javax was started from 5.8.4 to keep supporting Java EE

For the foreseeable future, we will implement any new features, bug fixes, security-related updates, etc., in both branches so you can enjoy Tapestry improvements regardless of your Servlet needs.

One breaking change we're going to introduce (besides the Servlet API itself) is the minimum required Java version going up to 11.

Many Servlet containers, like Jetty or Tomcat, require at least Java 11, although Jakarta EE 9 can be run on Java 8. Our own tapestry-runner is based on Jetty, so we'd need to develop a new one based on another container to make Java 8 work for development. To avoid stretching our resources too thin, we decided to increase the required minimum Java version instead, as the Java EE variant is still available for Java 8 and will be developed alongside the Jakarta EE variant.

(IN PROGRESS) Website/Documentation updates

The website and documentation are in dire need of some updates.

With two actively developed branches, we want to provide a multi-version documentation system, so it's easier to discern how to use features with your version, and what might be outdated, etc..

Therefore, we're going to move the documentation to the Git-based tool Antora. It supports documentation for multiple versions, and thanks to its Git-based approach, it will be easier for people to contribute, provide changes, and more, through pull requests.

(PLANNED) Making contributions more accessible

Every open-source project needs contributions.

Right now, our resources are pretty sparse, but we see a lot of awesome people from the community wanting to contribute, like the latest PR that started the Jakarta EE work.

Still, the initial hurdle to take to participate needs to be lower, especially since Apache restricted public signups for their JIRA.

That's why we plan to move more towards GitHub, as it's the de facto standard for most open-source projects. GH issues are easier to participate in than Apache Jira and are better integrated into pull requests and discussions.

The move isn't supposed to replace the mailing lists, but complement them. In the long run, Jira might be replaced with GH issues, as maintaining two issues trackers and keeping them in sync requires a lot of additional work.

(PLANNED) Community Projects

The Tapestry framework comes with many "batteries included", which is one of its strengths. However, keeping all the different parts up-to-date requires a lot of work, too.

That's why we're planning to move a few of the tapestry-* projects into a yet-to-be-created "community projects" organization on GitHub.

For example, tapestry-mongodb is a severely outdated dependency. There's an argument to remove it in a future version, but we prefer not to remove any feature without the absolute necessity to do so. Instead, certain projects will live on separately from the main project. That doesn't mean we don't want to update at all. However, their priority will be lower than any project in the primary repository.

On the other hand, we plan to support certain third-party projects and try to bring them into the fold of the community projects. This way, such essential projects will receive quicker updates and be easier to discover.

(PLANNED) Updating Guides

There are multiple guides available on the project's website, and they need updating. Especially the contribution/development guides should always be up-to-date and as simple as possible, to encourage more participation.

Some of the required steps to set up a project might be replaced by improving the Gradle scripts to make it even easier.