[MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup

[judovana]

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes. https://issues.apache.org/jira/browse/MARCHETYPES-76
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MARCHETYPES-XXX] SUMMARY, where you replace MARCHETYPES-XXX
  and SUMMARY with the appropriate JIRA issue. Best practice is to use the JIRA issue
  title in the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[judovana]

Note, that the PR is in real just:

-#compilerProperties( "1.7" )
+#compilerProperties( "1.8" )

the rest is adjusting of tests to the new reality. Renaming s/8/7/g in names and s/1.8/1.7/g in theirs pom.xml and reference

[gnodet]

Note, that the PR is in real just:

-#compilerProperties( "1.7" )
+#compilerProperties( "1.8" )

the rest is adjusting of tests to the new reality. Renaming s/8/7/g in names and s/1.8/1.7/g in theirs pom.xml and reference

And why do we need to move all the tests back to 1.7 ?

[slachiewicz]

Java 7 target is no longer supported on Java 21

[judovana]

The test demosntrates that you can still use legacy 1.7 if you insists.

Java 7 target is no longer supported on Java 21

Right. thats why this PR was created :)

[judovana]

And why do we need to move all the tests back to 1.7 ?

Well the default is now 1.8, it soudned liek nonsense to keep "bump" to 1.8.

There is already test which demonstrate that you can bump it up from default (to 11), to modular jdk,
The renamed test was demonstrating bump up, to non modular jdk. Unluckily there is no more non-mudular jdks when jumping up, so I kept the test to demonstrates that you can still use legacy 1.7, non modular if you insists.

Considering the next minimal JDK with next LTS will be some JDK12 or so, the test down, to non modular jdk will be still valid.

If you have any issues, I will revert the test change, or adjsut.

[gnodet]

Unless there's a reason, I'd revert the variable naming change.

[judovana]

Thank you very much. I did not realised that the commit will be squashed. I will keep it in mind for next time.

[judovana]

The remaining 1.7 fixed in #20 if you would be so kinf to eyball again, and possibly do a new release of maven archetypes, so the 1.8 will is egenrated via released version in maven repos, would be awesome - https://issues.apache.org/jira/browse/MARCHETYPES-79

[slachiewicz]

I've reverted it 0da7166 becouse I approved it too fast and we shouldn't move tests from Java 8 back to Java 7.

[judovana]

Do you realize that test will then (after bump of default jdk from 1.7 to 1.8) do noting. What do you suggest todo with that test then?

Afaikl the test to bump/dump to non-modular jdk should be there (there is a if in the macros on modular jdk)

[slachiewicz]

Thank you. I would leave it to someone more knowledgeable with this project.