#697: Migrate to JSR330

[jarmoniuk]

Migrating to JSR330. Notable find: removed the bogus duplicate of the ArtifactResolver component in AbstractVersionsUpdaterMojo (there are two which point to the same component).

Using constructor-style injection, as advised in the reference.

[jarmoniuk]

@slachiewicz @slawekjaranowski please review

[jarmoniuk]

@slachiewicz why did you close it without merging?

[jarmoniuk]

@slachiewicz @slawekjaranowski please merge ;)

[slawekjaranowski]

@ajarmoniuk was merged by direct push in commit: a54e87f instead of using GH gui

Another case for manual push is that this PR will be missing from auto generated releases notes.
@slachiewicz what is purpose for direct push it?

[jarmoniuk]

I see. Thanks for the explanation.

[slachiewicz]

this time i was forking from command line, not from GH ui. I've updated, rebased change before push to test it locally.

[slachiewicz]

maybe release note action configuration should be updated?

[slawekjaranowski]

As I know release-derafter only take list of merged PR .. so we should process all important changes by PR with merged status ... 😄

[slachiewicz]

i've updated release note with my merge PR plus few small styling updates

[slawekjaranowski]

We will see what will happen after next release note rebuilds ... try to re-run Release Drafter action

[slachiewicz]

all my changes dropped :( thx for explanation

[jarmoniuk]

@slachiewicz I've noticed that you're now trying to replace constructor-based injection with injecting fields. -- that is, placing the @Inject annotations next to fields. While this is certainly possible, it's not advised to do so.

Please see https://github.com/eclipse/sisu.plexus/wiki/Plexus-to-JSR330#Basics

[slachiewicz]

Yes, i expect that without constructors it will be easier to refactor code to not use deprecated classes from Maven 2.
Someone can migrate Mojo one by one.
Later we can introduce constructors with new proper parameters.