Hallo Ernst,
Exactly for this question I moved to maven a year ago and only use maven
in the cmsc project.
The big picture of a cmsc project is
MMbase
CMSC core
CMSC optional modules
CMSC optional portlets
Nijmegen project
I don't want a developer on the nijmegen project bother with the fact
that I upgrade the project to a new mmbase or cmsc version. At the
moement, when the developer does an update on the cvs nijmegen project
the maven files are renewed. The maven files contain the new version
number and the maven build will download the new files.
The technical lead of the cmsc project follows these steps to create a
release
1 cvs update cmsc project
2 cvs tag on cmsc project
3 run clean maven build
4 deploy artifacts to remote maven repository
5 change version to the next version (maven builds will use the version
for the binairies.You don't want to override the final "tagged" build in
the maven repository)
6 checkin new version
We use different version dependency strategies for each layer.
MMBase - All jars have the same number (x.x.x)
CMSC core - All jars have the same number (x.x.x)
CMSC - optional modules - - Each jar can use the a different number, but
must use the same major and minor number as the csmc it belongs to. (x.x)
CMSC - optional portlets- - Each jar can use the a different number, but
must use the same major and minor number as the csmc it belongs to.(x.x)
Nijmegen - all jars and wars have the same version number. This number
is based on the release to the customer.
Regards
Nico
Ernst Bunders wrote:
Hello Developers
We at Dynasol are asked by Kennisnet to do some development/bugfixing
for MMBob in the near future. They specifically requested that we
should develop in the mmbase cvs repository, and build a specific
Kennisnet release on top of the files produced by the mmbase
contributions build.
A requirement for us is that we can make releases that can be
reproduced. it should be possible to branch from a previous release.
To document what changes belong to a specific release.
The trouble is that I can not think of a release model other than
following the mmbase releases. Because the applications/contributions
are dependent of mmbase and version tagging/branching follows mmbase.
It is not a very good situation if we fix a number of bugs and than
have to say: you can have the new version in three weeks because than
a new mmbase release is being made.
We could tag the mmbase repository for mmbob releases. This at least
would give us the chance to recreate a release. The problem of this
approach of course is that mmbase might at such a time be unstable
itself.
So, the crux is that an independent development model for applications
is completely missing. I can not think of a way to do it right. I
suppose maven could be used to disconnect the
applications/contributions from mmbase as it is good at defining
dependencies. But that is not the current situation.
I wonder how other people look at this issue. is there something I miss?
Can anybody suggest a way of working that would allow us to meet hour
requirements apart from following the mmbase releases?
I am looking forward to some reactions on this.
regards,
Ernst
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
