Skip to content

✨ feat: Add resolved field#1148

Merged
LogFlames merged 41 commits into
mainfrom
995-add-resolved-field-with-url-to-a-downloaded-artifact-to-the-lockfile
Apr 16, 2025
Merged

✨ feat: Add resolved field#1148
LogFlames merged 41 commits into
mainfrom
995-add-resolved-field-with-url-to-a-downloaded-artifact-to-the-lockfile

Conversation

@LogFlames

Copy link
Copy Markdown
Contributor

See #995.

@LogFlames LogFlames linked an issue Mar 26, 2025 that may be closed by this pull request
@LogFlames LogFlames marked this pull request as draft March 26, 2025 15:47
@LogFlames

Copy link
Copy Markdown
Contributor Author

Will solve #1149 first.

@LogFlames

LogFlames commented Apr 6, 2025

Copy link
Copy Markdown
Contributor Author

TODOs:

  • Add RemoteChecksumCalculator
  • Add checks to IT to check for correctly ResolvedUrl

@LogFlames LogFlames marked this pull request as ready for review April 8, 2025 07:04
@LogFlames

LogFlames commented Apr 8, 2025

Copy link
Copy Markdown
Contributor Author

This PR is now ready for review, became quite a lot of lines changed as all integration tests had to be updated with the new resolved field.

@LogFlames LogFlames requested a review from algomaster99 April 8, 2025 08:25

@algomaster99 algomaster99 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overwhelming PR but great job. I have some comments on the implementation and some changes.

Comment on lines +5 to +21
public class DeprecationUtils {
public static String ChecksumModeDeprecation(String checksumMode, Log logger) {
if (checksumMode.equals("maven_local")) {
if (logger != null) {
logger.warn("Option 'checksumMode=maven_local' is deprecated. Use 'checksumMode=local' instead.");
}
return "local";
}
if (checksumMode.equals("maven_central")) {
if (logger != null) {
logger.warn("Option 'checksumMode=maven_central' is deprecated. Use 'checksumMode=remote' instead.");
}
return "remote";
}

return checksumMode;
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this wrapper? Does't the logging library support @Deprecated annotation?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would @deprecated be used to generate the warning message for the log? Or to mark the option?

We can deprecate a parameter, which in this case would be checksumMode. But it is not the parameter which is deprecated but the options for it.

Looking at it I don't think it is needed to separate this into its own thing. I wanted to make sure the upgrade from older versions of lockfiles were smooth but since the config is generated from Gson it doesn't seem to go through the Config constructor and could therefore not be automatically updated, will revert.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(P.s. sorry @ deprecated, not ment to mention you)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generate the warning message for the log? Or to mark the option?

Ideally, there should be a warning message at runtime also but I am not sure if @Deprecated provides that - it is only a compiler warning. I assumed the logging libraries would also support it and can log the usage of deprecated components.

Comment on lines +89 to +90
Path remoteRepositoriesPath = artifactFolderPath.resolve("_remote.repositories");
List<String> locallySavedRemoteRepositories = Files.readAllLines(remoteRepositoriesPath);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that since we depend upon maven resolver, we should have the URL information readily available. We have access to org.apache.maven.artifact.Artifact which has an API getDownloadUrl and I expected it to returned the "resolved URL" but somehow it returns null.

Steps I tried:

mvn clean install -DskipTests
mvnDebug io.github.chains-project:maven-lockfile:5.4.3-SNAPSHOT:generate # on any maven project with plugins and dependencies
project.getPluginArtifactMap().get("org.cyclonedx:cyclonedx-maven-plugin").getDownloadUrl() // returns null

I also tried deleting org.cyclonedx:cyclonedx-maven-plugin artifact from my .m2 folder but downloadUrl is still null. Probably a bug in maven?

I am up for implementation using _remote.repositories file, but like you mentioned that day this file is internal to maven. I would prefer an implementation where artifact comes with the URL it was downloaded using.

@LogFlames LogFlames Apr 8, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fully agree an implementation using public APIs is preferable!

I also tried a bunch to get the value out of the getDownloadUrl as well, when I was speaking about not finding it in the open API.

My best guess for why it is null is that maven resolves and downloads the dependency prior to plugins running and that we would need to create a maven core extension to access this information. However, we would not want to be forced to redownload all dependencies to capture their resolved url so we would still need to read this file or access other internals of maven resolver.

Maybe we could send a mail to a mailing list and ask if someone knows how to access the download url with a public API from a plugin? Apache dev?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the dependency prior to plugins running and that we would need to create a maven core extension to access this information.

I think the URL for dependencies was also null.

Maybe we could send a mail to a mailing list and ask if someone knows how to access the download url with a public API from a plugin? Apache dev?

Do ask them 👍 Maven Developer's List seems okay.

@algomaster99

Copy link
Copy Markdown
Member

It seems to have a lot of already merged commits. Could you rebase this branch with main?

@LogFlames

LogFlames commented Apr 8, 2025

Copy link
Copy Markdown
Contributor Author

Ill try a rebase, hopefully it'll go well ^^ Long history 😅

@LogFlames LogFlames force-pushed the 995-add-resolved-field-with-url-to-a-downloaded-artifact-to-the-lockfile branch from b9ca86c to c2542e4 Compare April 8, 2025 11:05
@algomaster99

Copy link
Copy Markdown
Member

Try converting the above class into record. We can merge this then. The implementation can be improved later according to what email response we get.

@algomaster99

Copy link
Copy Markdown
Member

We merge after updating README.

@LogFlames

Copy link
Copy Markdown
Contributor Author

@algomaster99 @massimeddu-sj note changes in RemoteChecksumCalculator to ensure consistency between RemoteChecksumCalcuclator and FileSystemChecksumCalculator when a checksum cannot be found.
See comment in #1149.

Comment thread README.md
@LogFlames LogFlames merged commit c73c947 into main Apr 16, 2025
@LogFlames LogFlames deleted the 995-add-resolved-field-with-url-to-a-downloaded-artifact-to-the-lockfile branch April 25, 2025 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add resolved field with url to a downloaded artifact to the lockfile

2 participants