The MPP plugin builds jars for each module/subproject in a multi-project build. Intellij's JPS (IDE build system) uses classes. The latter is faster and scales better with more modules though requires more heap memory.
The goal is to rebuild the proper classpaths substituting class output directories for the project dependencies.
Must be recursive so as to support transitive internal dependencies (typically declared as api dependencies vs implementation)
Follows MPP conventions of how common source sets are handled with each target (see NOTE at bottom)
Does not include external dependencies
Does not include composite build support (IDE or Gradle generated)
Spike
[ ] Is it possible to precisely target the correct source sets within a gradle subproject using dependencies provided by the MPP plugin (aka, are we going to have to resort to parsing metadata or more brittle measures)?
[ ] Does the MPP plugin support .getAllDependencies() or an equivalent?
[ ] Does the MPP plugin retain project dependencies in their dependencies function?
Bonus
[ ] Ability to turn it on/off for particular targets globally for that build (don't implement this in the DSL)
[ ] Test if this works with composite builds constructed in the IDE or by Gradle from build scripts or command line. Write up some followup tickets.
NOTE
One thing to watch out for is I think that the MPP plugin currently puts common on the same classpath as its target classpaths directly (vs adding it as a source directory for the target source set). We should keep in line with this convention as it might reduce IDE indexing and ensure compatibility with various IDE MPP features delivered through the Kotlin IDE plugin.
The MPP plugin builds jars for each module/subproject in a multi-project build. Intellij's JPS (IDE build system) uses classes. The latter is faster and scales better with more modules though requires more heap memory.
The goal is to rebuild the proper classpaths substituting class output directories for the project dependencies.
api
dependencies vsimplementation
)Spike
Bonus
NOTE One thing to watch out for is I think that the MPP plugin currently puts common on the same classpath as its target classpaths directly (vs adding it as a source directory for the target source set). We should keep in line with this convention as it might reduce IDE indexing and ensure compatibility with various IDE MPP features delivered through the Kotlin IDE plugin.