[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601125#comment-14601125
]
A. Soroka commented on JENA-960:
--------------------------------
I'm at a bit of a loss here: I opened this ticket based on a remark from _you_,
[~andy.seaborne] :)
http://jena.markmail.org/message/mh2kmwnagqncw4by
and I certainly do _not_ have the time to churn change on an open source
project for which I don't get paid. But it sure seems that some confusion has
arisen on the way. I'll give _my_ answers to your questions and I'm sure we can
sort this out usefully.
- "Are flags and values handled in the same way?" Yes, why would they not be?
Why would we want to change that? (Modulo new functionality.)
- "Is compatibility a goal?" I should think it an assumption. No one in this
thread has suggested breaking back-compatibility.
- "Is there something wrong with the current command line handling?" It's more
that there is, for me as a neophyte who would very much like to contribute a
patch for JENA-959, a lot of confusion about how the framework works and how to
use it. For example, none of the (I think) important types {{ArgModule}},
{{ArgModuleGeneral}}, or {{ModBase}} have any Javadocs, and the few comments
there aren't really enough to help a new dev understand what's gong on. In fact
_most_ of what is now in {{jena-base>/jena.cmd}} lacks Javadocs. By comparison,
Elephas' {{RdfStats}} seems extremely clear and the Airline docs are thorough
and helpful.
- "Who and what will be affected by change?" Ideally, no end user will need to
know, but devs wanting to use and extend the framework should find it easier
and better documented. The indirect benefit to end users will be speedier and
less costly work for tickets like JENA-959.
So from that POV, there are a couple of directions I'd like to suggest as
available. Jena could use Airline, as suggested above. Jena could continue to
use the framework now in place, but perhaps document it better and even provide
a tutorial on writing new CLI functionality (and yes, I am volunteering for
that, as long as an experienced dev is willing to help by answering questions).
Or Jena could keep what it has and simply accept that new folks (like me) are
sometimes going to find the code very confusing and difficult to use, which
will slow down work, or make it impossible.
It may very well be that I am not a good example of a new Jena contributor, but
I do think that I am a solid journeyman Java programmer, and I don't think I
have much less time than anyone else to volunteer on open source projects.
{grin}
> The construction of jena-cmd
> ----------------------------
>
> Key: JENA-960
> URL: https://issues.apache.org/jira/browse/JENA-960
> Project: Apache Jena
> Issue Type: Epic
> Components: Jena
> Reporter: A. Soroka
> Priority: Minor
> Labels: cli, command-line, commandline
>
> The current machinery supporting Jena's CLI tools is too sophisticated to be
> replaced entirely by off-the-shelf parts, but it is also scattered across
> several modules. That's not necessary and it could be improved by
> constructing a centralizing module {{jena-cmd}}. This module would depend on
> SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
