in a source.jar, the pom is not inculded by default but can be if specified :

https://maven.apache.org/components/plugins-archives/maven-source-plugin-3.0.1/jar-mojo.html#includePom

• some maven origins contain a zip instead of a jar, and in that case it looks like the pom.xml is included (ex : https://webapp.staging.swh.network/browse/origin/directory/?origin_url=https://repo1.maven.org/maven2/org/jboss/snowdrop/snowdrop)

• in some cases, the pom is included in a subdirectory of META-INF (ex : https://webapp.staging.swh.network/browse/origin/directory/?origin_url=https://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.jakarta-regexp&path=META-INF/maven/org.apache.servicemix.bundles/org.apache.servicemix.bundles.jakarta-regexp)

• in some cases, the pom.xml is directly in the sources.jar (if the includePom option of maven source plugin has been set to true) (ex : https://webapp.staging.swh.network/browse/origin/directory/?origin_url=https://repo1.maven.org/maven2/org/glassfish/packager/glassfish-appclient/3.1/glassfish-appclient-3.1-sources.jar)

I think the simplest way to get the pom file associated to a specific release of a maven package is to download it from the folder where we can find the source jar.

For instance with that maven origin, the source jar the 0.1.2 release is downloaded from that folder.

The associated pom file can also be found in that folder.

All maven packages seem to follow that convention about the files that can be downloaded.

Hi @anlambert, @bchauvet ,

Congrats on the work done! I think that downloading the pom file from the same folder is indeed the way to go.

AFAICR we had a discussion about this mapping (poms <-> jars) and I vaguely remember that it works in one way (i.e. if there is a jar, then there is a pom) but not the other way around (i.e. there are many poms without any jars). As a matter of fact, I've spent the last 30 minutes randomly crawling through various maven repositories and I could not find a single example of a missing pom when there is a jar (or zip..).

So I assume it would work.

I'm not sure to understand the intent, as we already keep the pom in the extrinsic metadata (don't we?).
Double-checking in the SWH codebase, I believe you could build upon this: see [1] lines 166-180.

[1] https://forge.softwareheritage.org/source/swh-loader-core/browse/master/swh/loader/package/maven/loader.py;d925d06e6f1a51a4a7e8f0d1250a1c3bc45db891$166?as=source&blame=off

HTH, cheers!

You're right boris, indeed it's already stored as extrinsic metadata, we hadn't checked properly :)
Thank you for your answer !

@douardda @bchauvet @anlambert ^

To summarize, the initial intent was to adapt the jar loaded (as extracted directory) to append the pom.xml so we do not lose that reference.

But then there exists jar artifacts that do append the pom.xml.
It all depends on how the developers do declare in their pom how to build the "*sources*.jar".
So then the plan became "reference the pom as extrinsic metadata".
But now, as @borisbaldassari mentions, it's already the case.

So in the end, the conclusion is that the loader already does the right thing so it's a noop, right?

Good news *can* happen, ahah! Thanks for notifying me.

Have a great day, cheers!

So in the end, the conclusion is that the loader already does the right thing so it's a noop, right?

Yes, we can close this task as invalid and deploy the maven loader to production \o/

Yesss! \o/