[
https://issues.apache.org/jira/browse/LUCENE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468676#comment-17468676
]
Dawid Weiss commented on LUCENE-10328:
--------------------------------------
I've been working on this for too long and I am nowhere nearer a perfect
solution so I think we should just merge what's currently done on PR 571. Here
is what is currently implemented:
!image-2022-01-04-16-04-56-563.png|width=589,height=532!
The diagram above shows two of gradle's main source sets: the main source set
(a project's "jar") and the test source set (test classes). In theory (and
often in practice) there can be more source sets but let's limit ourselves to
just this.
Each source set can be class-based or modular (containing a top-level
module-info.java). On an intersection of the matching option you can see how
this particular arrangement of the main and test source set is currently
resolved for compilation and runtime tasks. In short: we do have full support
for either full classpath mode testing (right lower corner) or full modular
tests (upper left corner). A mix of the two requires module patching magic that
I simply don't believe the infrastructure (or people) are ready for. I couldn't
get IDEs to work with those options, I couldn't get other tasks and
dependencies like ECJ to parse them gracefully. I am exhausted looking through
various options and, in all honesty, I don't think this bit is so much needed.
Let me explain.
The current way tests work is fine in my opinion. They work in classpath mode
(so they can access package-scope, etc.) with the main source set also working
in "classpath mode". This is what majority of downstream Lucene consumers will
be using for a long time in the future (my guess) so leaving tests there seems
like a reasonable option.
For any tests requiring a full modular setup, we also have a working
infrastructure - you have to create a separate subproject with a suffix
".tests", then create a fully modular test source set referencing the module
you're interested in testing. Examples are provided in the form of
"lucene/core.tests" and "lucene/analysis/morfologik.tests" - these are fully
fledged modular tests, running on of the test-framework (module, yay!).
I realize this is a bit inconvenient but if you want the upper right corner of
the diagram to work I have to warn you I've tried all the options below and
none of them worked well (again: IDE support, various other build tasks):
* main source set patching,
* test source set patching,
* combining main+test into a separate artifact,
* plus perhaps a gazillion other try-reverse attempts I made.
> Module path for compiling and running tests is wrong
> ----------------------------------------------------
>
> Key: LUCENE-10328
> URL: https://issues.apache.org/jira/browse/LUCENE-10328
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Dawid Weiss
> Priority: Major
> Attachments: image-2021-12-19-12-29-21-737.png,
> image-2022-01-04-16-04-56-563.png
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Uwe noticed that the module path for compiling and running tests is empty -
> indeed, the modular configurations we create for the test sourceset do not
> inherit from their main counterparts. This is not a standard thing created
> for a sourceset - the test-main connection link is created by gradle's java
> plugin. We need to do a similar thing for modular configurations.
> !image-2021-12-19-12-29-21-737.png|width=490,height=280!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
