> On Nov 6, 2014, at 6:43 AM, Andy Seaborne <[email protected]> wrote:
> 
> 
> Hi Mark,
> 
> 
> On 05/11/14 15:22, Mark Feblowitz wrote:
>> I have a collection of various demonstrators that make use of
>> fuseki-server.  Each requires essentially the same config file to
>> configure the various services, differing only in the tdb store
>> location.
>> 
>> Currently it’s either/or: use a config file or use --loc on the
>> command line, but not both.
> 
> A configuration file can have several definitions in it so there is not one 
> location to override with "--loc”.

I thought that might be the case.

> 
>> It would be great to be able to override the location from the
>> command line. In that way, I can provide a single config file along
>> with instructions for each demo that include a location override.
> 
> What I usually do is write a little wrapper to invoke Fuseki that takes a 
> template file, string-replaces some key string with the required specific 
> value, and runs with the instantiated template.

Good idea - I’ll build that into my patch process.

> 
>> Interestingly, one can specify locations both using --loc and in the
>> config file; the store gets created, but rather than fuseki-server
>> using it, this message is displayed and fuseki-server terminates:
> 
> Bug.
> 
> Which location gets a store created? The --loc or the one in the config file?

command line location gets populated.

> 
>> 
>> "Dataset specificed on the command line and also a configuration file
>> specificed.”     (note misspelling of “specified”)
> 
> Fixed.
> 
>> This happens whether the store spec is included in the config file or
>> when a config file is used but a location is not specified there.
>> 
>> (I also noticed that, contrary to the instructions page, referencing
>> a non-existing location from the command line triggers an error).
> 
> The script makes an explicit check (TDB auto-creates).  Link to the 
> documentation you are reading here?

Auto-creation for config script, rejection for --loc . 

http://jena.apache.org/documentation/serving_data/

    --loc=DIR 
   Use an existing TDB database. Create an empty one if it does not exist.

> 
>> Would it be at all possible to have the --loc be interpreted as a
>> location override?
> 
> Tricky because there isn't one location.
> 

Right - hadn’t thought of that. Will have to try i out.

>> I case you’re wondering why I don’t just provide a customized config
>> file for each demo, it’s because my employer’s attorneys won’t allow
>> us to distribute files that contain license restrictions. For the
>> conf file case, the line
>> 
>> # Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0
>> 
>> causes the proposed code distribution to be rejected. :-S  As such, I
>> need to generate a patch file for each config file.
> 
> I'm afraid I don't understand your employer’s attorneys point here because 
> the Apache license was written to allow modification.  It's one of the rights 
> of "open source".
> 
> And for the Apache license, you do not have to relicence your changes under 
> Apache - it's not viral/copyleft.  You retain a free choice on your changes 
> (and retain copyright ownership).
> 
> You can write your own template from scratch. The license is for the actual 
> content in the example.  That means you can look and rewrite. (The license 
> also covers reuse of IP unlike some other open source licenses so that aspect 
> is safe as well.)
> 

Right. Chalk it up to hyper-conservative corporate attorneys. It’s so bad that 
the checking software even rejects a patch script that includes the license 
statement as a context line. Sheesh. I could make it a career-shortening issue, 
but I’ve already wasted to many bytes just complaining about the arbitrary 
actions of a heartless bureaucracy :-S

Excellent point. I can reclaim some hours of frustration by just using the 
sample as a guide. 

> 
>       Andy

Reply via email to