Hi *,
Welcome Alhomora!
I am afraid, the present setup, as explained on IRC, does not work. I
tried to implement a subproject sub1 in a separate project and I added
some glue code under alhomora-parent. It contains a kind of a dependency
cycle - i.e. none of alhomora-parent or alhomora-sub1 can be built.
Have a look:
PROJECTS=~/scratch
cd $PROJECTS
git clone
https://github.com/ppalaga/alohomora.git
git clone
https://github.com/ppalaga/alohomora-sub1.git
cd alohomora
git checkout -b alhomora-parent ppalaga/alhomora-parent
mvn clean install # Could not find artifact
org.alohomora.sub1:alohomora-sub1
cd ../alohomora-sub1
mvn clean install # Could not find artifact org.alohomora:alohomora-bom
Maybe you meant it differently than I did?
The BoM should not be a child of alhomora-parent. BoM should rather be
independent in a separate repo, groupid and versioning cycle.
Thanks,
Peter
On 2014-11-19 11:43, Heiko W.Rupp wrote:
Hello,
RHQ.next is / will be split and developed in several sub-projects on their own like
rhq-metrics, rhq-msg, rhq-audit and so on.
This also means that we need a "central place" to integrate all the pieces into
one.
In addition we need to make sure that the sub-projects use "compatible"
versions of dependencies.
So I propose that we introduce a rhq.next project (*) that servers those two purposes
- integration of individual project
- master pom/bom for versions of dependencies
During the initial development cycle, we may need to publish that bom more often in order
to
make dependency definitions available, but should be better off in the long run.
I don't know if there is a way to enforce that the individual projects don't just
override the settings from the bom.
I know there are people on the list, that have done that before and can probably help
with the setup.
Heiko
*) or branch inside "rhq" project if we want to keep that name