search

jsedding / osgi-ds-metatype-diff

Tool to show the difference in Declarative Services and MetaType metadata of two OSGi bundles
4 stars 3 forks source link

wrap osgi-ds-metatype-diff in a maven plugin #10

Open justinedelson opened 5 years ago

justinedelson commented 5 years ago

As (sort of) discussed in https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/1741, it would be beneficial to that project (and I'm sure others) to be able to run osgi-ds-metatype-diff inside a build process (similar to the baseline goal).

This plugin would need to:

  1. Download the latest release (similar to what baseline does).
  2. Run the diff.
  3. Report differences.
  4. Fail under a configurable set of circumstances or probably more precisely fail if there are any differences except for a specific whitelist.

Based on the basic IT I created in ACS AEM Commons, I'd suggest that the following types of whitelists be supported:

  1. by property name (e.g. any change to a property named X is OK) -- for things like service.vendor
  2. by component name+property name (e.g. any change to a property named X in a component Y is OK)
  3. by component name+property name+change type (e.g. to allow changes to the type of a specific property, but not the serialized default value)

@jsedding WDYT?

jsedding commented 5 years ago

@justinedelson I agree that usability of this tool could benefit from more seamless integration into the build process.

I have considered what you suggest, however, I believe that it may be better to a utility to leverage the comparison in unit or IT tests.

Creating a mechanism similar to the bnd's baselining would be possible, but it would raise the question on how you tell the tool that certain changes are intended and may therefore pass. For baselining this is achieved by raising the export version, which is part of the code-base. For OSGi metadata diffing this would need to be handled differently. I cannot currently imagine a solution to this problem, let alone a simple or intuitive one.

On the other hand, it would be relatively simple to extract all of a bundle's metadata into the test/resources folder of a project and running an automated test that allows comparing the metadata in the test/resources with the generated metadata in the bundle. I suspect such a test would need to run during maven's integration-testing phase. When evolving the bundle, the test would fail if there are changes to the metadata. To resolve the test failure, the metadata in test/resources would need to be adjusted accordingly (and could be done simply by extracting the bundle's generated metadata and overwriting what's there). An added benefit is that it causes the history of the bundle's metadata to be maintained together with your code-base in an SCM.

All this said, I currently don't have the spare cycles to work on such an enhancement. Should you find the time to work on a PR, then I'll do my best to make time for reviewing it.