[
https://issues.apache.org/jira/browse/LUCENE-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023947#comment-17023947
]
Erick Erickson edited comment on LUCENE-9134 at 1/26/20 10:59 PM:
------------------------------------------------------------------
OK, thanks Dawid. I suspected some/all of what I've done so far would be
throw-away while I got my feet wet with "the gradle way". Or maybe that's
"Dawid's way" ;) And, for that matter, understood what the heck the ant stuff
was doing.
Humor aside, it's great that you're willing to lend some structure to the
gradle effort, that helps keep things coherent rather than ad-hoc, with many
different ways of doing something depending on who did which bit.
I'll close the PR and start over with your model, now that I have an approach
I'm _starting_ to see how they all fit together, and I can do these in smaller
chunks.
Should I put the deletes bits in? If so, my impulse would be to put it in the
@TaskAction in JFlexTask.
Regardless of whether I should, would that be the correct place for something
like that?
So is there anything to do with the jflex you put in for StandardTokenizerImpl
except push it except verification or perhaps put the delete parts back? I'll
look at javacc in the meantime.
was (Author: erickerickson):
OK, thanks Dawid. I suspected some/all of what I've done so far would be
throw-away while I got my feet wet with "the gradle way". Or maybe that's
"Dawid's way" ;) And, for that matter, understood what the heck the ant stuff
was doing.
Humor aside, it's great that you're willing to lend some structure to the
gradle effort, that helps keep things coherent rather than ad-hoc, with many
different structures depending on who did which bit.
I'll close the PR and start over with your model, now that I have an approach
I'm _starting_ to see how they all fit together, and I can do these in smaller
chunks.
> Port ant-regenerate tasks to Gradle build
> -----------------------------------------
>
> Key: LUCENE-9134
> URL: https://issues.apache.org/jira/browse/LUCENE-9134
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Attachments: LUCENE-9134.patch, core_regen.patch
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Take II about organizing this beast.
> A list of items that needs to be added or requires work. If you'd like to
> work on any of these, please add your name to the list. See process comments
> at parent (LUCENE-9077)
> * Implement jflex task in lucene/core
> * Implement jflex tasks in lucene/analysis
> * Implement javacc tasks in lucene/queryparser (EOE)
> * Implement javacc tasks in solr/core (EOE)
> * Implement python tasks in lucene (? there are several javadocs mentions in
> the build.xml, this may be irrelevant to the Gradle effort).
> * Implement python tasks in lucene/core
> * Implement python tasks in lucene/analysis
>
> Here are the "regenerate" targets I found in the ant version. There are a
> couple that I don't have evidence for or against being rebuilt
> // Very top level
> {code:java}
> ./build.xml: <target name="regenerate" description="Runs all code
> regenerators">
> ./build.xml: <subant target="regenerate" inheritall="false"
> failonerror="true">
> ./build.xml: <target name="regenerateAndCheck"
> depends="regenerate,-check-after-regeneration"/>
> {code}
> // top level Lucene. This includes the core/build.xml and
> test-framework/build.xml files
> {code:java}
> ./lucene/build.xml: <target name="regenerate">
> ./lucene/build.xml: <subant target="regenerate" failonerror="true"
> inheritall="false">
> ./lucene/build.xml: <modules-crawl target="regenerate"/>
> {code}
> // This one has quite a number of customizations to
> {code:java}
> ./lucene/core/build.xml: <target name="regenerate"
> depends="createLevAutomata,createPackedIntSources,jflex"/>
> {code}
> // This one has a bunch of code modifications _after_ javacc is run on
> certain of the
> // output files. Save this one for last?
> {code:java}
> ./lucene/queryparser/build.xml: <target name="regenerate" depends="javacc"/>
> {code}
> // the files under ../lucene/analysis... are pretty self contained. I expect
> these could be done as a unit
> {code:java}
> ./lucene/analysis/build.xml: <target name="regenerate">
> ./lucene/analysis/build.xml: <forall-analyzers target="regenerate"/>
> ./lucene/analysis/common/build.xml: <target name="regenerate"
> depends="jflex,unicode-data"/>
> ./lucene/analysis/icu/build.xml: <target name="regenerate"
> depends="gen-utr30-data-files,gennorm2,genrbbi"/>
> ./lucene/analysis/kuromoji/build.xml: <target name="regenerate"
> depends="build-dict"/>
> ./lucene/analysis/nori/build.xml: <target name="regenerate"
> depends="build-dict"/>
> ./lucene/analysis/opennlp/build.xml: <target name="regenerate"
> depends="train-test-models"/>
> {code}
>
> // These _are_ regenerated from the top-level regenerate target, but for –
> LUCENE-9080//the changes were only in imports so there are no
> //corresponding files checked in in that JIRA
> {code:java}
> ./lucene/expressions/build.xml: <target name="regenerate"
> depends="run-antlr"/>
> {code}
> // Apparently unrelated to ./lucene/analysis/opennlp/build.xml
> "train-test-models" target
> // Apparently not rebuilt from the top level, but _are_ regenerated when
> executed from
> // ./solr/contrib/langid
> {code:java}
> ./solr/contrib/langid/build.xml: <target name="regenerate"
> depends="train-test-models"/>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
