Skip to main content

Inconsistency on Maven model

Introduction

Trying to build maven from a single svn commit (actually it was a TAG commit), I found that it is impossible without a central repository or information from other svn commits. I present details about this case of "cross commit version cycle". I call this a "inconsistency" on Maven Model because it allows to create commit versions of a project that are not self-sufficient.
Any inconsistency about this inconsistency is welcome.

Maven project model (fragment)

In maven there are two different project relations Parent Relation and Module Relation.
Parent Relation inherent project properties and Module Relation manage the build process: "When building this project, build also this submodules".
Look at the maven reference documentation for full reference: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html

Snapshot versions and release versions

Most Maven projects have a main parent and many submodules as on figure 1.
Figure 1. Project structure and relations

Snapshot versions are used during development, to get the last version of the source code. Maven look on the central (or project if configured) repository to look for the last build.
When a release is ready, all the projects may be commited with version 1.0. You get then a concrete release and relations as on figure 2.
Figure 2. Release commit with version 1.0

Problem on partial version upgrade

The problem with Parent/Module relations appears on partial increase of versions. Assume that only some submodules versions are increased on release 1.1 (fig 3). As parent project has old version 1.0 (it was not changed) then submodules 1.1 refere to version 1.0. Lets call this commit 1.1_partial.
Figure 3. 1.1_partial commit

Now, increase on a new commit 1.1_rest the version of remaining projects to 1.1. You get a commit where each pom has version 1.1, BUT!! submodules changed on commit 1.1_partial have as parent pom with version 1.0 (fig. 4)
Figure4. Inconsistency relations cross commits

It may look as a bad use of maven versioning, but the model allows this situations so: how to interpret such a 1.1_rest commit??

Some simple arguments

Talking about this "inconsistency" on maven model, I get the follow counterarguments:

This don't happen!

I found this trying to build maven from source from a tag commit, so here is the example:
  • PARENT: org.apache.maven.plugins:maven-plugins:pom
  • SUBMODULE: maven-clean-plugin:maven-plugin
Refer to this TAG commit on maven:
Project relations are (version in brackets)
PARENT(18) --submodule--> SUBMODULE(2.5-SNAPSHOT) --parent--> PARENT(17)
Look here to see this relations:
You may not have any problem to build maven with this commit IF you have pom of PARENT(17) on you maven repository. This means that building from scratch is possible only if you use 2 different source commits, at lease 2 if you don't get more old version references.

I will take care of my pom versions, so it will not happen on my project

You control pom versions only on you projects, so if some external dependency have such a cross commit version cycle you will inherent it

Old versions are all on central repo, so no problem

I would like to have maven projects on gentoo, so is a problem for me.

Is this a real problem??

It is not a problem, until You have a central maven repository with old release versions. It seems to be sad, that actually We are forced to have such a historical repo.

Comments

Post a Comment

Popular posts from this blog

Inverse of Control is not Dependency Injection

How to understand the difference between "Dependency Injection" and "Inverse of Control"? Problem lies in lack of examples to "Inverse of Control" different than "Dependency Injection". So, below You can find a simple example to see the difference. On car traffic, each car is "controlled" by a driver. On front of stoplights, cars line up waiting for green light. Drivers accelerate at the sight of green lights, but they do it with delay. This leads to a situation as shown: Applying the Inverse of Control principle, stoplights could take "control" of car's acceleration and execute a synchronized and fast start on green light. So inverse of control for car-semaphore scenario looks like this: How is Dependency Injection related to Inverse of Control?? Well, on Dependency Injection you take the "control" over the new statement from developers to architect. Control on developer looks like this: public clas...
2 comments
Read more

Canonical Protocol

Introduction I will like to show some ideas about the canonical protocol I have defined. In the final example it is shown that such protocol provide features given by OAuth at the protocol level, it means that You can pass external resources without any change on services implementations or additional inter-service integration. RPC integration paradigm When using webservices to integrate remote systems, the development process can be summarized to: Client side -- Prepare request data from context -- make call -- Parse response and interpret result Service provider side -- Parse request -- interpret data to make internal API calls -- Create response Well, not so difficult. But the problem is that all the code used to serialize/parse context information and interpret request/response does not add any value to the system. Note that change from technologies like CORBA to web-services is just a standardization of the binary format used to create/parse the messages. The RPC ...
Post a Comment
Read more

Controlled scope

Introduction A specific use of Guice custom scopes is presented. You can have many problems trying something similar, so be careful. The reason to present this post, it to have a reference to explain a similar custom scope used in Service Architecture Model: ExtrenalBindingInfrastructureModule Problem: nested passing of parameters A business operation may be explicitly defined in a context of several high-level context objects. To improve reusability, code is split in several layers and nested method execution pass the context object. In the example below such situation is shown in one class. public class NestedParamaterPass { public void businessOperation(BusinessData data, Person person, Manager manager, Context context){ // some operation firstNestedCall(data, person, manager, context); } private void firstNestedCall(BusinessData data, Person person, Manager manager, Context context) { secondNestedCall(data, person, manager, context); } private void secondNested...
Post a Comment
Read more