Vert.x stack projects

We define here the Maven projects that are part of the Vert.x stack. Vert.x 3 stack is a set of projects that forms a stack. For the sake of flexibility, not all projects must have the same version, this apply mostly to languages or extensions.

Current stack projects

The projects of the current stack (more projects will be part of this stack later).

• Parent
  • vertx-parent:1 : a parent that defines the default plugin management of the whole stack. This pom extends the sonatype parent pom and defines the most usual plugin version and configuration for the stack (compiler, source, etc...)
  • vertx-ext-parent:1 : a parent that extends the vertx-parent and define plugin execution for code generating extensions. This project does not depend on a particular Vert.x dependency, it only uses existing plugin. This is possible because we use annotation processing that is a kind of plugin but that is managed via maven dependencies, so this indirection is actually useful to ensure Vert.x projects don't depend on a parent snapshot.
• Tools
  • vertx-codegen : the code generation tool
  • vertx-docgen : the doc generation tool
  • vertx-codetrans : the code translation tool
• Vert.x core
• Languages
  • vertx-lang-js : JavaScript generation
  • vertx-lang-groovy : Groovy generation
• Services library
  • vertx-service-proxy : event bus service proxy generation
  • vertx-service-factory : hot service deployment
  • vertx-maven-service-factory : a service deployer based on Maven repositories
• Extensions
  • vertx-metrics : Codahale metrics for Vert.x
  • vertx-hazelcast : Vert.x clustering based on Hazelcast
  • vertx-reactive-streams : reactive stream implementation
  • vertx-mongo-embedded-db : easy bootstrap of mongo db for testing purpose and kickstarts
  • vertx-rx : Rx* integration with RxJava, RxGroovy and RxJS
  • vertx-sockjs : SockJS
  • vertx-auth-service : authentication service
  • vertx-mongo-service : MongoDB async service
  • vertx-jdbc-service : JDBC service
  • vertx-apex : a set of building blocks for building web applications with Vert.x

Update this diagram

Stack versioning and dependency management

There is one extra project that is not mentioned above whose goal is to centralise the version of the projects. This project is called vertx-dependencies it defines the current versions of the stack via dependency-management sections.

Any project consuming an external stack component (i.e not in the same project but via the maven repository) should depends on this component using the maven dependency section. However it must not declare its version, instead the version must be defined by the vertx-dependencies pom. This pom should be consumed by the project using the following declarations:

<dependencyManagement> 
  <dependencies> 
    <dependency> 
      <groupId>io.vertx</groupId> 
      <artifactId>vertx-dependencies</artifactId> 
      <version>${stack.version}</version> 
      <type>pom</type> 
      <scope>import</scope> 
    </dependency> 
  </dependencies> 
</dependencyManagement> 

The stack.version property holds the version of the current stack, this property is managed by the release process that changes when the stack is released.

<properties>
  <stack.version>3.0.0-SNAPSHOT</stack.version>
</properties>

The benefits of this dependency management are:

• we keep the stack versions in a single central place of the project, instead of distributing the versions in each projects
• each project depends at most of a single SNAPSHOT declaration, the SNAPSHOT version of the vertx-dependencies pom. This ease much the release process, since when a release happens, the vertx-dependencies pom is first deployed with all the correct versions, then each project updates its version of the _vertx-dependencies_pom and then can be deployed

Managing Maven project

In the previous section we explained how we want to maintain dependencies, let's now give the simple rules that stack project need to follow

a project declare at most a single external snapshot : the vertx-dependencies

• Dependency versions come from this vertx-dependencies definition
• It is not mandatory, for instance vertx-codegen does not depend on it
• It include parent pom, the parent pom should be either vertx-parent or vertx-ext-parent, such projects are released independently of the stack
• This includes plugins dependency section: they must not declare dependencies on snapshots
• On the contrary in a multi module project, the version snapshot needs to be declared, but this is not considered as an external dependency (because it is same project)

Keep in mind also that when you do a multi module project, not all your modules should go in the vertx-dependencies defintion. For instance your project can have module for testing purpose (like the vertx-maven-service-factory project)

Stack version property

The stack.version property is used for controlling the vertx-dependencies version by the release process, it can be used for other things such as resource filtering, documentation version, etc...