-
Notifications
You must be signed in to change notification settings - Fork 73
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
Pull dependencies rather than scanning the build classpath #201
Pull dependencies rather than scanning the build classpath #201
Conversation
) | ||
.settings( | ||
libraryDependencies += Dependencies.Smithy.model, | ||
javacOptions ++= Seq("--release", "8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍, but we might want Xlint still
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at least, in the JVM 11, javac -Xlint
did not seem to be a thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work 👍
Pull dependencies rather than scanning the build classpath
TLDR:
protocol
a java lib (move test in another module)If you have jars in your sbt classpath that contains smithy files, the content is taken into account and codegen will produce code accordingly.
In some context, users can be completely unaware that they're pulling such dependencies and may not understand why codegen has produced such code.
In other scenario, it straight up break the build because the generated code conflict with some stuff already on the classpath.
We avoid the issue here by using explicit dependency on :
protocol
(local project) andsmithy-model
.We have to make sure that
protocol
is published locally for all jvm version before running the codegen scripted tests.