[ 
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865071#comment-17865071
 ] 

ASF GitHub Bot commented on MNG-8180:
-------------------------------------

cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674028547


##########
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##########
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
                             String artifactId = 
root.getChild("artifactId").getValue();
                             String goalPrefix = 
root.getChild("goalPrefix").getValue();
                             String name = root.getChild("name").getValue();
-                            return new PluginInfo(groupId, artifactId, 
goalPrefix, name);
+                            // sanity check: plugin descriptor extracted from 
artifact must have same GA
+                            if (Objects.equals(artifact.getGroupId(), groupId)
+                                    && 
Objects.equals(artifact.getArtifactId(), artifactId)) {
+                                return new PluginInfo(groupId, artifactId, 
goalPrefix, name);
+                            } else {
+                                throw new 
InvalidArtifactPluginMetadataException(
+                                        "Artifact " + artifact.getGroupId() + 
":"
+                                                + artifact.getArtifactId()
+                                                + " JAR (to be 
installed/deployed) contains Maven Plugin metadata for plugin "
+                                                + groupId + ":" + artifactId + 
"; coordinates are conflicting. "
+                                                + "Most probably your JAR 
contains rogue Maven Plugin metadata, "
+                                                + "possible causes may be: 
shaded in Maven Plugin or some rogue resource)");
+                            }
                         }
                     }
+                } catch (RuntimeException e) {

Review Comment:
   I might be missing something, intent is "throw all unexpected ones" (or, 
swallow all expected ones, like IOEx, XML parsing and Plexus XML ones, these 
are all checked ones).
   
   Also, the newly introduced IAPMEx is "unexpected" as well. All "unexpected" 
ones fails the build, while all the "expected" ones are swalled as were since 
1.9.0.





> Resolver will blindly assume it is deploying a plugin by presence of 
> META-INF/maven/plugins.xml in JAR
> ------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-8180
>                 URL: https://issues.apache.org/jira/browse/MNG-8180
>             Project: Maven
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 
> 3.9.8
>            Reporter: Tamas Cservenak
>            Assignee: Tamas Cservenak
>            Priority: Major
>             Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of 
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may 
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR, 
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST 
> BE aligned (artifact GA == metadata GA). In this case all is happening as 
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the 
> build, as deploying "formally adhering to maven plugin JAR with rogue 
> metadata" may be very misleading. Most probably the origin of "rogue" plugin 
> metadata is by shading (like in case of Tika), or by some other rogue 
> resource, or even someone "reinventing" the plugin metadata for some other 
> purposes. Maven should simply prevent install/deploy of artifacts like these, 
> and users should fix the artifact (in case of shading, exclude that resource, 
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata 
> generation happens in maven-resolver-provider module that does not and cannot 
> depend on maven-core (is "pure" resolver), hence notion of packaging, 
> project, build etc is not available. In Maven4 with new API we MAY do 
> something more later. The two PRs against 3.9.x and 4.0.0 are currently 
> identical.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to