Carlos Sanchez wrote:
Have you guys thought about making the build more hierarchical, adding
more parent poms and grouping the projects to share configuration
This is basically what I was trying to describe in my other message
where I talk about our waffling between flat versus hierarchical. Since
flat hasn't seemed to work out too well, I am willing to give a more
hierarchical approach a try.
However, I still feel that trunk/ should contain sub-projects. Some
sub-projects may contain multiple parts, e.g., iPOJO, MOSGi, UPnP, etc.
So those can be grouped, but I do not think we should try to define some
ontological grouping hierarchical, like tools, plugins, etc. This gets
too confusing, e.g., iPOJO has a plugin, which could go into plugins or
tools, but it is really part of the iPOJO sub-project.
Thus, my suggestion would be trunk/ being the flat set of sub-projects,
where each sub-project can be comprised of one ore more modules to allow
for additional grouping.
The question is whether or not we should try to formally decide this
(i.e., a vote) or just do it.
-> richard
for instance, instead of
ipojo
ipojo.arch
ipojo.metadata
ipojo.plugin
ipojo/pom.xml (modules: ipojo, arch, metadata, plugin, version= 0.7.0 )
ipojo/ipojo (usually core or some other name)
ipojo/arch
ipojo/metadata
ipojo/plugin
all the ipojo subprojects would extend ipojo/pom.xml that in turn
extends the parent felix pom, you could share some info in
ipojo/pom.xml
that way you reduce the modules in felix parent to ipojo,
plugins,mosgi,...
and you wouldn't need different profiles, just go into one of the
folders and mvn install, eg. go to plugins to build all plugins
from my experience i think it would make more sense and ends being
easier to mantain
