Re: [DISCUSS] Merging small plugins
Il mer 8 gen 2020, 16:49 Elliotte Rusty Harold ha scritto: > Is the proposal to combine the plugins into a single plugin No or simply > to combine the individual plugins into a unified repo with a unified > release process such that when one plugin is released all are > released? > Yes Enrico > > On Sun, Jan 5, 2020 at 11:31 AM Enrico Olivelli > 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, > enforcernot > > 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 svnbut I think this move can give more vitality to the project > > > > We would have to think about jira, websitesI know it won't be easy > > > > Best regards > > Enrico > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Merging small plugins
Is the proposal to combine the plugins into a single plugin or simply to combine the individual plugins into a unified repo with a unified release process such that when one plugin is released all are released? On Sun, Jan 5, 2020 at 11:31 AM Enrico Olivelli 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, enforcernot > 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 svnbut I think this move can give more vitality to the project > > We would have to think about jira, websitesI know it won't be easy > > Best regards > Enrico -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merging small plugins
Hi Enrico, > 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 that's a bad idea as multiple otherwise unrelated goals then share their dependencies. Assume, for the moment, that the maven-ext-plugin has both checkstyle and pmd goals and that I specify both a specific version of Checkstyle and PMD in the plugin's element. Now what happens if Checkstyle and PMD have conflicting transitive dependencies? And, no, this is not hypothetical. I have this exact problem with the xml-maven-plugin: Its validate and transform goals often require , e.g., to support Relax NG validation or XSLT 2.0 transformation and those dependencies *do* have conflicting dependencies. AFAIK, there is no workaround for this, as are unfortunately not -level; you only can specify them for the plugin as a whole. :-( Best wishes, Andreas signature.asc Description: OpenPGP digital signature
Re: [DISCUSS] Merging small plugins
Hi, On 05.01.20 19:33, Benjamin Marwell wrote: 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. Yes very good philosophy... If voting is a drawback for small plugins, maybe change the voting system for smaller plugins instead? Than I would ask: What is a "small" plugin? Not really I just want to note that... 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? The VOTEing has a very good background see https://www.apache.org/foundation/voting.html but if we might need we could change it.. > And maybe talk about more automatisms for updating the poms and dependencies, maybe even use a github bot? Automated updates for dependencies is a very good idea.. I already have done a lot to more automate my tooling... The final step is check which dependencies could be updated...and the rest can be automated as I already did... At the moment I only call my script "createdependencyupgradeissue.sh" from the appropriate plugin/lib with supplemental explanation (This could be automated)..This will create a branch for the change / JIRA Issue etc. I only need to manually change the version of the dependency...and wait for the successful build and afterwards "gitmergeandclean.sh" which merges the branch, fixes the JIRA issue etc. So the interesting part is: Identify which dependency has to be updated? Something like "versions:display-dependency-updates" which can deliver the needed informationI think that might a way to go or maybe GitHub DependendaBot... On Sun, 5 Jan 2020, 17:31 Enrico Olivelli, 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 This is independant of the release. - stage a release That's not the real problem. The signing of the artifacts is the part which is the issue cause the rest could be automated via Jenkins/WhatEver...but the Problem is related to the private PGP key to sign the artifacts. - make the VOTE, wait, make at least 3 PMC vote.. Yes ... - finalize... Could be done via button ...(Need some work, but doable)... Also creating the announcement mail etc. 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, enforcernot 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...) Which means one plugin could block all others. We have some plugins like maven-compiler, maven-shade, maven-pmd which needed to be released with each Java version ...other are not that problem.. We could even think to time based release schedule How long could be the time between the releases? days, weeks, months? I image the big work you did for splitting all of the 100 git repositories from svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merging small plugins
> We have tens of plugins, most of them are rarely updated and released ... is the key problem you're trying to solve right? Team to actively process issues and PRs and push releases minor releases efficiently is the real wish, right?
Re: [DISCUSS] Merging small plugins
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, 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, enforcernot > 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 svnbut I think this move can give more vitality to the project > > We would have to think about jira, websitesI know it won't be easy > > Best regards > Enrico >
Re: [DISCUSS] Merging small plugins
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 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, enforcernot 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 svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico
[DISCUSS] Merging small plugins
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, enforcernot 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 svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico