Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MNG-5695] document Maven 3.2.5+ scoped components usage #236

Merged
merged 1 commit into from
Jan 6, 2024
Merged

Conversation

hboutemy
Copy link
Member

@hboutemy hboutemy commented Nov 5, 2023

clarify something which precise scope was unclear until now (at least to me)
=> update https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/


@Parameter( defaultValue = "${session}", readonly = true )
// @Parameter( defaultValue = "${session}", readonly = true )
@Component // since Maven 3.2.5, thanks to MNG-5695
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were discussing and leaning to the exact opposite.
Keep @Parameter for things injected from the config and @Component/@Inject for injecting beans, including those from the session (Session) and mojoExecution scopes (MojoExecution, Project)...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were discussing and leaning to the exact opposite. Keep @Parameter for things injected from the config and @Component/@Inject for injecting beans, including those from the session (Session) and mojoExecution scopes (MojoExecution, Project)...

This is exactly what I remember. Use @Parameter exactly for this case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were discussing and leaning to the exact opposite. Keep @Parameter for things injected from the config and @Component/@Inject for injecting beans, including those from the session (Session) and mojoExecution scopes (MojoExecution, Project)...

This is exactly what I remember. Use @Parameter exactly for this case.

But those components can also be injected with @Component, so this is weird to warn about something that is supported by sisu (because those are actually bound to scopes), while pushing users to a custom solution. Why only a few components would be accessible by name then ?
I would agree if we had a single annotation for both use cases, but that's not the case in Maven 3. I suppose we could try for the v4 api though.

Copy link
Member

@michael-o michael-o Nov 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were discussing and leaning to the exact opposite. Keep @Parameter for things injected from the config and @Component/@Inject for injecting beans, including those from the session (Session) and mojoExecution scopes (MojoExecution, Project)...

This is exactly what I remember. Use @Parameter exactly for this case.

But those components can also be injected with @Component, so this is weird to warn about something that is supported by sisu (because those are actually bound to scopes), while pushing users to a custom solution. Why only a few components would be accessible by name then ? I would agree if we had a single annotation for both use cases, but that's not the case in Maven 3. I suppose we could try for the v4 api though.

I agree that this is inconsistent. If both are valid and are functionally identical then the warning is wrong.

Copy link
Member Author

@hboutemy hboutemy Nov 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so do we all now agree that using @Component is better than using @Parameter( defaultValue = "${session}", readonly = true ) (because smaller and moreover we're sure there is no typo in the default value expression)?

if we agree, the warning could be to promote switch to @Component for ${session}, ${project} and ${mojoExecution}...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and do we all now agree that using @Component is better than using @Parameter( defaultValue = "${session}", readonly = true ) (because smaller and moreover we're sure there is no typo in the default value expression)?

if we agree, the warning could be to promote switch to @Component...

From my PoV, is this cannot be provided by POM or CLI means and it is unambiguous, then yes.

Copy link
Member Author

@hboutemy hboutemy Nov 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reading git blame on https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/JavaAnnotationsMojoDescriptorExtractor.java#L791 , I see that in the past, we (I :) ) implemented in plugin-tools a hack to replace @Component with an expression in the plugin descriptor: https://issues.apache.org/jira/browse/MPLUGIN-204

It was was done when we were with Maven 3.0.x, if it was before Maven 3.2.5 MNG-5695. With Maven 3.2.5, this hack is not useful any more for MavenSession, MavenProject nor MojoExecution: it remains useful for a few other types...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO there is no problem when JSR330 being used. Problem happens when Mojo APIs (java5 anno or javadoc annos are being used).


@Parameter( defaultValue = "${session}", readonly = true )
// @Parameter( defaultValue = "${session}", readonly = true )
@Component // since Maven 3.2.5, thanks to MNG-5695
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were discussing and leaning to the exact opposite. Keep @Parameter for things injected from the config and @Component/@Inject for injecting beans, including those from the session (Session) and mojoExecution scopes (MojoExecution, Project)...

This is exactly what I remember. Use @Parameter exactly for this case.

@hboutemy
Copy link
Member Author

hboutemy commented Nov 6, 2023

now that we've found back the MPLUGIN-204 hack, in the proposed update:

@Component // since Maven 3.2.5, thanks to MNG-5695

we could perhaps drop the comment on Maven 3.2.5 because the plugin transforms @Component with @Parameter, then it works with any Maven release
the only improvement that could be useful is to NOT transform but keep a real Plexus component if the plugin is targetting 3.2.5+: I don't know if this is feasible

@hboutemy
Copy link
Member Author

hboutemy commented Nov 6, 2023

in MPLUGIN-204 we advised using @Component (that would use the trick to transform to parameters in the plugin descriptor XML), but later we advised back: f8a946d
see https://issues.apache.org/jira/browse/MPLUGIN-257

@gnodet
Copy link
Contributor

gnodet commented Nov 6, 2023

in MPLUGIN-204 we advised using @Component (that would use the trick to transform to parameters in the plugin descriptor XML), but later we advised back: f8a946d see https://issues.apache.org/jira/browse/MPLUGIN-257

That's exactly what I don't understand. Since they are bound to a scope in plexus, they are plexus components, even if they have not been instantiated by plexus. They can be injected into other Plexus components, especially those from the plugin.

@hboutemy
Copy link
Member Author

before Maven 3.2.5, they were not Plexus components: then implementation in plexus-tools was a hack to replace with parameter in plugin descriptor XML

@hboutemy
Copy link
Member Author

hboutemy commented Nov 13, 2023

on latest discussions on Slack (I hate non-shared Slack diuscussions), there is also the @Inject options that IIUC completely avoids the plugin descriptor intermediate= <requirement> in https://maven.apache.org/ref/3.9.5/maven-plugin-api/plugin.html

I don't know if it works, never tried

@gnodet gnodet requested a review from michael-o November 14, 2023 07:06
@michael-o
Copy link
Member

Are we good to merge this? We have two approvals.

Copy link
Member

@slawekjaranowski slawekjaranowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michael-o
Copy link
Member

We also should remove replacements and worning form code:

https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/JavaAnnotationsMojoDescriptorExtractor.java#L791

changing only documentation users will be confused when use it

Right, it needs to be consistent. @cstamas, your turn.

@michael-o
Copy link
Member

I took the stab now and change the code: #253. Both PRs should go together in the next release.

@asfgit asfgit merged commit 25d920f into master Jan 6, 2024
@michael-o michael-o deleted the MNG-5695 branch January 6, 2024 22:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants