Hi - I'm working on a support tool that enables the bulk creation and management of Intrscope alerts for a client (the client requires hundreds of alerts to be created and managed, and via the UI is too time consuming). I'd like to open source the code, however I'm unsure if I can include the IntroscopeManagementModule.xsd schemas in the publicly available code for this tool - can anyone advise me if there are licensing restrictions that would prevent me from including the schema in the code. Thanks in advance, Iain.
Chris_Kline, can you answer that?
Hi irmac. We're glad you're helping with the community assets! We would prefer that you allow the user to point to the Introscope home directory and then extract the necessary file(s) at runtime rather than rely on a separate distribution of them. This type of linking will be more flexible if locations change over time.
Thanks for the quick response - much appreciated. The tool doesn't actually need to use the xsd's at runtime, they are used during development to generate classes via JAXB compilation, and the schema's themselves aren't bundled with the application. I wanted to include them to give other developers the freedom to recompile with custom bindings should they so wish. I'll not include the schema's in the codebase and direct developers to use the schemas in the Introscope home directory if they want to recompile.
The last time I looked into the management module schema, the delivered xsd was incomplete since it was missing the ADS section. Had a support case and was finally told that the ADS were validated with code and not the xsd.
If you found this has changed, please comment to this thread. Was looking into how to parse a management module to find any corruption.
I've had the same problem - I'm working with older version of the product (9.1,9.5), so can't comment on whether the missing elements are present in the schema for the newer versions. Looking at the xsd's I got the impression that the schemas were generated from example management module xml files using altova xml spy, and that perhaps the xml used didn't contain the ADS element, hence it being missing in the generated XSD - could be totally wrong though!
This was an issue when marshalling/unmarshalling jaxb bindings - so I resorted to adding the ADS definition back into the xsd manually prior to running the jaxb compilation just to get the complete set of objects.
Would be very interested to find out if this has been resolved.