XDEV has decided to end the active development of RapidClipse and transition the product into a structured end-of-life phase. This does not mean that applications built with RapidClipse will be shut down or need to be replaced at short notice. Existing projects and applications can generally continue to be operated and developed.
We want companies to be able to protect their existing investment in RapidClipse applications. That is why XDEV supports existing users in assessing, stabilizing, further developing, and potentially modernizing their projects.
What Does End of Life Mean for RapidClipse?
Starting July 1, 2026, RapidClipse will no longer be actively developed as a standalone product. No new features or regular product releases will be published.
The most recently available version will remain usable. The RapidClipse framework and other publicly available components will remain available in accordance with their respective license terms. Existing applications are not directly affected by the end of product development. They will not be disabled and will not automatically stop working. However, future changes to Java, Eclipse, Vaadin, operating systems, browsers, or other dependencies may require adjustments. Long-term compatibility with future versions of these technologies cannot be guaranteed after the end of the maintenance phase.
Your Investment Remains Protected
RapidClipse applications are based on Java and established technologies such as Vaadin, Hibernate, and Maven. The RapidClipse framework is available as open-source software. This provides a solid foundation for continuing to maintain and evolve applications even without active development of the RapidClipse IDE.
Depending on the project, different paths may make sense:
- Continued operation in a stable and documented environment
- Technical stabilization and updates to important dependencies
- Further development without the visual RapidClipse GUI builder
- Gradual replacement of individual RapidClipse components
- Migration to a current Java and Vaadin architecture
- Full modernization of the application
An immediate migration is not necessary in every case. The key factors are the technical condition, the planned period of use, and the future requirements of the individual project.
XDEV Supports You with the Next Steps
As the creator of RapidClipse, XDEV has in-depth knowledge of the architecture, tools, and typical challenges of existing RapidClipse projects. We can support you with:
Technical Assessment
We analyze your application, the RapidClipse version in use, libraries, Java versions, interfaces, and the current maintenance status.
Stabilization and Continued Operation
We help secure a reliable development and operating environment, document dependencies, and reduce technical risks.
Maintenance and Further Development
Our Java and Vaadin team can take over existing RapidClipse applications, fix issues, and implement new functionality.
Migration and Modernization
If technical modernization makes sense, we work with you to develop a realistic, step-by-step migration strategy. Existing applications do not necessarily need to be completely rebuilt from scratch.
Knowledge Transfer
We support internal development teams in taking ownership of existing applications and maintaining them independently in the future.
Let Us Assess Your Project – No Obligation
Every RapidClipse project is different. That is why there is no one-size-fits-all recommendation on whether an application should continue running unchanged, be stabilized, or be modernized. In an initial, no-obligation consultation, we will take a look at:
- the current technical state of the application,
- potential risks,
- the planned lifespan of the system,
- and realistic next steps.
Can I continue using RapidClipse?
Will my existing application continue to work?
Do I need to migrate my application immediately?
Can I continue developing my application without RapidClipse?
Will the RapidClipse Framework remain available?
What will happen to the documentation and downloads?
What will happen to existing support agreements?
Will XDEV continue to provide support?
Yes. XDEV will continue to offer technical consulting, project support, maintenance, further development, and modernization for existing RapidClipse applications. Going forward, this will no longer be general development of the RapidClipse product, but individual support for specific customer projects.
How much does an analysis or migration cost?
How can I keep my project up to date and secure?
RapidClipse applications are usually based on a wide range of open-source libraries and frameworks. Even if an application continues to run reliably, its dependencies should not remain unchecked indefinitely.
New security vulnerabilities are discovered regularly. This means that an application considered secure today may contain known vulnerabilities tomorrow — even if your own source code has not changed.
We therefore recommend checking the dependencies used in your project regularly with the OWASP Dependency-Check Maven plugin. The tool analyzes the libraries used in the project and reports known vulnerabilities that have been publicly documented.
Please note: such a scan is only one part of application security. A successful scan result does not automatically mean that an application is secure. Your own application code, configuration, authentication and authorization concepts, infrastructure, and operating environment are not fully assessed by this scan.
Step 1: Integrate OWASP Dependency-Check into the project
Add the following plugin to your pom.xml:
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>${owasp.version}</version>
<configuration>
<nvdApiKeyEnvironmentVariable>NVD_API_KEY</nvdApiKeyEnvironmentVariable>
<failBuildOnCVSS>7</failBuildOnCVSS>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Make sure that ${owasp.version} refers to a current and supported version of OWASP Dependency-Check.
The failBuildOnCVSS value defines the vulnerability severity at which the Maven build should fail. With a value of 7, the build is stopped as soon as a high-severity vulnerability is detected.
You can adjust this value according to your security requirements. Lower values result in stricter evaluation.
Step 2: Request an NVD API Key
OWASP Dependency-Check obtains vulnerability information from the National Vulnerability Database (NVD).
You can request a free API key here: https://nvd.nist.gov/developers/request-an-api-key
Using an API key is strongly recommended. Without one, the scan may be significantly slower and subject to stricter access limits.
Do not store the key directly in your pom.xml and do not commit it to your source code repository. Instead, use an environment variable named NVD_API_KEY or a protected secret in your CI/CD system.
For Linux or macOS:
export NVD_API_KEY="your-api-key"
For Windows PowerShell:
$env:NVD_API_KEY="your-api-key"
Step 3: Run the Scan
Run the following command:
mvn dependency-check:check
Because the plugin is integrated into the Maven build, the check can also be run as part of the regular build process:
mvn verify
The first run may take a little longer because the vulnerability database needs to be downloaded and processed first.
Step 4: Review the Report
After the scan, an HTML report is generated in the target directory:
target/dependency-check-report.html
In Maven multi-module projects, each module may generate its own report. If desired, the aggregate goal can be used to create a combined report for the entire project.
Do not evaluate the results based solely on the CVSS score. For each reported vulnerability, check:
- Is the affected library actually used?
- Is the vulnerable functionality reachable?
- Is a patched version already available?
- Is the library still actively maintained?
- Are additional mitigation measures required?
In most cases, the solution is to update the affected dependency, the parent project, or the Bill of Materials (BOM) that manages its version. After every update, rebuild and thoroughly test the application.
False positives are possible. Suppress a finding only after it has been reviewed and documented. A suppression should never be used solely to make the build pass.
Step 5: Make Dependency Checks Part of Your Regular Process
A one-time scan is not enough. New vulnerabilities can be published at any time.
We therefore recommend:
- integrating OWASP Dependency-Check into every CI/CD build
- running an automated scan at least once a week
- regularly checking available updates
- documenting direct and transitive dependencies
- replacing libraries that are no longer maintained
- keeping the Java runtime and operating environment up to date
In addition, components outside the Maven project should also be reviewed regularly, including:
- the JDK
- the application server
- the database
- the operating system
- web servers and reverse proxies
- container base images
- JavaScript libraries
- build and deployment infrastructure
A stable application is not automatically a secure application. Security requires continuous monitoring, timely updates, regular testing, and a clear understanding of all components used.
If you are unsure which dependencies require special attention or whether an update can be applied safely, we will be happy to support you in analyzing your RapidClipse project and creating a practical security and modernization plan.
Thank You to Our Users and the Community
RapidClipse has been used and supported for many years by companies, developers, and an engaged community. We would like to thank you for your trust, your feedback, and the many projects built with RapidClipse. Even though active product development is coming to an end, we remain connected to the companies and people behind these projects. Our goal is a responsible transition that protects existing applications and opens up realistic paths for their future.