Hi everyone, I'm Tarun, a CS student planning to apply for GSoC 2027 with Apache Maven. I wanted to share my proposal idea early and get community input before writing the full application.
The proposal: Add a diagnostic capability to Maven that answers the question: "Why was this project included in or excluded from the reactor build?" Current situation: Users working with multi-module Maven projects often use options like -pl, -am, -amd, and -rf to control reactor builds. When these options are combined, it can be difficult to understand exactly why certain projects are included or excluded from the build. Currently, users often have to inspect the project structure and reactor behavior manually to understand the selection. Proposed solution: Introduce an opt-in diagnostic mode that explains reactor project selection decisions. For example: $ mvn install -pl module-a -am -Dreactor.selection.verbose Reactor Selection Analysis: Included projects: - root-project (required as aggregator) - module-a (explicitly selected) - module-b (required dependency of module-a) Excluded projects: - module-c (not selected) - module-d (not required by selected projects) Selection reason: module-a was explicitly selected using -pl. module-b was included because of -am. Implementation approach: - Investigate the existing reactor selection flow, particularly DefaultGraphBuilder and related project graph components. - Trace how options such as -pl, -am, -amd, and -rf affect project selection. - Capture the reasons behind project inclusion and exclusion. - Present the selection decisions in a human-readable diagnostic output. - Ensure the feature does not change existing reactor selection or build behavior. I am proposing this as a diagnostic feature rather than a change to Maven's reactor logic. The goal is to make complex multi-module builds easier to understand and debug. I'd appreciate: 1. Feedback on the scope — too big, too small, or about right for a 12-week project? 2. Whether this idea overlaps with existing Maven 4 work, discussions, or JIRA issues. 3. Whether any Apache Maven committer or experienced contributor would be interested in mentoring me on this proposal for GSoC 2027. 4. Any suggestions for refining the implementation approach or identifying a suitable starting point in the codebase. As I'm still learning some parts of Maven's reactor internals, I would particularly appreciate guidance from a potential mentor who could help me refine the scope, understand the relevant architecture, and guide the implementation. Thank you for reading. Happy to discuss the idea further or share a more detailed write-up. Best regards, Tarun https://github.com/Tarun4201 Sai Vidya Institute of Technology, India
