pass custom input into Corb Task

[Luiz-N]

Corb2 has the option to pass in a custom input however this does not seem possible with the current implementation of the ml-gradle corbTask. As a workaround I'm using the "collectionName" property to pass in a string but I think a more robust and native solution would be of value.

I feel the relevant place for this would be here where any task properties not found in the default corb options list can be added. The official docs say to add it as a property to uris-modules but i'm not quite sure how that would work in this context and thought I'd share before attempting a PR.

Thoughts?

[rjrudin]

@hansenmc Thoughts on this?

[hansenmc]

The easiest way to set custom input options would be to set them in an options file.

We could also adjust how the system properties are collected. Rather than look for a system property that matches the CoRB option name, we could test whether it starts-with() that value. Then you could set the custom input with a system property - which could be specified on the commandline -DURIS-MODULE.myCustomProp=foo.

The issue with trying to support CoRB custom inputs as task properties is that the properties names are not known prior to being sent in. The ml-gradle CorbTask initially defines a static set of option names, but tries to collect the list of options names from the CoRB options class in case a newer version of CoRB is being used that has new options that were not listed in the ml-gradle CorbTask. Each of those options names are set as member variables (normalized with lowerCamelCase naming convention) on the ml-gradle CoRB task.

[Luiz-N]

Perhaps i'm missing something but does the property name need to be known by the ml-gradle CorbTask before being sent in? My thinking was that if a property passed in via the gradle task does not match any of the known option names it could then be treated as a custom input and assigned to the uris-module dynamically before being passed along to corb.

My current use case requires passing in a host, username, and other relevant inputs into corb that would feel redundant and overly-verbose to be passed in via the commandline.

[hansenmc]

Can you share an example code snippet demonstrating how your task is defined and how you were expecting to set the custom input property on the task?

Assuming that the task member variable is set, we could change the handling of those that are not an exact match in the place that you suggested.

However, the CoRB options are normalized into camelCased CorbTask member variable names(to have a java/groovy friendly name), and when the names are matched, they are then normalized back into their actual CoRB option (i.e. optionsFile => OPTIONS-FILE). For custom inputs, I guess you could test whether it starts-with any of the custom input property names and it's string-length is longer than, such that urisModuleFoo starts with urisModule and would produce URIS-MODULE.Foo or processModule_bar starts-with processModule and would produce PROCESS-MODULE.bar.

We would have to decide on a convention or regex pattern for those custom properties that would handle either/both simply removing the "." or converting "." into "_", and would probably not normalize the second half of the custom option to be camelCased, since we wouldn't know how to "un-camelCase" that value. In the preceding example, knowing whether urisModuleFooBar should produce URIS-MODULE.fooBar, URIS-MODULE.FOOBAR, URIS-MODULE.FooBAR, etc.

Although I think we should support custom properties if we can, it is important to point out that you can set CoRB options in an options file, task properties, project properties, and system properties, and can mix-and-match. It is not a mutually-exclusive decision. For instance, you could specify your custom inputs as options in the OPTIONS-FILE and set standard/common options, such as the XCC connection info in project properties for the same task execution.

[rjrudin]

@Luiz-N and @hansenmc Is there something to be done here then?

[rjrudin]

@hansenmc Sounds like this is addressed via PR #153 as well? I think yes, so I'm closing - will be in ml-gradle 2.5.0, which I'm preparing now.

[hansenmc]

Yes, I believe that it helps a little, providing one more option for setting custom inputs.

In order to fully address the stated requirement, we would need to decide on a pattern for converting the project property names into CoRB options. Since it involves an unknown portion, we won't know whether to lowerCase, upperCase, or preserve (or maybe set all three and see which one "sticks" when invoked). Unless there is a burning need, I think it's fine to be closed.