I thought it would be best to have overall bom + integration in one
repo.
If I do "mvn install" we would get the alohomora "product" built by
pulling
in the code from the dependencies and so on.
If that does not work as one repo, so be it.
Are you asking to have one uber maven project where, if you build it via mvn install,
you'll get rhq-metrics, rhq-msg, rhq-alerts, etc. built and packaged?
Maybe I'm confused what it is you want.
What the alohomora project does now is it provides two things:
1) A root parent pom
This gives you all the "common" third-party library versions - so, for example,
we have gnu getopt defined here - all alohomora related projects will be expected to use
that and only that version of getopt. It doesn't define the actual DEPENDENCY
(groupId, artifact) - that's what the bom provides. See below.
This also gives you the repository definitions. So if your project has alohomora parent
module as its parent module, it gets the repository definitions for free.
Same with pluginManagement section - your project can get those definitions for free if
its parent module is alohomora parent.
2) The BOM pom
This provides the actual dependencies. It uses the version sys props provided by alohomora
parent so it can pull in the proper versioned dependency libraries.
It does NOT provide pluginManagement or sysprops.
Your project can depend on the BOM, thus bringing in all the dependency definitions - your
project can then just give groupId/artifacts for what it wants to use - no need to define
<version> since the BOM provides that. Your project will use the bom by putting this
in the pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.alohomora</groupId>
<artifactId>alohomora-bom</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
You still have to have <dependencies> in your pom.xml - you have to say WHICH third
party libs you want, and you can then give them scope (like test scope, or provided). The
scope is NOT to be provided by the BOM (at least, that's how the jboss integration
project has it). That allows the child projects to limit the scope how they want it (e.g.
some may want "provided" scope, others not).