Exporting to StaMPS fails with java.lang.NoSuchFieldException: UNIT

Exporting to StaMPS fails on current master with the following stack trace:

Error: [NodeId: StampsExport] java.lang.NoSuchFieldException: UNIT
org.esa.snap.core.gpf.graph.GraphException: [NodeId: StampsExport] java.lang.NoSuchFieldException: UNIT
	at org.esa.snap.core.gpf.graph.NodeContext.initTargetProduct(NodeContext.java:79)
	at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:199)
	at org.esa.snap.core.gpf.graph.GraphContext.initOutput(GraphContext.java:166)
	at org.esa.snap.core.gpf.graph.GraphContext.<init>(GraphContext.java:85)
	at org.esa.snap.core.gpf.graph.GraphContext.<init>(GraphContext.java:58)
	at org.esa.snap.core.gpf.graph.GraphProcessor.executeGraph(GraphProcessor.java:118)
	at org.esa.snap.core.gpf.main.DefaultCommandLineContext.executeGraph(DefaultCommandLineContext.java:86)
	at org.esa.snap.core.gpf.main.CommandLineTool.executeGraph(CommandLineTool.java:547)
	at org.esa.snap.core.gpf.main.CommandLineTool.runGraph(CommandLineTool.java:391)
	at org.esa.snap.core.gpf.main.CommandLineTool.runGraphOrOperator(CommandLineTool.java:287)
	at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:188)
	at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:121)
	at org.esa.snap.core.gpf.main.GPT.run(GPT.java:55)
	at org.esa.snap.core.gpf.main.GPT.main(GPT.java:34)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.esa.snap.runtime.Launcher.lambda$run$0(Launcher.java:55)
	at org.esa.snap.runtime.Engine.runClientCode(Engine.java:189)
	at org.esa.snap.runtime.Launcher.run(Launcher.java:51)
	at org.esa.snap.runtime.Launcher.main(Launcher.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
Caused by: org.esa.snap.core.gpf.OperatorException: java.lang.NoSuchFieldException: UNIT
	at org.esa.s1tbx.insar.gpf.StampsExportOp.initialize(StampsExportOp.java:219)
	at org.esa.snap.core.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:528)
	at org.esa.snap.core.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:298)
	at org.esa.snap.core.gpf.Operator.getTargetProduct(Operator.java:385)
	at org.esa.snap.core.gpf.graph.NodeContext.initTargetProduct(NodeContext.java:77)
	... 26 more
Caused by: java.lang.Error: java.lang.NoSuchFieldException: UNIT
	at javax.measure.unit.Unit.asType(Unit.java:172)
	at javax.measure.unit.NonSI.<clinit>(NonSI.java:667)
	at org.esa.s1tbx.commons.CRSGeoCodingHandler.<init>(CRSGeoCodingHandler.java:62)
	at org.esa.s1tbx.commons.CRSGeoCodingHandler.<init>(CRSGeoCodingHandler.java:47)
	at org.esa.s1tbx.commons.CRSGeoCodingHandler.<init>(CRSGeoCodingHandler.java:41)
	at org.esa.s1tbx.insar.gpf.support.ProjectedDEM.createTargetProduct(ProjectedDEM.java:65)
	at org.esa.s1tbx.insar.gpf.support.ProjectedDEM.<init>(ProjectedDEM.java:56)
	at org.esa.s1tbx.insar.gpf.StampsExportOp.initialize(StampsExportOp.java:205)
	... 30 more
Caused by: java.lang.NoSuchFieldException: UNIT
	at java.lang.Class.getField(Class.java:1703)
	at javax.measure.unit.Unit.asType(Unit.java:170)
	... 37 more

(the stack trace is obtained running GPT, but the same problem manifests when using the graphical interface)

The problem does not originate in SNAP’s code, but in the initialization of the dependency net.java.dev.jsr-275.jsr-275, which searches for the UNIT field in interface javax.measure.quantity.Volume. The problem is that class Volume exists twice in the classpath: the first copy is provided by jsr-275, and correctly has the UNIT field. But another copy is provided by package javax.measure.unit-api, and does not have the UNIT field. The class resolver finds the copy without the field, and the exception is thrown.

I don’t think that the classpath should contain two copies of the same class, because it is impossible for the Java resolver to find which one is requested. But I could not undertand where to untangle the dependency graph to remove unit-api.