This does not work for merging with text substitution for the same reason I mentioned in my previous comment, but you are right, it is include functionality.   I was probably biased towards the use case for which I created this thread. 🙂   Thanks. ... View more

Yes, that seems to be the best strategy.   I was experimenting with putting the text from different morphline files, each containing a single morphline, via string substitution (e.g., using the Apache Commons Lang StrSubstitutor class).   That approach does not work if you use text substitution in the morphline file, because in that case the "declarations' have to be outside the morphline, at the top of the file, so when the files are merged compilation fails.   It would have been nice if HOCON supported a C-style #include command. 🙂   Thanks for the advice! ... View more

I assumed so, but wanted to confirm that there is no state sharing "behind the scenes", especially in the Command building process.   Thanks for the confirmation. ... View more

Sure.   FreeMarker is a good idea, especially now that they have switched to the Apache 2.0 License.   ... View more

Hmmm...   You mean, read the morphline config file, do a text "search and replace" and then compile it?   The problem I described (having lots of config code replication) is very common, maybe you should look at providing a more "programatic" solution. 🙂 ... View more

Thanks for the prompt answer!   Adding to the Morphlines Reference Guide, the tryRules block has to be placed inside the commands block, e.g.   morphlines : [ { id : morphline1 importCommands : ["org.kitesdk.**", "org.apache.solr.**"] commands : [ { readLine { charset : UTF-8 } } { tryRules { catchExceptions : false throwExceptionIfAllRulesFailed : true rules : [ # next rule of tryRules cmd: { commands : [ { ... } { ... } ] } # next rule of tryRules cmd: { commands : [ { ... } { ... } ] } } } ] }     ... View more