Hello Michiel,
My response on your first point. My idea is to use war overlays
extensively. http://maven.apache.org/plugins/maven-war-plugin/overlays.html
The base-webapp at the moment is the mnimalistic war we had before. the
example-webapp is de binary distribution. The current mmbase war is not
a replacement for something earlier. What I like to see it split up of
the mmbase war in smaller maven projects. For example. one for each
editor? Smaller projects usually make it clearer what files are used
where. You don't want to force the outside world to use all those small
things even when they might be nice. Here a base-webapp aggregates
everything an outsider needs. Maybe another webapp without any non
mmbase libs is nice. The small an big wars facilitate 2 types of people:
the control-freaks and the do-not-care.
On the second. I haven;t figured out yet how to do the mmbase.version
property correctly as intended in the privaterelease profile. How it is
now in svn it is crashing when the application parent is not in the
local repistory and working offline (mvn -o) The reason of this is that
the parent pom.xml is not correctly resolved. The ../pom.xml (parent
relativePath default) for the applications/resources/pom.xml does not
match the groupdId/artifactId/version which is specified.
Probably 2 solutions which work
1 drop the usage of the mmbase.version property
2 Put our main poms, which don't change a lot to a fixed version.
/pm.xml and applications/pom.xml. I haven't test this one yet, but it
should work. The parent should be installed before all modules.
I agree with the versioning of the mmbase maven plugins. They are
required for build of the mmbase product, but not part of the product.
Nico
Michiel Meeuwissen wrote:
We have 'maven2ized' the directory structure. And most of it is quite nice.
But I have two issues, for which I could use opinions.
Firstly, I think that the current situation with base-webapp.war vs
mmbase.war is a bit inconsistent.
base-webapp contains mmbase.jar, mmbase-taglib.jar and the jars on
which they depend.
the mmbase.war contains only mmbase.jar and a few (not all, but that
obviousy is a bug), jars on which it depends.
The mmbase.war also contains the '/mmbase/' dir. The base-webapp does
too, but only because it depends on the mmbase.war.
I think that since not much in the /mmbase/ dir can work without the
mmbase-taglib, either mmbase-taglib.jar should also be in the
mmbase.war or the /mmbase/ dir should be in the 'base-webapp' only.
So I'd say one of these 2 things must happen:
1. core/pom.xml becomes of type 'jar' and is only responsible for the
mmbase.jar. All templates are moved to the base-webapp.
or
2. base-webapp is dropped alltogether. mmbase.war will also include
mmbase-taglib.jar, and can itself serve as a 'base' war for all mmbase
installations.
The second issue I have it that dependencies seem a bit circular.
E.g. /applications/pom.xml with artifactId 'mmbase-application-parent'
calls, via <modules />, every application in /applications/, and hence
this build is dependent on every application's build, and it's pom is
only 'installed' if every application's build succeeded.
Every application though has as parent 'mmbase-application-parent',
and hence is dependent on it.
It could be that this is usual thing to do, but I encounter more
problems with it then I like (especially when changing the version)
and would like to experiment with an application parent which is more
like a sibling to the applications (I mean that it is _also_ created
by the 'modules' pom, but the 'modules' pom is parent to nothing). But
it is not impossible that my relative inexperience with maven 2 is
talking here.
Related to this last issue is that I'm not sure that 'parent' poms and
maven plugins should share the mmbase version (1.9-SNAPSHOT, 1.9.1
etc). Because, at least together with the described 'circular
dependencies issue' this makes building a new version a minor pain
(where you have to do several times 'mvn -N' to ensure that the stuff
is build in an order that actually works)
greetings,
Michiel
_______________________________________________
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
