Skip to content

Move Extensions to Dynamically Discovered and Loaded Plugins #33

@sbondorf

Description

@sbondorf

We assemble the test configurations in DncTestMethodSources.java. Alternative Curve and Number Backends are hardcoded, even if they are non-essential extension (e.g., MPA RTC Curve Backend). I.e., we have a compile time dependency.

Can somehow make the tests look for "plugins" during runtime to break this compile-time dependency. I am thinking of a way that the plugin tells the test what it provides (e.g., a Num / Curve / Operator interface implementation) and the tests dispatch to it accordingly.

Using OSGi seems too much overhead to achieve this.

Some speculation: Can we put jar files into a plugin directory. Their names or a bundled descriptor file could probably follow a specific pattern that indicates capabilities (i.e., implemented interfaces). For example, the name pattern could be {short interface path/name}-{plugin name}.jar and RTC MPA code would then be in curve_CurvePwAffine-MPA_RTC.jar. We only hardcode the package prefix "de.uni_kl.cs.discodnc." in our code, the remainder would be found in the jar name. The example refers to the sub-package "curve" and implements interface CurvePwAffine (indicated by the capital letter). The name of our implementation is MPA_RTC and all the code needs to be in the de.uni_kl.cs.discodnc.curve package (this last point is subject to more refinement, in particular if we use a descriptor file instead).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestquestionFurther information is requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions