[DISCUSS] Merging small plugins

[Enrico Olivelli <eo...@gmail.com>]

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

Re: [DISCUSS] Merging small plugins

[Andreas Sewe <se...@st.informatik.tu-darmstadt.de>]

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 <dependencies> 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
<dependencies>, 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 <dependencies>
are unfortunately not <execution>-level; you only can specify them for
the plugin as a whole. :-(

Best wishes,

Andreas

Re: [DISCUSS] Merging small plugins

[Paul Hammant <pa...@hammant.org.INVALID>]

> 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

[Karl Heinz Marbaise <kh...@gmx.de>]

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 information....I think that might a way to go or maybe GitHub
DependendaBot...


>
>
> On Sun, 5 Jan 2020, 17:31 Enrico Olivelli, <eo...@gmail.com> 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, 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...)

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 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
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Merging small plugins

[Benjamin Marwell <bm...@gmail.com>]

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, <eo...@gmail.com> 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
>

Re: [DISCUSS] Merging small plugins

[Robert Scholte <rf...@apache.org>]

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 <eo...@gmail.com> 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

Re: [DISCUSS] Merging small plugins

[Enrico Olivelli <eo...@gmail.com>]

Il mer 8 gen 2020, 16:49 Elliotte Rusty Harold <el...@ibiblio.org> 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 <eo...@gmail.com>
> 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
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Merging small plugins

[Elliotte Rusty Harold <el...@ibiblio.org>]

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 <eo...@gmail.com> 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



-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org