On Mon, 13 Jan 2025 at 03:53, Gerd Aschemann <g...@aschemann.net> wrote: > > 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/>.
Static code analysis is generally a good idea. But I'm not sure if it is our biggest problem. Before we choose a specific tool for it, we should answer such questions: - Do we want to break the build in case of an issue in static analysis? - Do we want to report issues from static analizes? - Do we have the power to fix such issues? - How do we manage the rules? We already have reports from PMD, like: https://maven.apache.org/plugins/maven-clean-plugin/pmd.html We use standard rules for ..... maybe we should work on rules - step by step PMD can be easy enabled in build and developer can have a feedback very quickly. The tool should be chosen at the and when we have a requirement and we know how we work with it. > > 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-maven-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-maven-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-project-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-demo>, > 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-extension>, > bugfix > <https://github.com/support-and-care/maven-studies/tree/bugfix/77-make-project-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/1330656e1945dfe7ef1a1f3e8034b64138887f10/src/main/java/org/apache/maven/plugins/verifier/VerifierMojo.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/12734042142>): > 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/12738839164>): > 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/12738868925>): > 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 > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
