In testing, I noted that modlImplementation configuration handling was resolving transitive dependencies. To maintain consistency in behavior with the java-library plugin, it should NOT have.
Following discussion with some coworkers, I decided to simplify the dependency configurations to use only a single modlDependency configuration as a marking. The reasoning is that in the Ignition Platform, the distinction between 'consumable/api' dependencies and 'implementation' dependencies does not really exist. So either we have two different configurations that are effectively identical in everything but name, or, as my original comment stated, we alter the implementation version to not include transitive dependencies. The problem there is that you could very easily have a module that compiles/builds fine (as transitive dependencies are added to the compile classpath), but fails to run correctly due to missing dependencies due to transitive dependencies not being added to the modl.
In addition, I found that in single-project modules, the plugin was being applied before the version was readable. To account for this possibility, I've wrapped the jar archive name convention in an afterEvaluate closure, as we prefer to include the version in the jar filename by default, and do not want to duplicate our version definitions to do so.
Will publish as version 0.1.0-SNAPSHOT-17 (initial commit was published as 16)
In testing, I noted that modlImplementation configuration handling was resolving transitive dependencies. To maintain consistency in behavior with the java-library plugin, it should NOT have.Following discussion with some coworkers, I decided to simplify the dependency configurations to use only a single
modlDependency
configuration as a marking. The reasoning is that in the Ignition Platform, the distinction between 'consumable/api' dependencies and 'implementation' dependencies does not really exist. So either we have two different configurations that are effectively identical in everything but name, or, as my original comment stated, we alter the implementation version to not include transitive dependencies. The problem there is that you could very easily have a module that compiles/builds fine (as transitive dependencies are added to the compile classpath), but fails to run correctly due to missing dependencies due to transitive dependencies not being added to the modl.In addition, I found that in single-project modules, the plugin was being applied before the version was readable. To account for this possibility, I've wrapped the jar archive name convention in an afterEvaluate closure, as we prefer to include the version in the jar filename by default, and do not want to duplicate our version definitions to do so.
Will publish as version 0.1.0-SNAPSHOT-17 (initial commit was published as 16)