The existing QSAR loading mechanism for DescriptorEngine depended on the fact that there were physical 'jars' to search for implementations. This of course isn't always the case and switching the maven the test's don't run as 'jars' and can't load the descriptors. The engine now uses the input Service Provider Interface (SPI). This also eliminates the use of int parameter to specify which descriptors to load.
new DescriptorEngine(IMolecualrDescriptor.class, builder); // previously int MOLECULAR = 3 new DescriptorEngine(MOLECULAR, builder);
The service loader also simplifies users adding custom descriptor. Instead of pulling by search the packages the SPI 'pushes' the implementations to the loader.
One issue was the qsarionpot and qsarprotein are higher in the hierarchy and so can not be run in DescriptorEngine test. This was always the case but was simply silently not picking them up. To correct these would need their own seperate 'org.openscience.cdk.qsar.IMolecularDescriptor' classes. This is not possible because the current build can't put two different files of the same to different jars in the output. Alternatively perhaps qsarionpot (3 classes) and qsarprotein (2 classes) could be merged back to qsarmolecular etc. Modules are great but in this case I'm not sure there's a use case for the overhead.
This was part of the module-unification but I realised this could actually be added separately.
Log in to post a comment.