Veripacks already allows to specify and verify which classes should be visible outside of a package (in a package-transitive way) as well as require importing and import packages within a project. This makes it possible to eliminate some build modules, while still keeping their strict isolation (which can be checked…
Category: specification
How to replace a build module with Veripacks
Compare the two trees below. In both cases the goal is to have an application with two independent modules (frontend and reporting), and one shared/common module (domain). The code in frontend shouldn’t be able to access code in reporting, and vice versa. Both modules can use the domain code. Ideally,…
Veripacks 0.3: importing packages (transitively, of course)
Previous versions of Veripacks focused on defining what classes are visible outside of a package hierarchy (exporting). This release focuses on defining what classes can be used inside a package hierarchy (importing). By default, no imports are required. As long as a class is visible (exported), it can be used….
Veripacks 0.2: exporting subpackages
Veripacks 0.1 allowed to specify which classes should be exported from a package hierarchy, by using a simple @Export annotation, and later verify that the specification is met. Version 0.2 extends this by allowing to export subpackages as well, using the @ExportSubpackages package annotation. When exporting a subpackage, only the…
Veripacks 0.1 – Verify Package Specifications
Using some free time during my Christmas & New Year break, I worked on a new project, which implements some of the ideas from my earlier blog “Let’s turn packages into a module system”. The project is Veripacks; it allows to specify which classes from a package should be accessible,…