NO-ISSUE: Upgrade Maven plugins to newer versions and Apache parent from 32 to 33

[yesamer]

In this PR:

• Updated Apache parent pom to version 33
  - Removed all plugin declarations already present in the Apache parent pom
• Updated most of the maven plugin versions
  - Removed stale profile reference in serverless-workflow

[tiagobento]

@yesamer I guess I didn't write this anywhere, but the idea of managing the versions of Maven plugins ourselves is to have more control over patches that may contain security fixes. If we delegate it to the Apache parent we may find ourselves in a position of having to declare them anyway to fix something that the Apache parent hasn't.

[yesamer]

@tiagobento Well, at the moment a CVE is detected in any plugin version, we can temporarily override. I guess that is a good compromise on having the same plugin versions used anywhere and keeping them updated.

[jomarko]

Thank you for the PR, my comments ale inline.

[yesamer]

@tiagobento I checked the CVE history of all declared plugins in Apache parent pom.
An example: maven-assembly-plugin
https://security.snyk.io/package/maven/org.apache.maven.plugins%3Amaven-assembly-plugin
https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-assembly-plugin
I didn't find any reported CVE for those plugins EVER.
Based on that, I guess we are safe to proceed ;)

[tiagobento]

@yesamer Problems are often in transitive dependencies...

[yesamer]

@tiagobento Even in such a case, those dependencies are not transitively imported in the production code, as the dependencies imported by the plugin are used during its own compile time only.

[jomarko]

Thank you. I did a small sanity check with the online-editor and extended-services:

• open bpmn sample
• open dmn sample, old dmn gwt editor
• run dmn model, old dmn gwt editor

[tiagobento]

I don't see it that simply @yesamer... I'm not 100% onboard with this version management strategy this PR introduces, as it delegates to Apache parent for maven-base but not for some other packages. I'd like to hold merging it so we can discuss it in more depth. Such a change is not to be done casually, IMHO, as it has to do with the way we manage and maintain dependencies in general.

[yesamer]

@tiagobento Setting this PR on hold until you share your input on the whole strategy. Again, apologies for my previous bad answer that I removed.

[yesamer]

@tiagobento After our discussion now I fully understand the scenario you described, and I agree it can be a realistic scenario. Thank you for raising that and apologize again for not giving the proper attention.
Now, to finalize this PR, I'm open to considering your suggestion and don't rely on the Apache parent pom for the involved maven plugins, to quickly react to the worst-case scenario of overriding a transitive dependency used by a maven plugin.

[yesamer]

maven-helper-plugin doesn't exist