[rules-dev] Maven Project Structure

[Geoffrey De Smet]

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
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120310/f1ff3c47/attachment.html