Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move VersionMappings stuff to a separate module and make it public #13

Merged
merged 9 commits into from
Jan 5, 2023

Conversation

bjlaub
Copy link
Contributor

@bjlaub bjlaub commented Jan 5, 2023

No description provided.

@changelog-app
Copy link

changelog-app bot commented Jan 5, 2023

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

move VersionMappings stuff to a separate module and make it public

Check the box to generate changelog(s)

  • Generate changelog entry

@@ -17,7 +17,7 @@

import org.apache.maven.artifact.versioning.ComparableVersion;

final class VersionMapping {
public final class VersionMapping {

Choose a reason for hiding this comment

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

I suspect we'll need to make the getters public as well

@@ -17,7 +17,7 @@

import org.apache.maven.artifact.versioning.ComparableVersion;

Choose a reason for hiding this comment

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

I think this is an implementation dependency, so it can't be exposed with a public getter. Can we abstract it away somehow such that we're not bound to the maven ComparableVersion type?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so one alternative to this is that we could leave VersionMapping package-private, and instead change the public VersionMappings#getReplacement to return an Optional<MavenCoordinate> instead of Optional<String>. From the perspective of something outside of this module, a caller doesn't care so much with inspecting the individual parts of VersionMapping and likely only cares about asking "what is the replacement that will be used for this dependency?"

Choose a reason for hiding this comment

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

Sounds good to me, reducing the exposed surface is always a plus

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cool, fixed

Comment on lines 31 to 33
ComparableVersion getMaxJakartaVersionWithJavaxNamespace() {
return maxJakartaVersionWithJavaxNamespace;
}

Choose a reason for hiding this comment

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

Thoughts on removing this method entirely in favor of building ComparableVersion on an as-needed basis in VerssionMappings?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah we can do that

Copy link
Contributor Author

Choose a reason for hiding this comment

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

one downside is that it becomes less clear that this mapping could technically apply to a range of versions, but i think in practice there's only one Jakarta EE release with the old javax namespace, so it's really always a single version.

Comment on lines 192 to 194
public static Map<String, VersionMapping> getMappings() {
return mappings;
}

Choose a reason for hiding this comment

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

Perhaps this should return Collection<VersionMapping> since the key is an implementation detail for quick lookups? we could return mappings.values();

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 done

also make VersionMappings#getMappings return Collection<VersionMapping>
@bulldozer-bot bulldozer-bot bot merged commit d700ed9 into develop Jan 5, 2023
@bulldozer-bot bulldozer-bot bot deleted the blaub/split-packages branch January 5, 2023 19:47
@svc-autorelease
Copy link
Collaborator

Released 0.2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants