org.csstudio.java now depends on Eclipse plug-in

[willrogers]

The plug-in org.eclipse.java says in its manifest: "Java Utilities, no dependencies to Eclipse". However, this was recently changed by the timestamp formatting changes, which require org.eclise.equinox.preferences.

You wouldn't expect this to cause a problem, but it has: the standalone EDM converter jar build depended on this, and there's no easy way to include the Eclipse depdency in that build.

We have a couple of options:

• pull ./src/org/csstudio/java/time/TimestampFormats.java into another plugin that has an Eclipse dependency
• copy ./src/org/csstudio/java/string/StringSplitter.java into the EDM converter plugin as well and rely on it not changing very much

Any ideas?

[kasemir]

How about moving the TimestampFormats from org.eclipse.java into the apputil plugin? apputil.ui already has the UI components for start/end time, and plain apputil has the non-UI start/end time code.

[willrogers]

That works well for me. @boryto, was it you who made the changes to org.csstudio.java? Would you be happy with this change?

[boryto]

Yes, this OK. We just have to be careful about the plugin namespace change, as we override the default preferences in global plugin customization.

[willrogers]

org.csstudio.logging depends on this, and that's in core. Is it ok for core to depend on applications?

[kasemir]

Maybe copying ./src/org/csstudio/java/string/StringSplitter.java into the EDM converter plugin is the safer option after all. That'll fix your EDM converter build issue, and doesn't mess with the plugin depdendencies. If you find a better solution, check that the final product can still prompt for a workspace, i.e. doesn't accidentally already set the workspace because some plugin that was loaded early had to e.g. look for preferences and thus set the workspace.

[kasemir]

As a for-what-it's-worth, the EDM converter could also add an RCP -application definition.

Similar to the MEDM converter, #2342, it would then be built into the CSS product, be usable from the UI, but in addition one could call it from the command line as something like

css -nosplash -application org.csstudio.opibuilder.edmconverter /path/to/file1 /path/to/file2

Advantage: It's all in one product, no need for a separate build of the standalone converter. A dependency of the converter code on org.eclipse would then not matter.

On the other hand, that should not be an excuse to needlessly add depdencencies.

[willrogers]

True, this would make sense.

[kasemir]

I'm at this time not volunteering to do that, but maybe you have somebody who can check https://github.com/ControlSystemStudio/cs-studio/pull/2343/files for what's needed:

• Create an Application
• In there, check the (String []) context.getArguments().get("application.args")
• Maybe ignore some arguments that we always get because of the css.ini
• List that Application in the plugin.xml

..rest is pretty much like what you'd have in any Java main()