Add a dependency tracking mechanism #607
Conversation
This facilitates the tracking of dependencies without imposing additional burden on the user to know what dependencies were used to generate code in upstream libraries/projects
modules/codegen-plugin/src/smithy4s/codegen/Smithy4sCodegenPlugin.scala
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| private lazy val simple = raw"([^:]*):([^:]*):([^:]*)".r | ||
| private lazy val cross = raw"([^:]*)::([^:]*):([^:]*)".r |
There was a problem hiding this comment.
just spitballing, could we use coursier's api to parse the dependency strings?
There was a problem hiding this comment.
and then how do you go from coursier dep to SBT dep ?
There was a problem hiding this comment.
dunno, if it was a structured parsing result we could probably do that - if there's no way then the answer to my question is "no" ;)
There was a problem hiding this comment.
Let's postpone this : right now the problem is more about "can we you render a dependency as a coursier-parsable string in both SBT and mill ?" Because I couldn't find a way to do that easily, I have the control over the format and parsing with coursier is not necessary as we're falling in the simplest possible cases (normal java dep, normal scala dep).
If it proves to be limitative we'll revise.
|
good stuff |
| and publish this project to an artifact repository, the Jar manifest will contain the following line : | ||
|
|
||
| ``` | ||
| smithy4sDependencies: software.amazon.smithy:smithy-aws-iam-traits:1.14.1 |
There was a problem hiding this comment.
may be worth noting that multiple dependencies are comma separated
modules/mill-codegen-plugin/test/src/smithy4s/codegen/mill/Smithy4sModuleSpec.scala
Outdated
Show resolved
Hide resolved
The same smithy4sDependencies metadata is now being populated for the artifacts published in the smithy4s repository
Baccata
force-pushed
the
dependency-tracking
branch
from
8cb3edd
to
ce19e26
Compare
| import org.portablescala.sbtplatformdeps.PlatformDepsPlugin.autoImport._ | ||
| import Smithy4sBuildPlugin.autoImport.isCE3 | ||
|
|
||
| object Dependencies { |
There was a problem hiding this comment.
moved this from build.sbt to be able to re-use in Smithy4sBuildPlugin
Baccata
force-pushed
the
dependency-tracking
branch
from
ce19e26
to
d952054
Compare
| @@ -174,7 +299,7 @@ object Smithy4sCodegenPlugin extends AutoPlugin { | |||
| output = os.Path(outputPath), | |||
| resourceOutput = os.Path(resourceOutputPath), | |||
| skip = skipSet, | |||
| discoverModels = true, // we need protocol here | |||
| discoverModels = false, // we need protocol here | |||
There was a problem hiding this comment.
| discoverModels = false, // we need protocol here | |
| discoverModels = false, |
I guess that comment can be removed now
|
something is not yes (this test wasn't running earlier because there was an
|
…ccount for codegen Now, by default, any library declared as a "normal" dependency, by means of `ivyDeps` in mill or `libraryDependencies` in sbt are used during the code-generation process. This makes Smithy4s more consistent with itself, as the same behaviour is applied to internal dependencies. It is also argueably more intuitive to do it this way.
This facilitates the tracking of dependencies without imposing additional burden on the user to know what dependencies were used to generate code in upstream libraries/projects.
Essentially, what it does is add a line in the manifest of project/modules that have the Smithy4s plugin enabled, tracking dependencies locally declared with
% Smithys. A bit of logic is added so that downstream projects that also haveSmithy4senabled automatically resolve these dependencies before running code-generation.Additionally, this PR changes the build plugins so that libraryDependencies are taken into account for codegen :
Now, by default, any library declared as a "normal" dependency, by means of
ivyDepsin mill orlibraryDependenciesin sbt are used during the code-generation process. This makes Smithy4s more consistent with itself, as the same behaviour is applied to internal dependencies. It is also argueably more intuitive to do it this way.Todo
Add the same mechanism in the Mill integration
Dogfooding : make sure that the artifacts published by this build (which do not use the Smithy4sCodegenPlugin, cause it's also published by this build) contain the correct line in the manifest, so that users don't have to add explicitly to their builds dependencies to protocol-test-traits, aws-traits, etc ...