You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (Jira)" <ji...@apache.org> on 2022/05/16 12:12:00 UTC

[jira] [Commented] (SLING-10790) BundleEntryHandler.extractArtifactId may use wrong GAV

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

Carsten Ziegeler commented on SLING-10790:
------------------------------------------

I refactored the code in https://github.com/apache/sling-org-apache-sling-feature-cpconverter/commit/68f71b3ba0a8f54c4d307e0ca179e7cc8a8c17c0 
It seems if we actually reset groupId etc. then a lot of tests start failing, therefore I didn't not do this. But at least the code is now a little bit easier to read

> BundleEntryHandler.extractArtifactId may use wrong GAV
> ------------------------------------------------------
>
>                 Key: SLING-10790
>                 URL: https://issues.apache.org/jira/browse/SLING-10790
>             Project: Sling
>          Issue Type: Bug
>          Components: Content-Package to Feature Model Converter
>            Reporter: Angela Schreiber
>            Priority: Minor
>             Fix For: Content-Package to Feature Model Converter 1.1.16
>
>
> [~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. {quote}it was the pom.properties  we were looking for{quote}.
> 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:
> {code}
>         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);
> {code}
> feel free to resolve as not a problem in case my reading of the code is all wrong.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)