Allow global registration of custom XStream converters.

[rankinc]

This lets us provide converters for any classes that we cannot annotate directly with @XStreamConverter. For example,

@XStreamConverters(
    @XStreamConverter(MyConverter.class),
    @XStreamConverter(MyOtherConverter.class)
)
@CucumberOptions(...)
@RunWith(Cucumber.class)
public class RunCukesTest {
}

The existing @XStreamConverter annotations are being reused for consistency. The RuntimeOptionsFactory will check for these annotations on the same class that has the @CucumberOptions annotation, which keeps this change nicely internal to cucumber-core.

[eduardmanas]

Nice one @rankinc!

This will enable using classes such as org.joda.time.DateTime without the need to annotate the method parameters with @Tranform all the time (which is a pain when the class is very common in your domain).

As an alternative, did you consider using @Transform instead of @XStreamConverters? For example, we could have re-used the @Transform annotation to annotate all Transformer implementations that should be automatically registered at start up.

@Transform
public class DateTimeTransformer extends Transformer<DateTime> {
    DateTimeFormatter dateTimeFormatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm");
    @Override
    public DateTime transform(String value) {
        return dateTimeFormatter.parseDateTime(value);
    }
}

[rankinc]

I did consider using @Transform instead of @XStreamConverter, yes. The problem is that Transformer extends SingleValueConverter, but my DataTable has more than one column.

However, if the principle of registering global converters in this way is acceptable then I don't see why we shouldn't register global transformers too.

TBH, I'm not a fan of using the @XStreamConverter annotation because its value is a ConverterMatcher rather than a Converter. I would prefer to use an annotation more like:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Documented
public @interface CucumberConverter {

    Class<? extends Converter> value();

    int priority() default 0;

}

However, I figured this pull would be more likely to be merged if it reused existing annotations ;-).

[davidyscott]

I just came across this in attempting to use this feature (which is excellent!) It looks like SingleValueConverters are treated separately from other Converters and are not type-compatible, so in order to properly use SingleValueConverters with the global registration, there would need to be a second if statement here to handle them.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.