oh, someone who seriously tries to maintain Maven Source Aggregator: nice! https://github.com/apache/maven-sources/tree/master/aggregator
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 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. 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 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-mav > 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-mav > en-due-diligence/src/docs/epics/77-maven-due-diligence/index.adoc#quick-wins > >. 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-proj > ect-build-again-consumer-pom>, Successful GH Action with M3 > <https://github.com/support-and-care/maven-studies/actions/runs/12733456692 > >), 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-dem > o>, bugfix > <https://github.com/support-and-care/maven-studies/tree/bugfix/77-add-maven > -verify-maven-extension-demo>, Successful GH Action with M3 > <https://github.com/support-and-care/maven-studies/actions/runs/12734023531 > >), 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-proj > ect-build-again-maven-extension-demo>, Successful GH Action with M3 > <https://github.com/support-and-care/maven-studies/actions/runs/12734023531 > >), 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/1330656e1945dfe7ef1a1 > f3e8034b64138887f10/src/main/java/org/apache/maven/plugins/verifier/Verifier > 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/127340421 > 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/127 > 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/127388 > 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/12734150620 > >): 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
