Geoffrey,
Thanks for the explanation. Looking at this through the lens of git, it
makes a lot more sense.
Best Regards,
Justin
On Sat, Mar 10, 2012 at 5:01 AM, Geoffrey De Smet
<ge0ffrey.spam(a)gmail.com>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?
Thanks,
Justin
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev