Hi, thanks for sharing your idea. While I can see the benefits, I also do see some drawbacks.
If only one part of the plugin has an invalid state, it will be impossible to create a release. Also, the Unix philosophy (make a tool which does one thing well) would be broken. If voting is a drawback for small plugins, maybe change the voting system for smaller plugins instead? As a new contributer, I found it easy to find a plugin I could contribute to. That would not have been that easy if there was one repository with one plugin that does a lot of things. I'd stick to the current layout for this reason. Maybe let's talk about voting instead? And maybe talk about more automatisms for updating the poms and dependencies, maybe even use a github bot? On Sun, 5 Jan 2020, 17:31 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 >
