sonatype-nexus-community/sonatype-platform-browser-extension

cannot find components with bundle packaging

hboutemy opened this issue · 5 comments

hboutemy commented

Describe the bug
components that have a "bundle" packaging cannot be evaluated
this is a regression introduced when solving "aar" packaging case in #85 / #87

To Reproduce
look at https://central.sonatype.com/artifact/org.scalatestplus/scalacheck-1-17_sjs1_3/3.2.17.0

this component is not recognized, because it is transformed to purl pkg:maven/org.scalatestplus/scalacheck-1-17_sjs1_3@3.2.17.0?type=bundle

Expected behavior
it should be recognized, because it should be transformed into purl pkg:maven/org.scalatestplus/scalacheck-1-17_sjs1_3@3.2.17.0?type=jar

Additional context
packaging in POM is not always the extension of the main file that will be published.

bundle packaging generates jar, and is widely used: https://central.sonatype.com/search?q=p%3Abundle
I'm sure there are others, but given the list of packagings that exist is open (anybody can create his own), it's not easy to list which packagings do which extension...
For example, Maven core ones are maven-archetype, maven-plugin. I just tested and these packaging cause the same issue

I don't know if using no type in the generated purl would work?
or type=pom? (any compoennt in Maven Central has a file with .pom extension

hboutemy commented

thank you @madpah for the quick fix, it works now for bundle because the transformation from bundle to jar in purl is hardcoded

but it does not work for maven-plugin: https://central.sonatype.com/artifact/net.sf.czsem/custom-properties-maven-plugin/4.0.3 nor maven-archetype: https://central.sonatype.com/artifact/io.kalix/kalix-maven-archetype-event-sourced-entity/1.3.3 nor probably every other case where a packaging produces a jar

and given I see the purl with ?type=maven-archetype but not ?type=pom, I'm not clear if the default pom switch has been tested

madpah commented

@hboutemy - are you able to provide some concrete rules that we can work to for this?

At present the rules essentially are:
Default to type=jar UNLESS

  • We find a POM on the current page and it contains <packaging> element
  • And the packaging value is NOT one of: bundle, pom, we use type=[packaging-value]

We can update cater for any requirement here, just need to get a clear steer from a Java Expert such as yourself @hboutemy

hboutemy commented

let's take an example:
https://central.sonatype.com/artifact/net.sf.czsem/custom-properties-maven-plugin/4.0.3 is not recognized
but https://central.sonatype.com/artifact/net.sf.czsem/custom-properties-maven-plugin/4.0.3/versions is
and https://repo1.maven.org/maven2/net/sf/czsem/custom-properties-maven-plugin/4.0.3/ also (and opening the .pom from there and evaluating freezes the browser: I suppose there is bug, but that's another story, and not a normal usage one)

is really type in purl necessary?
having a rule "no type" would be the best

and if type is absolutely necessary, si fixed type=pom ok?

if these 2 "no type" or fixed "type=pom" rules don't work, creating the list of all packagings that have to be transformed to type=jar will be cumbersome and incomplete, but the only solution (there is no algorithm other than "study the source code behind the packaging"). Sorry...

madpah commented

Understood @hboutemy - perhaps we can reverse the current change which was intended to provide a fix for #85 (where the packaged format was aar and not jar).

Seems like the default is safe as jar unless we know it should positively be changed.

brent-spiner commented

🎉 This issue has been resolved in version 2.10.7 🎉

The release is available on:

Your semantic-release bot 📦🚀