Automatically detect correct build profile (no more -Pcomplete)

[holly-cummins]

Resolves #233
Resolves #378

I think the reason we originally had profiles is that depending what zip they extract, sometimes people have lots of modules, sometimes they have a small number, and maven does not allow us to define optional modules, or just do a “build all subfolders” command.

The mvn docs say:

All profile elements in a POM from active profiles overwrite the global elements with the same name of the POM or extend those in case of collections. In case multiple profiles are active in the same POM or external file, the ones which are defined later take precedence over the ones defined earlier (independent of their profile id and activation order).

So anything we define in a profile will add to anything we define in the main pom, but profiles won’t add to each other, and we need to define them in order.

We can only define one ‘guard’ file per profile. The good news is that limits the combinatorics, and we have to assume a limited number of ‘profiles’ (as it were!) to cater for. This does mean if someone is midway through building the workshop and tries a top-level build, it will fail because of missing projects or, depending what guard file we choose, not build everything.

This is annoying, but no worse than where we were before. At least builds of the extracted zips will work.

Well, they would build if it wasn’t for #280. I’ll fix that next, and also add some tests to make sure the zips can actually build, since it seems like core technical capability.

[holly-cummins]

It turns out there are some subtleties with reactors build order and profiles. The reason some of the instructions and readmes build the extension module first is that, under some circumstances, maven will build the deployment module of the extension quite late. It doesn't take transitive dependencies into account when deciding the reactor order. It seemed like one way of defining the profiles got the correct order, so it behaved like the old -Pcomplete, and the other got an incorrect order and was broken. So I've gone with the way that works, but it's a bit more fragile than is ideal.

[holly-cummins]

Another complexity - we used to only build native for the core profile in the CI, but with this change, we build it for everything. That seems like the right kind of check to be doing in the CI, but it's

(a) slow
(b) failing

I've gone back to just building the core with native, and raised #404 and #405.

[agoncal]

I remember that @cescoffier had to refactor the directory structure and change the pom to make sure the extension was built first, and then the app in second

[agoncal]

OMG I can already see some merge conflicts when I'll create my PR ;o)

[github-actions]

🙈 The PR is closed and the preview is expired.

[holly-cummins]

Merging, @agoncal! The exclude for the extension version build isn't working - maybe it needs to be extension-version-parent? - but I will do that in a follow-up PR.

[agoncal]

Ok. I'll be careful with the extension then

[holly-cummins]

Ok. I'll be careful with the extension then

I think there's no need, just be aware that the CI build is annoyingly long now (doh, sorry!), and one mitigation that looks like it's there (not doing a native build of the extension) isn't actually working. :)