Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
kpauls, if my reading of BundleEntryHandler.extractArtifactId is correct it the method might be ending up using the wrong groupId/artifactId/version.
the code will loop over jar-entries and stop if the extracted GAV matches the bundle name. however, groupId/artifactId/version are not reset to null in case they were successfully extracted but didn't end up matching the bundle name i.e.
.it was the pom.properties we were looking for
i can't tell how big of an issue that is (and how likely). but given the fact that there is some extra effort to verify that the parsed pom is actually the right one, it might actually be relevant. the relies on a compliant content package that does contain a matching pom, which may or may not be the case...
logging a warning or throwing a ConverterException in case of violation might help spotting troublesome content packages instead of getting some sort of side effect if another pom was spotted.
a heavily simplified copy of the method:
String artifactId = null; String version = null; String groupId = null; String classifier = null; for (Enumeration<JarEntry> e = jarFile.entries(); e.hasMoreElements();) { [...] // extract groupId/artifactId/version [...] if (groupId != null && artifactId != null && version != null) { // bundleName is now the bare name without extension String synthesized = artifactId + "-" + version; // it was the pom.properties we were looking for if (bundleName.startsWith(synthesized) || bundleName.equals(artifactId)) { [...] // no need to iterate further break; } } } if (groupId == null) { [...] } return new ArtifactId(groupId, artifactId, version, classifier, JAR_TYPE);
feel free to resolve as not a problem in case my reading of the code is all wrong.
Attachments
Issue Links
- relates to
-
SLING-10784 BundleEntryHandler - sonar findings
- Open