On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Fri, 4 Oct 2019 at 12:03, Michael Osipov <micha...@apache.org> wrote:
>
> > Am 2019-09-28 um 14:05 schrieb Robert Scholte:
> > > Hi,
> > >
> > > TLDR; introduce maven.experimental.buildconsumer and push Java
> > > requirement to Java 8
> > >
> > > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > > didn't face real regressions.
> > > The only one might be tricky is the issue related to Tycho.
> > >
> > > However, I think we're ready to push Maven to the next level.
> > >
> > > For those actively reading this list, they should recognize the need
> for
> > > splitting up the pom as it is on the local system versus the pom being
> > > uploaded. Once we truly control this mechanism we can think of
> > > improvements on model 5.0.0 and new fileformats.
> > >
> > > I've created and implemented MNG-6656[1]. It also contains a zip with
> an
> > > example (original, patched, README) to understand what's happening.
> > >
> > > In order to make this successful, we need IDEs and CI Servers to
> > > understand and support these changes. The likely need to implement one
> > > of the interfaces[2].
> > > The new interface uses Java8 Functions (and especially SAXEventFactory
> > > is way easier to read+maintain with Java 8). I've tried to keep Maven
> > > Java 7 compatible, but that was too hard to do.
> > > So I'd like to use this opportunity to move Maven forward and start
> > > requiring Java 8.
> > >
> > > There are some other improvements I'd like to add (those messages will
> > > follow), so this will imply that it will take some time before we do a
> > > new release.
> > >
> > > WDTY,
> > > Robert
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-6656
> > > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >
> > Regardless of how good this sounds/is, we have quite other substantional
> > issues to solve first this year, this is not a real world problem which
> > needs to be solved instantly:
> >
> > 1. I would expect a formal vote for the bump and the justification for
> it.
> > 2. Fix behavior changes for 3.7.0, update plugins (infrastructure if you
> > like)
> > 3. Really really clean up JIRA. We have *1864* unresolved issues! It
> > *cannot* go on like that forever. I've been working hard this year to
> > push a lot of components like SCM, Wagon, etc. Even in 3.6.2 I have
> > addressed 25 issues.
> >
> > Personally, I don't have any motivation nor the mental/physical fitness
> > and especially time to make any substantial contributions except leaving
> > comments on JIRA issues or reviewing a PR at most for the next three to
> > six months.
>
>
> I would love to have the energy to work on Maven in the short term... I put
> a lot of energy into the PDT proposal, but finding a way to move on that in
> the current code base is tricky, hence why I haven't even started!
>
>
> > I also won't participate in any further in-depth discussion
> > for 3.7.0 for the reasons I have mentioned previously. I just don't see
> > it fruitful.
> > The technical debt we have is huge and we are not able to handle it.
> >
>
> There is a chicken and egg situation though. A lot of the technical debt we
> have is fall-out from being unable to evolve the pom. We cannot evolve the
> pom without being able to split the build vs consumer pom, thus we keep
> leaking the technical debt.
>
> And potential contributors will keep getting pushed away until we provide a
> pom evolution path.
>
> We need more contributors, but to get them we need a way to help them
> scratch their itches.
>
> 3.4.0 was the result of a new contributor trying to make progress... but
> because we didn't have a clear path to solve evolution we ended up burning
> that individual as a contributor.
>
> We need an evolution path.
>

Just Maven user here but involved in a number of other FOSS projects. We
are seeing significant improvement in number of new contributors and their
longevity since relaxing a bit the rules to not be all about supporting
ancient versions of everything. And a project is its contributors - not
managing to attract new guys and old guys getting tired is probably hardest
one to solve.


>
>
> > This is not intended to diminish your work anyhow, but to express our
> > current situation from my personal view.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team

Reply via email to