Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[Brian Fox]

What I meant to saw but didn't clearly articulate is that I found it
unlikely that half of the most popular stuff was somehow in that 6%. I
pulled the top 200 based on consumption and 136 had easily verifiable
pom.properties.

I don't think the facts really matter though,. I don't understand the
motivations and will avoid the trap of projecting them. However, it's been
clear that the team has been looking for reasons not to change the status
quo, vs having an open mind.

I thought that the Module-Name was a reasonable middle ground that would
allow developers to provide a smooth migration path between now and when
this hits critical mass. Now that it's out the window, we're right back
where we started from.

On Wed, Apr 5, 2017 at 1:17 AM, <mark.reinhold at oracle.com> wrote:

> 2017/4/4 2:38:37 -0700, Brian Fox <brianf at infinity.nu>:
> > Mark I think some of the assertions on the prevalence of the
> pom.properties
> > is wrong. We pulled our own top 20 list based on download popularity and
> > you can see it lines up well with your cited article:
> >
> >   count  |         group_name         |    artifact_name
> > ---------+----------------------------+---------------------
> >  9620458 | junit                      | junit
> >  7660971 | org.slf4j                  | slf4j-api
> >  5608458 | log4j                      | log4j
> >  5542626 | commons-codec              | commons-codec
> >  5389851 | com.google.guava           | guava
> >  5357355 | commons-io                 | commons-io
> >  5177092 | commons-logging            | commons-logging
> >  4936300 | org.apache.httpcomponents  | httpclient
> >  4874902 | org.apache.httpcomponents  | httpcore
> >  4756847 | commons-cli                | commons-cli
> >  4577052 | org.apache.commons         | commons-lang3
> >  4508856 | commons-lang               | commons-lang
> >  4430776 | com.fasterxml.jackson.core | jackson-core
> >  4280673 | com.fasterxml.jackson.core | jackson-databind
> >  4270501 | com.google.code.findbugs   | jsr305
> >  4140850 | com.fasterxml.jackson.core | jackson-annotations
> >  3860911 | org.slf4j                  | jcl-over-slf4j
> >  3410877 | org.springframework        | spring-core
> >  3062759 | org.springframework        | spring-beans
> >  2989047 | classworlds                | classworlds
> >
> > However, only junit and the 2 spring modules are missing a
> pom.properties.
> > The assertion that less than half the popular components don't have it
> > seems provably incorrect.
>
> It's correct for the 140 projects that I examined, which is all that
> I claimed.  Check them for yourself.
>
> The number of projects that constitutes a reasonable sample of the
> "popular" projects (by whatever ranking) is a bit of a judgement call,
> but twenty seems very small to me.  Every project in my list of 140 is
> well known, so I think it's a more representative sample.
>
> What do you see if you examine the top 140 projects according to
> whatever ranking you use for Central?
>
> >                           All the popular stuff is in Maven Central and
> > again, 94% is a huge number, saying it doesn't cover much is just
> > inaccurate.
>
> Nearly everything in Central is not popular.  That 94% of all projects
> have a given property does not imply that 94% of the popular projects
> have that property.
>
> - Mark
>