maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: Best practice for branching projects?
Date Wed, 08 Oct 2008 01:22:34 GMT
Hi Stefan,
I don't know if I got the problem right and if this could be a solution,
but I do as follows (obviously, we are talking about "maven branching",
not SVN or CVS branching, which is another story) :
- setup a developers only maven repository
- setup a production only maven repository
- use range versions instead of fixed ones
.. This means that instead of having a dependency on artifact
com.yourcompany:artifact:1.0.0 you have a dependency on
com.yourcompany:artifact any version > 1.0.0
- when a subproject is buggy, a team (or single developer, or whatever)
will start working on it
- they will build it on their own computers (in their local repository),
so no problem with them testing their own work
- they will occasionally deploy it TO THE DEV ONLY repository
.. deploying it there, will let the other teams use the new artifact and
test that their own work is correct related to the new
bugfixes/refactorings and so on
.. obviously, when they deploy, they should increment the minor
version/revision, but only on that project specific pom (for example
1.0.0-r1 1.0.0-r2 or 1.0.1 1.0.2 etc...)
- when the bugs have been fixed, the deploy can be made on the
production only maven repository
- from there, a complete build and test of the application can be done,
and final release (war, jars or whatever) created to send to customers

This way, every project can have its own "lifecycle", its own releases,
and probably its own SVN branches and so on. While using fixed version
dependencies is a good practice when linking to something outside your
control (artifacts on the main repo), for internal dependencies
(artifacts produced inside your company/team) it is a maintenance
nightmare and most of the time useless, cause you know when a new
version will break compatibility and can adjust versioning only when
that happens.

Using SNAPSHOTS can save a bit of time making the "change the version
when sending to other developers" step not necessary, but I think that
it should be avoided when there is a high number of developers : that
step can potentially break the build and stop other developers' work if
the new package breaks compatibility when it should not or introduces
more bugs than the previous one (which obviously happens :) ), and
having also these "internal" releases versioned is IMHO more time-saving
than using automagic snapshot updates.

Hope this helps,

Stefan Fritz wrote:
> Hi,
> We use Maven in an environment where we have ca. 150 projects.
> One project is the toplevel project (= the final deliverable to the
> customer/user).
> This project has dependencies to 10 projects, which have dependencies
> to other projects etc. In the end we have 150 different projects in
> the dependency hierachy.
> The challange now is what happens if in one of the projects on the
> lowest level is bug.
> This means we have to branch from our released version to work on a
> patch and then release the patched version.
> From my understanding the only way to do that is to branch all
> projects which depend on the "buggy" project. And the same has to be
> done for all levels up to toplevel project.
> Most low level components are referenced by multiple projects and
> therefore a patch-branch would afect ca. 30 projects :-(
> As you can imagine this can end up in a nightmare of manual steps
> and/or scripting.
> Therefore I hope anybody has a better approach to that.
> Is there a simple way to do that?
> Any automation in Maven?
> Any best practices?
> Thanks
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Simone Gianni            CEO Semeru s.r.l.           Apache Committer
MALE human being programming a computer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message