brew ships maven 3.5.4
apt-get ships maven 3.5.2
centos ships maven 3.0.5 !!??

CentOS is old enough that I'd expect those users to do a manual maven
install anyway, but Ubuntu being on 3.5.2 is recent enough to not want to
burden them but old enough to be annoying in this case.


On Wed, Aug 22, 2018 at 11:49 AM, Sean Busbey <bus...@apache.org> wrote:

> For what it's worth, all of our precommit and nightly testing jobs on
> ASF Jenkins rely on Maven 3.5.3.
>
> The simple IT jobs for master, branch-1.2, and branch-1.3 rely on Maven
> 3.0.5.
>
> The job that builds our website relies on Maven 3.3.3.
>
> If the answer is #1 we should at least make sure the website
> generation and master branch IT work with it. (I don't anticipate any
> issues there.)
>
> What, if any, maven versions do major OSes ship with or provide via
> their package managers these days? Would we be essentially requiring
> folks to do a maven upgrade or maven manual installation just for us?
> On Wed, Aug 22, 2018 at 11:26 AM Mike Drob <md...@apache.org> wrote:
> >
> > Hi Devs,
> >
> > Our current minimum maven version is 3.0.4, this is both enforced by the
> > enforcer plugin and documented in the ref guide. Over on HBASE-20175, our
> > Artem is suggesting to use a newer version of the scala-maven-plugin but
> > the latest version requires Maven 3.5.3
> >
> > It looks like we have a couple of options that I want to get feedback on:
> >
> > 1) Bump our minimum maven version for master branch. We can leave it at
> > 3.0.4 for branch-1 and branch-2, but this would come up again if we ever
> > try to backport the hbase-spark module.
> >
> > 2) Engage with the scala plugin community to try and get the plugin to
> work
> > with older maven versions. I haven't done any feasibility study on this
> > yet, and am not even sure which community we would be talking to.
> >
> > 3) See if the specific issues we are running into are solved by older
> > versions of the plugin that are compatible with older versions of maven.
> >
> > 4) Do some transitive dependency exclusion magic instead of actually
> > harmonizing the versions of things that we use.
> >
> > I'm leaning towards 1) or 4), but would be interested to hear thoughts
> from
> > other parties.
> >
> > Mike
>

Reply via email to