Thanks for the feedback so far. One PR was already merged, kudos also.
Regarding ’studies’ I have added a profile (with that name) to the reactor build and set the PR to ready as well as the remaining draft PRs: Maven Sources (Reactor): https://github.com/apache/maven-sources/pull/13 Maven Mapping: https://github.com/apache/maven-mapping/pull/8 Maven Stage Plugin: https://github.com/apache/maven-stage-plugin/pull/15 Maven Shared IO: https://github.com/apache/maven-shared-io/pull/27 Thanks for merging! I will soon try to get the reactor working with M4, add a profile to run the ITs, add a GH action. What else would you consider necessary? I wonder, for example, if there should be a trigger to build the reactor whenever one of the modules is updated (or even with a PR of the modules including the module in it’s particular branch). Perhaps all of these points are a different story and should be discussed in new branches? > On 14. Jan 2025, at 07:55, Hervé Boutemy <herve.bout...@free.fr> wrote: > > +1 to the profile approach for building these studies only when interested > > and keep in mind flexibility about sharing one general studies branch vs > taking > extra structure of a dedicated Git orphan branch > > Le lundi 13 janvier 2025, 22:23:26 CET Gerd Aschemann a écrit : >>> On 13. Jan 2025, at 08:01, Hervé Boutemy <herve.bout...@free.fr> wrote: >>> >>> oh, someone who seriously tries to maintain Maven Source Aggregator: nice! >>> https://github.com/apache/maven-sources/tree/master/aggregator >> >> Let’s see if I can manage this endeavour in the long run ;-). >> >>> I'm not really surprised that Maven Studies in that reactor may cause >>> issues https://github.com/apache/maven-studies >>> https://maven.apache.org/studies/ >>> As said in the master readme, they replace Maven Sandbox from svn time, to >>> avoid creating a separate Git repo that has limited interest, or not yet >>> proven >> >> I do not object to still have them in the overall code base (`repo` tool >> based Maven Source), but would like to remove them from the reactor build >> or at least ban them to a profile. >> >> What would be the most important goal of a reactor build? In my opinion it >> should allow for a simple embracement of all (production) relevant modules. >> Therefore it should IMHO only contain the respective (self-maintained) >> tools and libraries, underlying (former separate) libraries (like Plexus >> and Sisu), the Maven core itself and the plugins. All components which >> qualify to be part of the reactor should be maintained and kept up to date. >> >> I wouldn’t treat studies as equal citizens, in particular as they seem not >> to be well maintained. They perhaps were working at the time the respective >> study was necessary. But then either the idea was given up or it was >> incorporated into some other components. Aren’t both good reasons to drop >> them from the major reactor builds in this moment. Hey, we have an SCM, we >> can reactivate them anytime, but no reason to keep the burden with every >> build, right? >> >> Additionally, I wonder about the technical implementation. Keeping them in >> one repo on separate branches makes using `repo` real hard. Could we at >> least combine them on a single branch? They could have separate >> subdirectories, or even a common reactor if it helps. New studies could >> still be developed on separate branches. But they should then be merged to >> the common `main` (`master` seems to be politically incorrect these days) >> if they mature. >>> This permits to avoid empty GH repos like maven-metric-extension, created >>> but never used: if code had been initiated as a study, it's only after a >>> sufficient tested codebase that Git repo would have been created. >> >> Sure, I am a big fan of cleaning up outdated and non-maintained (or even >> empty) stuff. >>> I feel that recently quite a few maven-* Git repositories were created >>> that >>> may quickly become unmaintained: creating a separate orphan branch in >>> maven- studies is a way to stress test an idea >>> >>> >>> Studies are not meant to be components for release, but "studies": >>> - either with a limited time value, like the first studies for consumer >>> POM >>> - or with complex compatibility tests in mind, like the extensions study >>> >>> Some past studies (= Git orphan branches) may completely be deleted; >>> Some studies may be removed from the full source code aggregator build, or >>> moved to specific pom.xml profiles to document the specifics >>> >>> This pom.xml profile approach seems relevant for extensions study: not >>> fully dropped, but not part of normal full source code of Maven >> >> Thats the last resort, exclude them by a profile if not completely. >> >>> Regards, >>> >>> Hervé >>> >>> Le lundi 13 janvier 2025, 03:53:28 CET Gerd Aschemann a écrit : >>>> Hello Maven committers, >>>> >>>> some of you already noticed that our Maven Support-and-Care >>>> <https://github.com/support-and-care/maven-support-and-care> initiative >>>> started working in the last weeks. Sandra has prepared and supported >>>> migration of Jira issues to GitHub. >>>> >>>> Now it’s my turn to start contributing to successful individual project >>>> builds and in particular reactor build. This does not only improve the >>>> Maven project but also enables further analysis of code quality and >>>> enforcement of unique standards to all Maven projects. We expect to send >>>> in >>>> first formal analysis results soon, e.g., based on jQAssistant >>>> <https://jqassistant.org/>. >>>> >>>> Therefore I have run a due diligence >>>> <https://github.com/support-and-care/maven-support-and-care/issues/77> >>>> process to make at least all 133 current Maven projects including the >>>> reactor build with Maven 3.9.9 and JDK 21. After reaching this state by >>>> the >>>> end of 2024 I meanwhile could refactor the results, some of my insights, >>>> and also a lot of my tooling. Additionally, I started to work on Maven 4 >>>> with it (and will also try to cover M3.6.3 as soon as possible). I will >>>> try >>>> to report more about this to you in the next weeks. You may already look >>>> into my complete epic report >>>> <https://github.com/support-and-care/maven-support-and-care/blob/wip/77-m >>>> av >>>> en-due-diligence/src/docs/epics/77-maven-due-diligence/index.adoc> (I am >>>> happy to discuss anything with you). >>>> >>>> For now I would like to focus on the most important changes, the >>>> so-called >>>> quick wins >>>> <https://github.com/support-and-care/maven-support-and-care/blob/wip/77-m >>>> av >>>> en-due-diligence/src/docs/epics/77-maven-due-diligence/index.adoc#quick-w >>>> ins>> >>>>> . Therefore, I kindly propose to make some (rather small) changes to >>>> >>>> incorporate my work into the Apache Maven codebase (which you will also >>>> find as appendix below). This would make further changes easier, and - as >>>> I >>>> said - enables further code analysis. The longer and more complex our >>>> forks >>>> get and stay, the harder it is to work seamlessly on them. I have already >>>> prepared some Draft PRs covering most of my changes. >>>> >>>> But let me start with a brief summary of my changes. >>>> I would like to drop certain components, at least from the reactor build, >>>> if not completely from the Maven Source. They are either archived or >>>> announced to become archived and sometimes cause some trouble to the >>>> build. If possible I am happy if we can even archive/drop more >>>> components in the future. Studies (at least the three from the report, >>>> causing trouble) Project Utilties (soon to be archived) >>>> Artifact Transfer (deprecated) >>>> Repository Tools (aka. Meeper; ~15 years old; doesn’t build for various >>>> reasons, is not used somewhere in the other projects) Maven 3: The >>>> required >>>> changes are very small (one duplicate file removal, three times setting >>>> the >>>> Java Version from 7 to 8 as JDK 21 no longer builds with source/target >>>> set >>>> to 7). Maven 4: Requires some more changes (Upgrade of Parent POM version >>>> in 4 cases; Adding some dependency versions; dropping parent. >>>> relativePath >>>> here and there; Refactoring a method to less than 150 lines; Applying >>>> Spotless). >>>> >>>> To show the problems and successful application of the changes I have >>>> added >>>> GH Actions (copied from project with existing GH Action) to the >>>> respective >>>> repositories (links below). As the Maven 3 changes are almost trivial, I >>>> spared the PRs but could raise separate PRs for M3 if desired. For the M4 >>>> changes they were mostly small, except for the spotless application which >>>> reformatted several files (In fact, for the new format there were no >>>> semantical changes as far as I could see). Would you in general accept >>>> the >>>> respective PRs? Then I would make them final and we could perhaps discuss >>>> details during the PR process. >>>> >>>> I understand that it is common to raise a Jira first when working on some >>>> open issue. If desired, I could create Jira tickets (or GH issues) in the >>>> respective components. Or I could just raise one (where)? Then I would >>>> refer to the ticket(s) in the PRs when making them final. >>>> >>>> As outlined above there are some more improvements in my pipeline, but I >>>> wanted to get the ball rolling and rather push changes in small portions. >>>> >>>> Looking forward to get some feedback from you. >>>> >>>> Have a good start into the week, >>>> >>>> Gerd >>>> >>>> P.S.: Sorry for the inconvenience I caused to some of you by creating >>>> draft >>>> PRs (and reworking or even closing them). I promise to get used to the >>>> project standards. -- >>>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) >>>> +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net >>>> >>>> >>>> Quick wins >>>> >>>> To visualize the problems and the results of below discussed quick wins, >>>> we >>>> added a build to the Maven projects. Both currently make use of JDK 21 >>>> and >>>> Maven 3.9.9, as well as Maven 4.0.0-RC-2. We can show the initial results >>>> of the builds (without changes), and the results for both Maven versions. >>>> >>>> It is clear, that this does not yet cover all remaining (and to be >>>> detected) open problems of the Maven build. For instance, it does not >>>> yet cover full integration tests, or documentation checks. Nevertheless, >>>> it is a starting point which allows for step-by-step improvements. In >>>> particular, it allows to build the projects (and execute at least their >>>> unit tests) with the required JDK and currently two out of three >>>> supported Maven versions. >>>> >>>> For each of the single repositories below (running mvn verify), the build >>>> (on the respective PRs) is successful (both M3 and M4). See the build >>>> links >>>> in the discussion below. For the reactor build (running mvn install >>>> site.[1 >>>> <x-msg://54/#_footnotedef_1>]), it is a bit more complicated. For Maven >>>> 3.9.9, the build is successful, but with some errors (resulting from site >>>> building). For Maven 4.0.0-RC-2, the build still has some problems, and >>>> it >>>> will take us some time to resolve them (→ Work-in-Progress). We derived >>>> following tasks from the current state above. They make sure that we can >>>> at >>>> least execute the Maven build with the required JDK and Maven versions >>>> without running into basic build problems. >>>> >>>> Triage >>>> Check with the Maven committers if we could thin out the reactor build >>>> and >>>> the overall Maven Source and Reactor Build >>>> <x-msg://54/#box:maven-source>. >>>> >>>> Archive unnecessary components. >>>> Drop them from the Maven Source (or at least from the reactor build; >>>> Draft >>>> PR for both M3 and M4 <https://github.com/apache/maven-sources/pull/13>). >>>> The reactor build would become easier if the following components would >>>> be >>>> dropped from the reactor build The so-called Maven Studies (as they are >>>> causing trouble, cf. our forks), Consumer POM >>>> <https://github.com/apache/maven-studies/tree/consumer-pom> (Sac: fork >>>> <https://github.com/support-and-care/maven-studies/tree/consumer-pom>, >>>> bugfix >>>> <https://github.com/support-and-care/maven-studies/tree/bugfix/77-make-pr >>>> oj >>>> ect-build-again-consumer-pom>, Successful GH Action with M3 >>>> <https://github.com/support-and-care/maven-studies/actions/runs/127334566 >>>> 92 >>>> >>>>> ), Extension Demo Study >>>> >>>> <https://github.com/apache/maven-studies/tree/maven-extension-demo> (SaC: >>>> fork >>>> <https://github.com/support-and-care/maven-studies/tree/maven-extension-d >>>> em >>>> o>, bugfix >>>> <https://github.com/support-and-care/maven-studies/tree/bugfix/77-add-mav >>>> en >>>> -verify-maven-extension-demo>, Successful GH Action with M3 >>>> <https://github.com/support-and-care/maven-studies/actions/runs/127340235 >>>> 31 >>>> >>>>> ), Eventsound Extension Demo >>>> >>>> <https://github.com/apache/maven-studies/tree/maven-eventsound-extension> >>>> (SaC: fork >>>> <https://github.com/support-and-care/maven-studies/tree/maven-eventsound-> >>>> >> ex >>>> tension>, bugfix >>>> <https://github.com/support-and-care/maven-studies/tree/bugfix/77-make-pr >>>> oj >>>> ect-build-again-maven-extension-demo>, Successful GH Action with M3 >>>> <https://github.com/support-and-care/maven-studies/actions/runs/127340235 >>>> 31 >>>> >>>>> ), The Maven Project Utils >>>>> <https://github.com/apache/maven-project-utils> >>>> >>>> as they are soon to be archived, The Maven Artifact Transfer >>>> <https://github.com/apache/maven-artifact-transfer> as it is deprecated >>>> and >>>> should be archived soon, and The Maven Repository Tools >>>> <https://github.com/apache/maven-repository-tools> (aka. Maven Meeper) >>>> from >>>> the reactor build (Draft PR for M3 >>>> <https://github.com/apache/maven-sources/pull/13> will be withdrawn) as >>>> It >>>> is archived (so no further development is expected), >>>> It has many non-straightforward problems (see below). >>>> For the next steps below we assume that the components mentioned above, >>>> will not survive the triage <x-msg://54/#desc-item:triage> and >>>> concentrate on the remaining components. Maven 3 (.9.9) Updates >>>> To enable successful build with Maven 3 (.9.9) the following changes are >>>> necessary. >>>> >>>> Maven Verifier Plugin <https://github.com/apache/maven-verifier-plugin> >>>> Update the Java version to at least Java 8, and >>>> Drop duplicate license from VerifierMojo.java >>>> <https://github.com/apache/maven-verifier-plugin/blob/1330656e1945dfe7ef1 >>>> a1 >>>> f3e8034b64138887f10/src/main/java/org/apache/maven/plugins/verifier/Verif >>>> ier Mojo.java#L29> as it leads to a checkstyle error due to splitting the >>>> import statements. Maven Stage Plugin >>>> <https://github.com/apache/maven-stage-plugin>: Update the Java version >>>> to >>>> at least Java 8 Maven Mapping <https://github.com/apache/maven-mapping>: >>>> Update the Java version to at least Java 8 Maven 4 (.0.0-RC-2) updates >>>> To enable successful build with Maven 4 (.0.0-RC-2) the following changes >>>> are necessary. >>>> >>>> Maven Shared IO <https://github.com/apache/maven-shared-io> (Draft PR for >>>> M3 <https://github.com/apache/maven-shared-io/pull/27>, also works with >>>> M4; >>>> Successful GH Action >>>> <https://github.com/support-and-care/maven-shared-io/actions/runs/1273404 >>>> 21 >>>> 42>): Upgrade to Parent version 43, >>>> and add Plexus-XML dependency (in test scope). >>>> Maven Verifier Plugin (Draft PR >>>> <https://github.com/apache/maven-verifier-plugin/pull/6>, Successful GH >>>> Action >>>> <https://github.com/support-and-care/maven-verifier-plugin/actions/runs/1 >>>> 27 >>>> 38839164>): Upgrade to Parent version 43. >>>> Apply Spotless to the codebase. >>>> Maven Stage Plugin (Draft PR >>>> <https://github.com/apache/maven-stage-plugin/pull/15>, Successful GH >>>> Action >>>> <https://github.com/support-and-care/maven-stage-plugin/actions/runs/1273 >>>> 88 >>>> 68925>): Drop parent.relativePath. >>>> Refactor DefaultRepositoryCopier::copy to use less than 150 lines of >>>> code. >>>> Upgrade to Parent version 43. >>>> Apply Spotless to the codebase. >>>> Maven Mapping (Draft PR <https://github.com/apache/maven-mapping/pull/8>, >>>> Successful GH Action >>>> <https://github.com/support-and-care/maven-mapping/actions/runs/127341506 >>>> 20 >>>> >>>>> ): Drop parent.relativePath. >>>> >>>> Upgrade to Parent version 43. >>>> Apply Spotless to the codebase. >>>> >>>> >>>> >>>> -- >>>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) >>>> +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> -- >> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) >> +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
