repaint-io / maven-tiles

Injecting maven configurations by composition rather than inheritance
154 stars 32 forks source link

The plugin makes tile as parent, and then makes original parent as top parent #30

Closed kdeng closed 9 years ago

kdeng commented 9 years ago

The plugin makes a tile as parent, and then makes the original parent on the top of tile. So that the distributionManagement of original parent doesn't be overrided by tile.

I suppose the tile will be the top of original parent, so that the distributionManagement can be overrided.

rvowles commented 9 years ago

No, it is as it is by design - the tiles being the direct parent of the project means it has a higher priority. The issue is probably that the distributionManagement is not being overridden or the release plugin is not honouring it. I think @talios made some mention of this?

kdeng commented 9 years ago

the direct parent of the project? For example, if pom.xml looks like:

<parent>
   ...
   <artifactId>java-7-parent</artifactId>
   ...
</parent>
<build>
      <plugins>
            <tile>nz.ac.auckland.tile:java-8-tile:[1,2)</tile>
      </plugins>
</build>

What the final pom.xml will looks like?

<parent>
  <artifactId>java-8-tile</artifactId>
  <parent>
    <artifactId>java-7-parent</artifactId>
  </parent>
</parent>

Or another way around?

In this case, which java version will be used in the end?

rvowles commented 9 years ago

pom should look like: project -> java-8-tile -> java-7-parent, the tiles are inserted as fake parents.

talios commented 9 years ago

On 4 Sep 2015, at 17:15, Richard Vowles wrote:

No, it is as it is by design - the tiles being the direct parent of the project means it has a higher priority. The issue is probably that the distributionManagement is not being overridden or the release plugin is not honouring it. I think @talios made some mention of this?

Someone I missed all these messages. I keep meaning to find some time to try this out and step thru an execution when release:prepare or release:perform is being run to find out/see whats going on.

One thing to try, in your and include a help:effective-pom call to print out the effective pom at both the prepare/perform phases - are we correctly generating/carrying forth the and elements?

I can't recall if maven actually gives any specific error when trying to release using a tile or not?

Mark

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

talios commented 9 years ago

Ok, so I now have a successful release-tile working!

The problem, as I worked out is that the problem lies in the maven-deploy-plugin which gets a a maven Project injected, unfortunately this happens to the be the original unprocessed project model. So still points to your original parent ( or none ).

Since patching the deploy plugin is out of the (immediate) question, my solution is to add to your release tile:

<properties>
  <altReleaseDeploymentRepository>smx-releases::default::http://mynexus/content/repositories/releases/</altReleaseDeploymentRepository>
  <altSnapshotDeploymentRepository>smx-snapshots::default::http://mynexus/content/repositories/snapshots/</altSnapshotDeploymentRepository>
</properties>

Which the maven-deploy-plugin will gladly use in favour of the any defined in the distributionManagement section ( which we simply drop, or leave in if you want to generate site docs etc. ).

This leaves me with a nice release tile containing a templated scm section ( naming our repositories after the ${project.artifactId} for a measure of consistency and the <plugins> section containing maven-release-plugin.

talios commented 9 years ago

Given this... anyone take issue with me closing this issue?

kdeng commented 9 years ago

that's great to me. Thanks a lot.