Springboot artifacts fix

[sdedic]

There's a springboot module on the Plugin portal, but that one does not handle native-image compilation. Longer term, I'd like to create a dedicated native-image supporting module(s) and move the gradle+maven plugin support there. But for NBLS immediate release and NB17 release, I'd like to include a very trivial springboot support - Micronaut module is a good enterprise cluster candidate to make homeplace for it.

The PR adds ability to run native compilation from the NetBeans IDE based on springboot plugin support. In addition, springboot projects are configured differently to micronaut projects - the changes in MicronautPackagingArtifactsImpl make the impl more compatible with various setups, as it now reacts on the plugin's goal regardless of whether the plugin is bound to the buildchain.

The maven module part is a necessary subtle API change - the friend API did allow to create RunConfigs for an explicit goal, but not for an (abstract) project action which is needed here, and uses possible user's customizations for the action (and therefore the goal). It fits well to the RunUtils API function set.

I'd like to include this PR into NB17 release.

[dbalek]

Looks fine as a temporary solution.

[neilcsmith-net]

In current state, -1 for NB17. Haven't looked at the details of the implementation, but if this is to be included in NB17 it needs to be based on delivery and all spec version changes removed.

I also don't see the justification for inclusion in NB17.

[MartinBalin]

I agree with what Neils says. But, without this fix which is needed for some of the GraalVM+SpringBoot support in VSNetBeans we will need to either diverge VSNetBeans code from NetBeans code or do a hacky solution elsewhere... I propose to do this and then fix it properly in master after NB17?

[neilcsmith-net]

@MartinBalin nothing stopping the changes going into delivery and NB17 if you want them there, as long as the PR is updated to allow merging to delivery.

@sdedic assertion above about spec versions is wrong. The Maven module is incorrectly configured here as far as I can see (comment inline with code). It is certainly skipped when spec versions get incremented. So we won't get a merge conflict with master, but should fix it I think? And once delivery is synced, increment again?

The base branch was changed.

[sdedic]

Rebased onto delivery. Maven's spec version changed to use = and to 2.157.0

Concerns addressed.

[neilcsmith-net]

Thanks! That looks OK to me from perspective of merging to delivery.

I'll leave @MartinBalin to review in full and handle merging.