Hi I think
1. Yes 2. Plugin 3. Something equivalent to defining dependencies+exclusion but basically impacting a dependency tree. There are tons of options so expériment a bit probably For 12 weeks, default org.apache.maven.plugins (war,ear,jar,...) can be handled i think. At least war as a proof it works. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le sam. 20 juin 2026, 06:56, hitesh sai <[email protected]> a écrit : > Hi Romain and Tamás, > > Thanks for sharing that example. I think tracking dependencies > through plugins to the final artifact is a real problem worth solving. > > I'm interested in exploring this for GSoC 2027 (applications start > in January). I've already merged one PR and helped resolve another > issue, so I'm ready to contribute more to understand the codebase. > > A few technical questions: > 1. Is your tracking prototype the right foundation, or should I > Start fresh? > 2. Should this be a maven-core extension or a separate plugin? > 3. For capturing plugin decisions (WAR, assembly, shade), what > What Maven 4 APIs would plugins need? > 4. What would be a realistic scope for 12 weeks? > > I'm also looking for a mentor if this direction interests any of you. > > Thanks, > Hitesh > > On Fri, 19 Jun 2026 at 22:07, hitesh sai <[email protected]> wrote: > > > Hi Tamás and Romain, > > > > It looks like tracking the dependency graph is only one part of the > > picture; the more challenging part is capturing what happens during the > > build lifecycle, when plugins can influence the final artifact. > > > > The plugin tracking aspect is especially interesting, since it could help > > explain the complete path from a dependency to the final packaged output. > > > > I'll take a look at the prototype and the existing APIs to better > > understand the approach. > > > > Thanks for taking the time to share these ideas. > > > > Best regards, > > Hitesh > > >
