NetCal / DNC

The NetworkCalculus.org Deterministic Network Calculator
http://dnc.networkcalculus.org
GNU Lesser General Public License v2.1
25 stars 23 forks source link

Move Extensions to Dynamically Discovered and Loaded Plugins #33

Open sbondorf opened 6 years ago

sbondorf commented 6 years ago

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).