A big thumb up for lowering Maven console output! Many Maven errors (and outputs) are just very redundant and lost in ocean flood of log lines.
For the rest I'd leave to other team mates to chime in. Thanks T On Mon, Jul 22, 2024, 09:25 Gyorgy Abraham <gyorgy.abra...@genesys.com> wrote: > Dear Maven devs, > > At our company Genesys, we are holding a Hackathon in the following days. > Me and one of my colleagues decided to contribute to maven and specifically > enforcer plugin, because we use it in a daily basis and have some ideas to > improve the output format. > Before throwing in any PRs, I would like to ask for some guidance, so it > will be easier for both parties to get along. > > > * Should we just modify the current output format, or would you like > us to make it possible for an alternative output, that can be chosen by the > user? > * If the latter option seems better, what is the desired way to > specify the option? Switch on command line, pom.xml config in the plugin > section, etc? > * Maybe a different option would be create a similar rule, but with > *simple name. > * We only use require upper bounds rule: > https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html > Is it possible to only apply the alternative output for this one? Do you > need us to include all built in rules? > * What are the conventions and requirements for a certain PR to be > accepted? We would like to conform. > > Generally our intention is to make the output more human friendly, because > the current one is very verbose, lists unnecessary / unrelated issues, and > generally it is pretty hard to pick up what explicit dependency needs to be > increased. (In our test case, a single modification to only one dependency > would create a total of 8 lines of problems, of which only 3 were > necessary). > > Our alternative output would be some table maybe, with the following > columns: > > * Explicit dependency identifier > * Local version (to be increased) > * Higher version(s) found in the transitive graph > This version would lack some information that is present in the current > one, but most of the times that is not necessary. > > Kindly looking forward for your response, cheers > Gyorgy and Praveen > >
