-
|
What is the recommended way to have different versions of a particular dependency in the meta build? now I also need I was trying to define this in a separate package in the so that each of the respective A bit tangential, but it also seems to no
8000
t be possible to shared code down to the mill-build. For example, mill-build can't access the One thing I could think of is forgoing the mill-build thing entirely, and doing some hacky thing like this def compileMvnDeps = Seq(mvn"org.openapitools:openapi-generator:6.6.0")
def getCodegen = Task {defaultResolver().classpath(compileMvnDeps()).head}and then use Basically, I want to be able to write locally defined plugins, which can have their own set of independent dependencies, that I can use in my main project without having to publish those separately. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
@arminsumo typically for such scenarios, we use classloaders or JVM subprocesses to isolate the conflicting classpaths. See the docs below for examples: You can also look for examples of this in the Mill codebase, e.g. https://github.com/com-lihaoyi/mill/blob/main/libs/javalib/classgraph-worker/src/mill/javalib/classgraph/impl/ClassgraphWorkerImpl.scala |
Beta Was this translation helpful? Give feedback.
-
|
I see, that was kind of what I was assuming as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah there's definitely more that can be done to make this easier, although there are some hard boundaries that are enforced by the JVM only allowing a single version of any class on a classpath. It's not immediately obvious what the best way forward is, but maybe as you progress in migrating you'll end up with some helpers built on top of |
Beta Was this translation helpful? Give feedback.
-
|
I'm not as well versed in build tool internals as you are, so it may not be the correct way to think about it, but some things I have observed:
where each plugin has a compile time dependency on the respective openapi generator versions. So the only difference is that we want to define/build those locally as part of the main project build, instead of having them defined and pulled from externally. Seems like a very similar concept to the build.mill/package.mill system that's already in place to create independent modules, but we just want to use that in the build system itself, rather than to the application code. It seems like we are already achieving something like this with the suggest class loader strategy, so seems like it's possible to do that? But I am probably missing something crucial about the internals, that makes this unfeasible in reality. |
Beta Was this translation helpful? Give feedback.
@arminsumo typically for such scenarios, we use classloaders or JVM subprocesses to isolate the conflicting classpaths. See the docs below for examples:
You can also look for examples of this in the Mill codebase, e.g. https://github.com/com-lihaoyi/mill/blob/main/libs/javalib/classgraph-worker/src/mill/javalib/classgraph/impl/ClassgraphWorkerImpl.scala