Thanks for the explanation. Looking at this through the lens of git, it makes a lot more sense.

Best Regards,

On Sat, Mar 10, 2012 at 5:01 AM, Geoffrey De Smet <> wrote:
Hi Justin,

Take a look at those intermediate aggregator poms (for example drools-multiproject) per git repo.
You 'll see they contain some stuff we can't do without:
  • Location of JBoss repository
    • required to find and download the droolsjbpm-parent pom (because that's in a different repo)
    • so the build works out-of-the-box (very important for getting the community involved)
  • Repo specific overwrites that apply to all of the modules in that repo but not in the others
    • dependency versions sometimes (these are temporary hacks that must be removed but there are always some)
    • plugin configurations
    • <scm> info to find the git repo
    • ...

Op 07-03-12 16:49, Justin Holmes schreef:

Hello Devs,

I'm currently working on a project where I'm embedding Drools inside my application and using Maven to pull down the necessary artifacts. During this exercise, I've noticed that each project's pom (e.g. drools-core) references an aggregator pom (e.g drools-multiproject) as its parent. These aggregators then reference droolsjbpm-parent as their parent. I'm no maven expert, but it seems to me that this introduces an unnecessary layer of artifacts in the maven repository. My understanding is that aggregators are present solely to propagate build commands to their children and do not contain dependency information (as is the case in the Drools aggregators), so shouldn't the project poms reference droolsjbpm-parent directly? 



_______________________________________________ rules-dev mailing list

With kind regards,
Geoffrey De Smet

rules-dev mailing list