ascheman commented on issue #78: URL: https://github.com/apache/tooling-atr-maven-plugin/issues/78#issuecomment-5055118917
@slawekjaranowski @dave2wave Agreed on not modifying the source archive — and RAT-554 is the right home for the generation: it's the general version of exactly this thread (share the effective excludes between the Maven plugin and the CLI ATR runs). I just posted a sweep on apache/tooling-trusted-releases#1430: 50 of 90 apache/maven-* repos declare project-specific RAT excludes in the root pom (median 3, max 25) — and that's a lower bound (module-level excludes + inherited maven-parent defaults on top). So RAT-554 would pay off broadly, not just for edge cases. One thing worth deciding consciously: ATR today already consumes an in-archive `.rat-excludes` at the source-tree root (per @sbp on #1430). Dave's separate metadata archive is cleaner on the plugin side, but it's a *different* consumption path that ATR doesn't read yet — so that route needs matching ATR work, whereas a `.rat-excludes` that lands in the source tree the normal way (e.g. emitted at build time, included by the source-release assembly rather than patched in afterwards) needs no ATR change. Might be worth picking based on which side you'd rather add the work. I'd be glad to help on the Maven-plugin-shaped pieces — the atr-maven-plugin metadata side, or the apache-rat-plugin emitting the effective excludes — but I'll leave the RAT core/CLI config-sharing mechanism itself to you folks who know it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
