smartics generator includes redundant module definitions #184
Comments
|
We can help to guard against this by adding unwanted libraries into 'dependencyExcludes' on the smartics plugin configuration. Seems to work fine for commons-logging. I'll see what else can be excluded. |
|
With the manual process that we had before there was the danger of missing dependencies. Unknown code paths could run into class not found errors. With an automated approach there is the danger of dependency duplication or otherwise invalid module definitions. Modules may get generated that already exist in the platform somewhere or cannot be supported. By generally excluding dependencies via 'dependencyExcludes' we create problem one again for the automated approach. Ultimately, I believe some human intelligence will always be required to make the ultimate decision. Smartics could be used to make a proposal, that after being reviewed can make it upstream. Specifically I suggest, we review the existing module list carefully now and make sure we don't already have invalid module definitions (e.g. sun jdk deps, license issues, etc). Then we generate to a location that does not automatically make it into the patch and is under SCM control. Every delta in the smartics output would be visible in the git diff. We can see, review and comment on proposed changes before they make it into the patch. |
|
|
|
I've done a bit more work on this and the results can be found at commit a1d124e. There's also some additional documentation here. I went through several iterations of trying to get something working with standalone scripts and attempting to modify the smartics plugin. I've settled on a simple Groovy script which does some comparisons between the wildfly camel module dependencies and those supplied with the wildfly app server. Using Groovy at least keeps the build cross platform. It's not 100% foolproof. Since it's comparing Maven group / artifact ids, there are scenarios where duplicate dependencies can slip though. E.g with netty where WF uses the 'super' netty-all jar but WF camel uses a selection of individual netty jars. In this instance it'll be for code review to rectify. |
|
Does this generate to a location that goes not automatically into the patch and is under SCM control? |
Currently there is no mechanism that guarantees the correct wiring to existing wildfly modules. As a result, redundant/incorrect module definitions are being generated.
org/apache/logging for example
We support every module we ship. Therefore, its important that we only ship what we can support ;-)
If this cannot be automated, we may need to use smartics to generate the next module definition "suggestion" and have an additional review + copy step.
An alternative may be to maintain an list like above in scm and make sure that every change to the list must manually be endorsed.
The text was updated successfully, but these errors were encountered: