Use new metadata struct for dependency metadata

paketo-buildpacks / libjvm

A library and helper applications that form the basis for building the different Paketo-style JVM-providing buildpacks

Apache License 2.0

19 stars 20 forks source link

Use new metadata struct for dependency metadata #312

Open c0d1ngm0nk3y opened 12 months ago

c0d1ngm0nk3y commented 12 months ago

needs https://github.com/paketo-buildpacks/libpak/pull/283 (libpak v2)

Summary

Use the newly introduced DependencyLayerContributorMetadata as metadata rather than the whole dependency.

Use Cases

Using the complete dependency for using reflect.DeepEqual has sometimes strange results and even lead to very specific coding in libpak. This would simplify things.

Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

c0d1ngm0nk3y commented 9 months ago

Since this requires libpak v2, we will have to wait...

dmikusa commented 9 months ago

If you want to rebase this against https://github.com/paketo-buildpacks/libjvm/tree/release-2.x we could move this forward.

c0d1ngm0nk3y commented 9 months ago

If you want to rebase this against https://github.com/paketo-buildpacks/libjvm/tree/release-2.x we could move this forward.

It still needs the latest changes to be released, but at least it is already on the right base branch.

c0d1ngm0nk3y commented 5 months ago

@dmikusa Do you know what the plan for v2@libpak is?

dmikusa commented 5 months ago

It needs a bunch of work, I think there are some stories tagged as v2. It also just needs someone to go through and do updates like removing ioutil, switching to use t.Setenv and other clean up. I think there's probably also some of the structures that we want to rethink. There have been some pain points, some parts of the code that have grown a little tricky to manage and this v2 is a chance to revisit those and see if we can improve the situation.

I haven't personally had much time to work on it, as I've been focused on the ARM64 efforts. When we get that shipped, I will probably try to circle back to this. I don't think there's a huge rush to get v2 released, but it is a bit of a pain since we're maintaining both v1 and v2 for the time being.