Resolve tiles from current reactor

[erwint]

If a tile is defined in the current reactor and used in one of the modules, it should be resolved directly from the reactor. Otherwise you need to install the tiles in a pre-build step first.

[erwint]

gerrithub sumission added: https://review.gerrithub.io/#/c/282730/

[rvowles]

patch looks good. we really do need some better integration tests to ensure stuff isn't breaking existing things.

I'll pull this change in the weekend and see what happens to our stuff.

[talios]

On 15 Jul 2016, at 12:02, Richard Vowles wrote:

patch looks good. we really do need some better integration tests to ensure stuff isn't breaking existing things.

I'll pull this change in the weekend and see what happens to our stuff.

I've been meaning to get a chance to look at these PR/revs but have been snowed under with work. I did see one of them was to allow defining tiles inside a reactor build. If we land that, when we could setup some multi-module builds using invoker as tests - define a tile and use it in a test.

Altho that might want a tile per test which could be cumbersome, we could just set up a separate repo with a test tile.

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

[rvowles]

Yes, agreed - we really need to get better testing for this, particularly
because 2.8 ostensibly broke something.

On Sat, Jul 16, 2016 at 8:55 PM, Mark Derricutt notifications@github.com
wrote:

On 15 Jul 2016, at 12:02, Richard Vowles wrote:

patch looks good. we really do need some better integration tests to
ensure stuff isn't breaking existing things.

I'll pull this change in the weekend and see what happens to our stuff.

I've been meaning to get a chance to look at these PR/revs but have been
snowed under with work. I did see one of them was to allow defining tiles
inside a reactor build. If we land that, when we could setup some
multi-module builds using invoker as tests - define a tile and use it in a
test.

Altho that might want a tile per test which could be cumbersome, we could
just set up a separate repo with a test tile.

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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#65 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADZ2IecgbJh57-9bTlZICeKWF7GkAlcks5qWJx8gaJpZM4JERZP
.

---

Richard Vowles,
Groovy, Java, Javascript, AngularJS - Contract Software for Hire!

ph: +64275467747, web: www.google.com/+RichardVowles

[ivoleitao]

I'm also affected by this bug. Any workarounds while it's not solved ?

[rvowles]

I merged this fix @ivoleitao and released 2.9

[ivoleitao]

Hello,

I only recently needed this feature and noticed that the code was not merged. I've forked this and merged the code and I can confirm that it's working perfectly.

I'ts possible to merge this fix and release a new version ?

Many Tnks,
Regards,
Ivo Leitão

[rvowles]

You are using 2.10?

[ivoleitao]

Yes,

I checked the master also and the code is not merged. I've looked at https://review.gerrithub.io/#/c/282730/ most specifically to the method:

protected Artifact resolveTile(MavenSession mavenSession, Artifact tileArtifact) throws MavenExecutionException {

and it's missing code (not only this one but others also). If you compare that method in https://github.com/repaint-io/maven-tiles/blob/master/src/main/groovy/io/repaint/maven/tiles/TilesMavenLifecycleParticipant.groovy with the one from the commit in here c8c44f0 they are different.

Regards,
Ivo Leitão

[talios]

I've merged the two reviews:

• Fix for models with inherited groupId from parent
• Resolve tiles from current reactor (Fixes Resolve tiles from current reactor #65)

and everything seems to be working ok so far on local projects. Have also made some dependency updates ( latest Groovy, gmaven, maven ) and will push that for a review tonight as well, and hopefully get a release out.

[talios]

2.11 now released.

[ivoleitao]

Hello, I've updated to the new version but unfortunately something has gone terrible wrong since my builds stopped working. I think this must be related with some of the dependency updates. I'm obtaining a rather strange error message:

[ERROR] Unable to load, try another Isolator. org.sonatype.aether.impl.VersionRangeResolver -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException

I cannot build any of my projects that use 2.11 :-(. I've reverted to a internal version that I have generated and which I have merged and everything started work again.

Regards,
Ivo Leitão

[talios]

What version of Maven are you using? I tested against 3.5.1 and the current 3.5.3 releases. Are you using an older 3.3.x or something?

[talios]

You're right - it doesn't work under 3.3.9 anymore.

[ivoleitao]

Hi,
yes I'm using 3.3.9 version

Regards,

[kemitix]

IntelliJ still bundles Maven 3.3.9, which is the most convenient version to use when you work on multiple environments can't rely on the path to maven to be consistent.