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