CLI libraries
In examining and discussing https://issues.apache.org/jira/browse/JENA-959, it seems to me (a Jena newbie!) that Jena's CLI action is built up in jena-core, in package jena.cmdline. If that is correct, and Jena has its own CLI code, wouldn't it be better to replace this with a modern CLI library like that provided by Apache Commons? Does that sound like a ticket? --- A. Soroka The University of Virginia Library
Re: CLI libraries
On 08/06/15 15:47, aj...@virginia.edu wrote: In examining and discussing https://issues.apache.org/jira/browse/JENA-959, it seems to me (a Jena newbie!) that Jena's CLI action is built up in jena-core, in package jena.cmdline. If that is correct, and Jena has its own CLI code, wouldn't it be better to replace this with a modern CLI library like that provided by Apache Commons? Does that sound like a ticket? arq.cmdline.CmdLineArgs The whole cmd support does more than Apache Commons CLI. Around command line processing is support for grouping and reuse across commands, and an execution model. There are a lot of commands -- Apache Commons CLI would also cause chnages in syntax. e.g. arq.cmd does not treat -- and - differently; combined POSIX like options aren't supported. (jena.cmdline looks like some partial copy to get older development working). A useful goal might be to have a module "jena-cmd" which is after SDB, TDB and the rest with the set of command line tools we deed to be the public set of commands (some of the old stuff needs retiring or at least incompatibly brought into the general style - e.g. rdfcompare). People use rdfcat :-( but nowadays riot is better IMO (scale, speed, arguments, ..) but I'm not unbiased. A useful but bounded stpe might be to take arq.cmd* to /jena.cmd* and drop /jena.cmdline (not tried this so there maybe a forgotten dependency). Andy --- A. Soroka The University of Virginia Library
Re: CLI libraries
Okay, that makes sense.
Is the larger move (the construction of 'jena-cmd') worth an epic in Jira? With
the smaller ("take arq.cmd* to /jena.cmd* and drop
/jena.cmdline") as a first story therein?
---
A. Soroka
The University of Virginia Library
On Jun 8, 2015, at 11:24 AM, Andy Seaborne wrote:
> On 08/06/15 15:47, aj...@virginia.edu wrote:
>> In examining and discussing
>> https://issues.apache.org/jira/browse/JENA-959, it seems to me (a
>> Jena newbie!) that Jena's CLI action is built up in jena-core, in
>> package jena.cmdline.
>>
>> If that is correct, and Jena has its own CLI code, wouldn't it be
>> better to replace this with a modern CLI library like that provided
>> by Apache Commons? Does that sound like a ticket?
>
> arq.cmdline.CmdLineArgs
>
> The whole cmd support does more than Apache Commons CLI.
>
> Around command line processing is support for grouping and reuse across
> commands, and an execution model.
>
> There are a lot of commands -- Apache Commons CLI would also cause chnages in
> syntax. e.g. arq.cmd does not treat -- and - differently; combined POSIX
> like options aren't supported.
>
> (jena.cmdline looks like some partial copy to get older development working).
>
> A useful goal might be to have a module "jena-cmd" which is after SDB, TDB
> and the rest with the set of command line tools we deed to be the public set
> of commands (some of the old stuff needs retiring or at least incompatibly
> brought into the general style - e.g. rdfcompare).
>
> People use rdfcat :-( but nowadays riot is better IMO (scale, speed,
> arguments, ..) but I'm not unbiased.
>
> A useful but bounded stpe might be to take arq.cmd* to /jena.cmd*
> and drop /jena.cmdline (not tried this so there maybe a forgotten
> dependency).
>
>
> Andy
>
>>
>> --- A. Soroka The University of Virginia Library
>>
>
Re: CLI libraries
I don't see any actual references in the documentation to rdfcat. Perhaps it can be deprecated? --- A. Soroka The University of Virginia Library On Jun 8, 2015, at 11:24 AM, Andy Seaborne wrote: > People use rdfcat :-( but nowadays riot is better IMO (scale, speed, > arguments, ..) but I'm not unbiased.
Re: CLI libraries
On 09/06/15 17:11, aj...@virginia.edu wrote: I don't see any actual references in the documentation to rdfcat. Perhaps it can be deprecated? Interesting question - how to deprecate a command line tool? Print a "This is deprecated message" to stderr? As a Jena3 step we can be faster with migration. jena.rdfcat => only a message saying "use riot"? But first - is "riot" a good enough replacement? Does it need more documentation? (probabaly "yes" as facilities got added incrementally : "--formatted=FORMAT" needs to be the default output style and streaming require intervention). Andy --- A. Soroka The University of Virginia Library On Jun 8, 2015, at 11:24 AM, Andy Seaborne wrote: People use rdfcat :-( but nowadays riot is better IMO (scale, speed, arguments, ..) but I'm not unbiased.
Re: CLI libraries
In the PR I submitted a day or two ago, I added a "DEPRECATED: Please use riot instead" message to the help of rdfcat, but I didn't have it emit that message to stderr on all runs. That seems like a good move to me. I'll add that, and we can then decide whether to go all the way to having that be the _only_ think rdfcat does in Jena 3. --- A. Soroka The University of Virginia Library On Jun 10, 2015, at 6:39 AM, Andy Seaborne wrote: > On 09/06/15 17:11, aj...@virginia.edu wrote: >> I don't see any actual references in the documentation to rdfcat. Perhaps it >> can be deprecated? > > Interesting question - how to deprecate a command line tool? > > Print a "This is deprecated message" to stderr? > > As a Jena3 step we can be faster with migration. > jena.rdfcat => only a message saying "use riot"? > > > But first - is "riot" a good enough replacement? Does it need more > documentation? (probabaly "yes" as facilities got added incrementally : > "--formatted=FORMAT" needs to be the default output style and streaming > require intervention). > > Andy > >> >> --- >> A. Soroka >> The University of Virginia Library >> >> On Jun 8, 2015, at 11:24 AM, Andy Seaborne wrote: >> >>> People use rdfcat :-( but nowadays riot is better IMO (scale, speed, >>> arguments, ..) but I'm not unbiased. >> >
