-
Notifications
You must be signed in to change notification settings - Fork 58
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
Conversation
|
||
@Parameter( defaultValue = "${session}", readonly = true ) | ||
// @Parameter( defaultValue = "${session}", readonly = true ) | ||
@Component // since Maven 3.2.5, thanks to MNG-5695 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a warning for such components ...
and Component is replaced by expression
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
There was a problem hiding this comment.
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)...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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}
...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
now that we've found back the MPLUGIN-204 hack, in the proposed update:
we could perhaps drop the comment on Maven 3.2.5 because the plugin transforms |
in MPLUGIN-204 we advised using |
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. |
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 |
on latest discussions on Slack (I hate non-shared Slack diuscussions), there is also the I don't know if it works, never tried |
Are we good to merge this? We have two approvals. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also should remove replacements and worning form code:
changing only documentation users will be confused when use it
Right, it needs to be consistent. @cstamas, your turn. |
I took the stab now and change the code: #253. Both PRs should go together in the next release. |
clarify something which precise scope was unclear until now (at least to me)
=> update https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/