I understand the issue you're trying to solve, but I don't think it is the right solution. To me a plugin contains a number of goals that are related to each other. If there are issues, they are very easy to pinpoint. If we start with with a monolithic plugin, you'll likely introduce more issues. Suppose one goal has that feature you're wating for, but you can't use it because of a bug in another goal.
Also be aware that the number of releases says nothing about the plugin. It might be (close to) finished, hence no reason to release it. To me there are a couple of things we can do: - give plugins to there related library ( checkstyle, PMD, Antrun, Patch(?), PDF(?) ) - move plugins to mojohaus (but they suffer with the same issues) - archive plugins (I've already done that last year) - attract more contributors. thanks, Robert On 5-1-2020 17:31:13, Enrico Olivelli <[email protected]> wrote: Hi community, I just want to share this idea, maybe it is silly but why not talk about it. We have tens of plugins, most of them are rarely updated and released. So it happens that users contribute patches in order to fix real problems but they have to wait an indefinite time before seeing the fix released, because we are not doing a release just for one issue. Another problem is that making a release is quite an heavyweight task: - update parent pom, update dependencies.... - stage a release.... - make the VOTE, wait, make at least 3 PMC vote.. - finalize... What about creating some maven-ext-plugins git repository with a parent and reactor pom and move all of those plugins that are really never released? I am thinking to side plugins like jdeps, checkstyle, pmd, enforcer....not compiler, assembly, surefire... If we merge them into one single code base we can: - have releases for all of them, even with some minimal (but blocker) fix - save time and resources (one committer does the work once and PMC votes only once, and we release 10 or more plugins...) We could even think to time based release schedule I image the big work you did for splitting all of the 100 git repositories from svn....but I think this move can give more vitality to the project We would have to think about jira, websites....I know it won't be easy Best regards Enrico
