Also note that Ant's configuration mechanism isn't just with setters. A <java> task for example can take any number of <sysproperty> sub-elements, and they get "injected" via addSysproperty(Environment.Variable sysp).
System properties can be supported in 2 ways:
1. On the configuration level using an expression language (a la Spring... yes.. Spring supports it ). This means that in the schema you'll be able to configure properties like: stopWordFile="$
/stopwords.txt". the "conf.dir" parameter can be replaced either from system properties, properties file, or other source. Eventually these properties
2. Using another annotation (say, @SystemProperty) which indicates the value should first be taken from the system properties and then converted to the required data type
It's the specifying of the converter class in the annotation that I don't like. It can be more implicit than that, like "magic"
The @Converter annotation is mainly aimed for user extensions. Indeed all the out-of-the-box plugins don't need to have it as default converters can be pre-registered to handle all the data types we need at the moment. For users who want to provide their own plugins, we need to provide them a simple mechanism to register converters and I found the @Converter annotation to be the simplest one.
We'd have setStopWordList(SolrFile f), and we'd only that setter after the system properties were in the mix.
As you said, I believe once we have system properties supported this will be a no brainer and indeed I believe this belongs to an earlier "properties substitution" phase (as mentioned above).
is there anyone building it?
Oh yes , but beyond that, this will open up opportunities to develop plugins to IDE's/TextEditors for Solr... even just for better support in writing the schema files with auto-completion, validation, etc...
Why do we need this magic in String-> Object conversion at all?
Well, my obvious response is because of the nature of Solr configuration which is text based while at runtime you're dealing with other data types. Of course you can just create String setters and do the conversion yourself, but why do that if you can have done automatically and keep your classes clean. Just to be clear, the magic is not really "magic" we can be very clear about what converters are supported out of the box and (as I mentioned above) with the @Converter annotation users can be more explicit in how they want the conversion to take place. Bottom line, in the end of the day you want to be able to focus and write the plugins as POJO's using properties of the correct data types and focus on the plugin's logic rather than also focusing on configuration logic.