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

Generate Automatic-Module-Name attribute #1718

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

hubertp
Copy link

@hubertp hubertp commented Sep 25, 2024

It is currently impossible to define pureconfig on a module path. This is because Java fails to automatically infer Module name from jar's containing invalid characters (e.g. _ or - in _2.13 cross version). It's a common problem with Scala artifacts.

This change adds Automatic-Module-Name attribute to MANIFEST that contains a valid Java identifier that can be used to define appropriate module dependencies.

Also fixed a warning that was stopping the compilation for those who are on JDK 20 already.

It is currently impossible to define `pureconfig` on a module path. This
is because Java fails to automatically infer Module name from jar's
containing invalid characters (e.g. `_` or `-` in `_2.13` cross version).
It's a common problem with Scala artifacts.

This change adds `Automatic-Module-Name` attribute to MANIFEST that
contains a valid Java identifier that can be used to define appropriate
module dependencies.
@hubertp
Copy link
Author

hubertp commented Oct 14, 2024

Any problem with this PR? This should unblock anyone who wants to use pureconfig as a Java module, with a minimal effort.

@grzegorz-bielski
Copy link
Contributor

This is a nice addition.

cc @ruippeixotog, @jcazevedo

Copy link
Member

@ruippeixotog ruippeixotog left a comment

Choose a reason for hiding this comment

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

Hey @hubertp, thanks for the contribution. Is there anywhere where I can read more about Java module usages and Scala's recommended approach to this? As you said this seems to be a problem common to all Scala artifacts, so is there general guidance from the Scala team or the community? It seems strange for every project to require that small amount of boilerplate.

This LGTM in general, sending back you just just for minor adjustments.

@@ -15,9 +15,18 @@ ThisBuild / libraryDependencySchemes ++= Seq(
"org.scala-lang.modules" %% "scala-xml" % VersionScheme.Always
)

lazy val javaModuleName = settingKey[String]("Java Module name")
Copy link
Member

Choose a reason for hiding this comment

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

nit: can you please move this to after the projects are defined? This seems to be too niche and minor to be defined at the top of build.sbt.

@@ -44,6 +53,7 @@ def genericModule(proj: Project) = proj
.dependsOn(testkit % "test")
.settings(commonSettings)
.settings(name := s"pureconfig-${baseDirectory.value.getName}")
.settings(Seq(javaModuleName := s"${name.value.replace("-", ".")}") ++ publishSettingAutomaticModuleName)
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand why we're defining this only for core and generic modules. Don't other modules, like pekko-http and scala-xml, suffer from the same problem? If we can, we should skip the SBT setting boilerplate and just inline this into commonSettings.

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.

3 participants