+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
