np :) Thanks for the feed-back: it's better to question too much then
too little.
If you find anything else you think we can improve, let us know.
Op 13-03-12 00:01, Justin Holmes schreef:
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
<[email protected] <mailto:[email protected]>> 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
o required to find and download the droolsjbpm-parent
pom (because that's in a different repo)
o 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
o dependency versions sometimes (these are temporary
hacks that must be removed but there are always some)
o plugin configurations
o <scm> info to find the git repo
o ...
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 list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
