Better definition of 'composite pom'

[benson-basis]

The readme.md talks about composite poms. It would benefit a great deal from an example of this; it is just a pom that declares some dependencies and is used with `pom

import`? I know that an issue is not a great place to have an argument, so please forgive the following. I have a raft of projects with a lengthy, identical, list of dependencies. If you want to write a pax-exam test, you need all these dependencies. scope=import is only permitted in dependencyManagement. So it doesn't solve the DRY pain of all those dependencies, it just subtracts out the versions. I was hoping that I could make a tile for this job, but your forbid in a tile. So what do you recommend?

[rvowles]

http://repo1.maven.org/maven2/nz/ac/auckland/composite/ http://repo1.maven.org/maven2/com/bluetrainsoftware/composite/ http://repo1.maven.org/maven2/net/stickycode/composite/

No, never use the import scope.

[eyalfa]

can you please explain these examples? couldn't find a single tile, actually all poms had nothing but dependencies, where are all the plugin?

[talios]

On 15 May 2015, at 1:35, eyalfa wrote:

can you please explain these examples? couldn't find a single tile, actually all poms had nothing but dependencies, where are all the plugin?

Composites themselves have nothing to do with tiles. And actually, tiles are just one aspect of what Richard and I were wanting to deal with with repaint.io.

A composite is really little more than a concept:

A maven artefact that only contains other dependencies.

Whether this is a pom based artefact or a jar based one ( a jar, with no classes of it's own ), or in my own usecase - an OSGi bundle that only embeds other jars ( and exports their contents ).

Looking at the examples Richard link to, you can find:

http://repo1.maven.org/maven2/com/bluetrainsoftware/composite/composite-unit-test/1.1/composite-unit-test-1.1.pom

Which is Richards unit-testing composite, it has nothing but locked down dependencies for unit testing ( junit and mockito-core ). Any of his projects that do testing, just depend on this composite thus, get the common set of dependencies.

His projects can even depend on a version range for the composite, rather than a range on Junit, which means you can control the update of dependencies in a central spot ( the composite ) and everyone can just pick that up - without having to update each project.

Tiles do essentially the same thing, but for plugins ( and dependencies, if you enable that smell ).

My project uses OSGi, so we use an OSGi variant of the composite in the bundling/deployment of our system, but I find I'm favouring explicit dependencies at the compile side of my artifacts ( having releases that ONLY contain a pom version change but pick up new dependencies requirements silently has hurt us occasionally with OSGi's runtime dependency tracking ).

Mark

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[johnlcox]

Why are composite poms preferred to dependencyManagement? I noticed there is a composite-jackson pom in maven central, but it seems like it would be bad that it directly pulls in the jackson-datatype-joda dependency if I'm using Java 8 along with the new DateTime APIs. I'd rather have jackson-datatype-jsr310 and exclude joda.

It seems like dependencyManagement would be a better fit because it could be used to lock the jackson versions together but then projects could specify the exact dependencies they need rather than getting a bunch transitively that they may not need, and may even need to exclud.

[rvowles]

Because (a) composition is always better than inheritance (b) composition is more fine grained than inheritance, you can group together whatever sensible groupings of dependencies work for you across different projects in the same company instead of having to only have one parent (c) you control your dependencies, you always create your own composites for third party components and lock their versions down, so I'm not even sure why you finding a composite-jackson in maven central means anything? Clearly that composite means something to someone else's project. (d) composites allow you to broadly upgrade individual pieces without having to re-release everything, it allows you to fix bugs faster without causing shift in people who use your libraries. People can depend on your released composite for a project (for example, CXF could release a composite of fixed sub-versions of their dependencies) - allowing the composite to be called 1.5 (for example), but continue to fix individual packages and bugs and releasing them rapidly allowing people to add exclusions and directly inclusion of the file.

So no, there is no case where dependency management is better that composition.