[
https://issues.apache.org/jira/browse/NIFI-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012721#comment-15012721
]
Tony Kurc commented on NIFI-1081:
---------------------------------
I'm not sure of your concern, based on to the the apache license [1], but I'll
outline my thought process. As I understand it, by dropping your patch on jira,
you've basically said 'here is some code, I have not marked it as "not a
contribution"'. At that point, we have a record of the contribution. It is up
to committers and PMC members to decide what to do with it at that point.
It is apache "policy" to try to credit the original contributor author [2] (and
for NiFi, that generally means via the git commit author) of work for two
reasons, to trace back the commit to the record of the contribution (using the
ticket number), and to give people credit for their work.
We have everything to do that, your patch (contributed because you dropped it
on jira). my patch that I uploaded next based on your patch. The commit message
and author makes it easy to trace back and assign credit. I feel as thought
that is possible. My commit messages would always say "With amendments for ..."
if I changed the code in case someone wanted to assign blame (which git and svn
track per line of code). By all means, if you're saying this because you're
uncomfortable, that wasn't something I had considered.
[1] http://www.apache.org/licenses/LICENSE-2.0
[2] http://www.apache.org/dev/committers.html#applying-patches
> Add option to ExecuteStreamCommand to put value of execution to an attribute
> ----------------------------------------------------------------------------
>
> Key: NIFI-1081
> URL: https://issues.apache.org/jira/browse/NIFI-1081
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Joseph Percivall
> Assignee: Tony Kurc
> Priority: Minor
> Fix For: 0.4.0
>
> Attachments: ExecuteStreamCommandTester.xml, NIFI-1081.000.patch,
> NIFI-1081_02.patch, NIFI-1081_03.patch, NIFI-1081_fix_property_name.patch
>
>
> This issue arose from a user on the mailing list. It demonstrates the need to
> be able to put the output of ExecuteStreamCommand to an attribute:
> I'm looking to process many files into common formats. The source files are
> coming in various character sets, mime types, and new line terminators.
> My thinking for a data flow was along these lines:
> GetFile (from many sub directories) ->
> ExecuteStreamCommand (file -i) ->
> ConvertCharacterSet (from previous command to utf8) ->
> ReplaceText (to change any \r\n into \n) ->
> PutFile (into a directory structure based on values found in the original
> file path and filename)
> Additional steps would be added for archiving a copy of the original,
> converting xml files, etc.
> Attempting to process these with Nifi leaves me confused as to how to process
> within the tool. If I want to ConvertCharacterSet, I have to know the input
> type. I setup a ExecuteStreamCommand to file -i
> ${absolute.path:append(${filename})} which returned the expected values. I
> don't see a way to turn these results into input for the processor, which
> doesn't accept expression language for that field.
> I also considered ConvertCSVToAvro as an interim step but notice the same
> issue. Any suggestions what this dataflow should look like?
> Bryan Bende's response:
> One problem with the above flow is that ExecuteStreamCommand will replace the
> contents of the FlowFile with the results of the command, so the FlowFIle
> will have the encoding value and no longer have the original content.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
