Re: [eclipse-dev] Planning Meeting Post-Notes - 2 May 2012

[Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>]

On Thu, May 3, 2012 at 7:05 AM, Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:

Paul,

how are those POM files looking? Do you have some examples? I looked in the CBI Git repos and the pom.xml files there look quite simple and don't contain any additional data (maybe I did not see a real one?) i.e. they could simply be generated on the fly by the builder for most bundles (I guess). Is the information stored in the pom.xml, more frequently changed by the builder team or by the committers that own the source? If the former, it would probably make more sense to keep those POM files separate from the source and owned by CBI . The additional files could be generated or mixed in when running the build and it would allow the CBI releng people to change those files at will.

Some background:

The CBI based build starts off in a "aggregator" repo, which is the releng starting point.  It contains the main pom file that controls  the build.  In this case, http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/pom.xml?h=Juno_M6_R3 It also contains all of our repos, references as git submodules.  The aggregator repo controls the build input for a given build.

The first module it defines is eclipse-parent, http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/eclipse-parent/pom.xml?h=Juno_M6_R3 which contains tycho configuration.  Stuff like the environments to build, the p2 repositories the build needs to consume, and other build level configuration.

Then the rest of the modules describe what needs to be built.  For example for platform UI, you get http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/tree/pom.xml?h=Juno_M6_R3  That's basically a list of projects to build, like http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/tree/bundles/org.eclipse.core.commands/pom.xml?h=Juno_M6_R3

----

So each project to be built (bundle, fragment, p2 repo, product) has its own pom and its own subdirectory.  They live with the bundle they build.  That's maven's convention over configuration.  Just to put it in perspective, this is how maven treats pom files: "pom.xml files are fundamentally part of project source tree. They can and often do contain project specific configuration and must not be treated as something disposable."

The reason that most of ours appear pretty simple is that each pom inherits the parent configuration, so a lot of the work is done at the top instead of in each pom file.  We can override any of the config options in our project's local pom file.  Like using a project's pom file to completely specify its qualifier if we didn't want one to change.


Later,
Paul



-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR