[ 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