On Mon, Jun 16, 2025 at 9:21 AM Claude Warren <cla...@xenei.com> wrote:
> Thomas, > > Thank you for your reply. > > What would be the "Maven way" to solve the problem where there is shared > test code framework/data across multiple subprojects? > > For example Apache RAT has shared test data (used to verify > implementations) as well as helper classes for test cases (to assist in > correctly testing the subproject implementations) The core tests need both > the shared data and the helper classes. The helper classes need core > defined classes. > AFAICT, Apache RAT uses the 3rd option from my suggestions (without filtering the test-jar content though ; which is OK if the test features are internal to the project, rather than meant to be used by third party projects) IIUC from the last time I delved into Maven internals, because the test-jar goal is bound to the package phase (by default, and not overridden here), then this means that a 'mvn test' won't work; tests in downstream projects (e.g. apache-rat-tasks) wouldn't be able to resolve the apache-rat-core test-jar. You have to use 'mvn package' at a minimum (Maven will arrange builds so that apache-rat-core builds before apache-rat-tasks, will run up to the package phase in apache-rat-core which will build and attach the test-jar artifact, then when building apache-rat-tasks, the test-jar is available from the apache-rat-core project) (it's not clear to me why they separated out the testdata in a distinct subproject, maybe I just missed something looking at the POMs only for a few minutes) > Is the maven way to create a separate module for code and test so that > test-fixtures can be inserted between the 2? > If your test fixtures are a published artifact (not only an internal need), then yes (every published artifact should come from a dedicated Maven project, if only for the dependencies so they can come transitively in downstream projects). If they're only internal, then you can use the test-jar like Apache RAT does. Disclaimer: this is my understanding of "the maven way", also based on experience, but also influenced by my own opinions about Maven In your above comment are you saying that maven should not have bundled the > test processing into the main processing? > I have … opinions … on the Maven lifecycle, particularly in conjunction with multi-project builds; which I'll spare you here to keep the conversation as constructive as possible 😇 (suffice to say that I personally only use Maven to build Maven-specific artifacts: plugins and archetypes) -- Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
