NUTCH-3032 Code for an ArbitraryIndexingFilter to index values resolved by user POJO code at index time

[CatChullain]

This is the initial code for an arbitrary indexing filter, NUTCH-3032.

It could be helpful to let end users manipulate information at indexing time with their own code without the need for writing their own indexing plugin. I mentioned this on the dev mailing list (https://www.mail-archive.com/dev@nutch.apache.org/msg31190.html) with some description of my work in progress.

One potential use is to address some of the same concerns that NUTCH-585 discusses regarding an alternative approach to picking and choosing which content to index, but this approach would allow making index time decisions, rather than setting the configuration for all content at the start of the indexing run.

Ideally a solution to NUTCH-585 would work at parse time, but this index time code still has potential uses for any kind of look-ups or calculations that depend on values in the document where the need to manipulate data exceeds what something like Jexl filter can do easily, or where outside data is worth incorporating into the document for use after indexing.

Thanks for your contribution to Apache Nutch! Your help is appreciated!

Before opening the pull request, please verify that

• there is an open issue on the Nutch issue tracker which describes the problem or the improvement. We cannot accept pull requests without an issue because the change wouldn't be listed in the release notes.
• the issue ID (NUTCH-XXXX)
  • is referenced in the title of the pull request
  • and placed in front of your commit messages surrounded by square brackets ([NUTCH-XXXX] Issue or pull request title)
• commits are squashed into a single one (or few commits for larger changes)
• Java source code follows Nutch Eclipse Code Formatting rules
• Nutch is successfully built and unit tests pass by running ant clean runtime test
• there should be no conflicts when merging the pull request branch into the recent master branch. If there are conflicts, please try to rebase the pull request branch on top of a freshly pulled master branch.
• if new dependencies are added,
  • are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • are LICENSE-binary and NOTICE-binary updated accordingly?

We will be able to faster integrate your pull request if these conditions are met. If you have any questions how to fix your problem or about using Nutch in general, please sign up for the Nutch mailing list. Thanks!

[lewismc]

Hi @CatChullain nice patch!
Please see my minor comments. I have not tested this yet but will get around to that soon :)

[lewismc]

HGi @CatChullain please also address my feedback on logging statements. Thank you. This applies for the entire PR. Thanks

[CatChullain]

Thanks, Lewis! I got some of it done today. I'll consolidate the LOG statements a bit more tomorrow.

[lewismc]

Hi @CatChullain please see some updated comments RE: logging.

[CatChullain]

Thanks, Lewis! I moved all four to DEBUG, but I wonder where might be good spots for INFO level messages. I'm thinking of the operator or tech who doesn't dig into code and has an issue in the config. During dev & test myself, I sometimes forgot to increment the index.arbitrary.function.count and the plugin ignored the later fields. Just outputting that count value, and maybe something when overwrite is true, might be helpful for alerting someone that the config might not be what they'd believed.

Do either of those (or something else) seem worthwhile, or does it make more sense to let people use it and see what issues they raise?

[lewismc]

@CatChullain thanks for your patience whilst we work this one 👍

… I wonder where might be good spots for INFO level messages

The reason I suggested that the log level be revised from INFO to DEBUG was that any logging needs to make sense in the context of the entire log. Said another way, plugin logging needs to complement the core crawler tasks.
That being said, if you want to include INFO for the following scenarios then please go ahead.

• recording the count value, and
• indicating when overwrite is true
  Your rationale is sound.

[lewismc]

Hi @CatChullain I associated this Jira ticket to the 1.20 release and made you assignee 👍
We will get it merged soon and roll the release.

[CatChullain]

Thanks again, @lewismc.

I did add those INFO messages, but I found an extra call to setIndexedConf from setConf that the filter() method handles more cleanly, so I removed that, too.

[lewismc]

+1 thanks @CatChullain for considering all the feedback. Will merge once CI passes.