MMbase and applications are already mavenized version 1 (except for
rmmci). Contributions which want to be in this process should be mavenized.
All appications have a project.xml which extend
/mmbase-1.8/applications/app-base/project.xml. The only dependency in
this file is
<dependency>
<groupId>mmbase</groupId>
<artifactId>mmbase</artifactId>
<version>${mmbase.version}</version>
<url>http://www.mmbase.org/</url>
<properties>
<eclipse.dependency>true</eclipse.dependency>
</properties>
</dependency>
To make the layers more complete in my previous mail
MMbase
MMbase applications
MMBase contributions
MMApps
CMSC core
CMSC optional modules
CMSC optional portlets
Nijmegen project
Nico
Ernst Bunders wrote:
That makes a lot of sense. Perhaps we have to do something like it.
in that case we have the following layers:
1 mmbase (tagged release)
2 mmbob, multilanguage, thememanager, profilesconnector (tagged
release using different tags)
3 Kennisnet specifics.
where the second layer should match major and minor version numbers of
mmbase.
But I suppose that for this to work smoothly, the applications and
contributions of the mmbase cvs repository should be 'disconnected'
from mmbase and also use mmbase as a dependency, or in other words,
they should be mavanized, right?
Ernst
Nico Klasens wrote:
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
