Fix Profile Interpolation bug

[ciis0]

#102 rebased

Closes #102
Fixes #103

[hohwille]

@ciis0 Thanks for this PR 👍
I would like to first discuss whether we should "fix" the existing resolveCiFriendliesOnly as it seems to be quite buggy or create a new mode as suggested by this PR.
Do not get me wrong. I like that you care about existing behaviours that you do not want to break.
Also I would like to integrate your work and pull out a new release with this fix.
However, I do not yet understand the full context and want to take the right decision.

[hohwille]

Please do not missuse existing ITs to test a new feature. You would need to create a new integration test instead.

[hohwille]

IMHO we should either "fix" the existing mode, or if we keep it create a new IT for version mode.

[ciis0]

As per #114 (comment) resolveCiFriendlies should be fixed. :)

[hohwille]

So if this is a "fix" for resolveCiFriendliesOnly why do we have to introduce a new mode then?
My impression is also that this plugin can not be understood by an avergage user anymore. So what does version mode do? Where is it documentated? I already had concerns like this with the naming of resolveCiFriendliesOnly and the documentation is already lacking there but I did not want to be a blocker for urgently requested features. I think that your PR is in general providing a very helpful improvement as I also experienced some problems/bugs with this resolveCiFriendliesOnly. However the way we address this should IMHO need some improvement.
@lasselindqvist do you have some cents on this?

[ciis0]

I just kept it during rebase, no other reasons from my side. ^^

[hohwille]

interesting. So actually keep does not actually do what it should? Can you give an example?
And you invented a new handling to avoid breaking existing build configs?
That would make a lot of sense. So does keep somehow already resolve variables or what is it that it does too much?

[ciis0]

The problem that arose for me was that the configuration in (active) profiles was interpolated, specifically ${basedir}.

And I did not invent anything, just rebased it. ^^

[ciis0]

Without wanting to be rude, but the overall direction of the original PR-code is rather being a work-around that being a real fix :D

I guess the work remaining now is to fix the underlying issues so the workarounds (version, keepRaw) are not necessary anymore.

[ciis0]

I basically invented nothing here, just rebased it :D

I just kept the original new version mode from the original code, I didn't make any assumptions here ^^

In the context I encounter the bug in resolveCiFriendlies (flattening ´${revision}` in a multi-module project) for the project it wouldn't be important to have an extra mode for this and fixing the original one would also be okay.

I'd say this kind of behaviour is not worth keeping backwards-compatible, it simply does the wrong thing in a way that and.
To make everyone happy one could introduce a property that still interpolates profiles and the likes. :D
Name suggestion based on https://xkcd.com/1172/ would be overheatCpuOnSpacebar.

[ciis0]

Although the underlying code is not mine, I am motivated to fix the issues that arose; the bug is really annoying in some of our projects :D

[lasselindqvist]

See also comments in: #103

I don't think this is in a mergeable state, as it contains a mix of commits for different things, but the integration test idea is definitely usable here and opening a PR with two commits: the first introducing the test, and the second introducing the fix should be merged.

The added test has

<profiles>
	<profile>
		<id>cifriendly-profile-bug</id>
		<activation>
			<activeByDefault>true</activeByDefault>
		</activation>
		<repositories>
			<repository>
				<id>myrepo</id>
				<name>myrepo</name>
				<url>https://${repoHost}/${repoPath}</url>
			</repository>
		</repositories>
	</profile>
</profiles>

but I think we want to have something like

<profiles>
	<profile>
		<id>cifriendly-profile-bug</id>
		<activation>
			<activeByDefault>true</activeByDefault>
		</activation>
		<repositories>
			<repository>
				<id>myrepo</id>
				<name>myrepo-${revision}</name>
				<url>https://${repoHost}/${repoPath}</url>
			</repository>
		</repositories>
	</profile>
</profiles>

so that we see that the revision is resolved in the profile, but other variables are not.

[lasselindqvist]

Checked this behavior and the problem is that the profile arrives to FlattenMojo.createResolvedPom already resolved to
<url>https://foo/bar</url>
so there is nothing CiInterpolator can do about anymore. Need to stop this resolution before that.

Seems like this issue exists regardless of the resolveCiFriendliesOnly flatten mode, which might make it harder to solve.

[ciis0]

Seems like this issue exists regardless of the resolveCiFriendliesOnly flatten mode, which might make it harder to solve.

Yup, that's the keepRaw thingy if I am not mistaken.

[ciis0]

#126 supersedes this PR.