Am 21.11.2014 um 17:42 schrieb John Mazzitelli
<mazz(a)redhat.com>:
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?
No.
It will pull in the dependencies of rhq-metrics, rhq-msg, .... from a maven repo with very
defined version
and build alohomora "product". This is like current RHQ builds by pulling in
e.g. hibernate or log4j except
that a large part of the stuff lives in rhq-metrics, rhq-msg and so on.
So that one has the glue/integration code in it (and of course also some biz logic, some
ui and so on).
(btw alhomora, alohomora or almohora ?)
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.
Yes
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.
Yes
Both sound right to me.
And the third usage of the repo would have been the integration project as described
above.
If those 3 do not fit together into one repo and need to go into 2
- bom/pom
- integration, pulling in the pom/bom
then this is fine too.
I hope I am not to confusing here ...