Re: Module paths and tool integrations
On behalf of Hendrik Ebbers who seems to have problems posting to this list currently. Please keep him and Karl Heinz up to date with ongoing efforts. Hi, We defined work items on the module path/classpath support for Maven for the Maven Support & Care project that will be funded by the German government (see https://github.com/OpenElements/maven-support-care). It is unclear today who will work on that issue (we have some freelancers from the Maven ecosystem with whom we already made contracts), but it will make sense to attend such a group. Maybe Karl-Heinz and me will be a good start. Best, Hendrik > On 8. Nov 2024, at 11:39, Robert Scholte wrote: > > I've met Nicolai yesterday, we'll probably start soonish. It's not sure if > the group is complete, but at some moment we just need to start. Joining > later is of course still a possibility. > > Robert > > -Original Message- > From: Martin Desruisseaux > Sent: vrijdag 1 november 2024 11:41 > To: dev@maven.apache.org > Subject: Re: Module paths and tool integrations > > Hello > > Le 2024-11-01 à 08 h 23, Ozgun Oz a écrit : > >> I would love to at least have a view on the discussions as an >> observer. I think what Olivier propose, "making the group/discussion >> public" would be great help to the community. >> > The discussion did not started yet (or if it did, I didn't realized). I would > be happy with open discussion, but let see what Robert thinks. > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional > commands, e-mail: dev-h...@maven.apache.org > > > > ----- > 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
Re: [DISCUSS] Switch to GitHub issues
For the sake of completeness: I asked Chris Dutz whether he was aware of other ASF projects moving from Jira to GH issues. * He performed such migration for the PLC4X project (but didn’t leave any tools to automate that?). Here is a sample for a migrated issue: https://github.com/apache/plc4x/issues/581 * He mentioned other ASF projects (SteamPipe, IoTDB) which might have done migrations or hybrid issue management. Perhaps someone is aware of other ASF projects as well or has a contact for more information? > On 6. Dec 2024, at 14:40, Sandra Parsick wrote: > > I asked on other channels, how Spring migrated their Jira issues. I got a > link to their migration tool: > > https://github.com/rstoyanchev/jira-to-gh-issues > > An updated version can be found here: > https://github.com/rwinch/jira-to-gh-issues > > I reviewed the code a little, and it appears that the code is generic enough > to give it a trial. > I will invest some time to do a dry run and share my experience with it. > > Another idea: > > Maven Tycho project also moved from Bugzilla to Github issue. The "migration" > was set Bugzilla project read only and only issues were moved to Github which > was actively in work. > > Sandra > > > Am 04.12.24 um 08:36 schrieb Sandra Parsick: >> My 2 cent from a user perspective: >> Spring's approach has a benefit. As a user, I need only search for an issue >> in only one location. >> But I also understand Michael's point, that it is a chance for a cleanup of >> the backlog. >> Regardless of whether all issues should be migrated or not, I could ask the >> Spring Team if they could tell more about how they did it. >> Maven Support and Care has an epic about Backlog Grooming [1] and IMHO the >> migration from Jira to Github issue could be a good first task in this epic >> (of course, after a decision about the How). >> Sandra >> [1] https://github.com/OpenElements/maven-support-care/issues/42 >> Am 25.11.24 um 17:36 schrieb Guillaume Nodet: >>> They seem to have migrated the issues from JIRA to GitHub. That would be >>> #1 option, but I'm not sure if we need to go into that direction. >>> >>> Le ven. 22 nov. 2024 à 17:28, Arnaud Héritier a >>> écrit : >>> >>>> I know spring teams did such move in the past >>>> ref: >>>> >>>> https://spring.io/blog/2019/01/15/spring-framework-s-migration-from- >>>> jira-to-github-issues >>>> But I didn't see anything easily reusable... >>>> >>>> On Fri, Nov 22, 2024 at 12:17 PM Michael Osipov >>>> wrote: >>>> >>>>> I'd like to complete the cleanup, as dicussed earlier, end of this year. >>>>> This will give us a leaner migration base. >>>>> >>>>> On 2024/11/22 11:03:09 Guillaume Nodet wrote: >>>>>> Following the discussion that happened some time ago about switching to >>>>> GH >>>>>> issues... >>>>>> I think we have several options: >>>>>>1/ try to migrate issues and make JIRA read only >>>>>>2/ make all our JIRA projects unable to create new issues and new >>>>> issues >>>>>> would be raised on GH >>>>>>3/ do not change JIRA but slowly switch to GH >>>>>> >>>>>> #1 looks not feasible, so I rule it out, unless someone knows about >>>>> tools, >>>>>> but I don't really see how we could recreate history... >>>>>> >>>>>> #2 would simply require a switch that could be easily requested to >>>> INFRA, >>>>>> but until we have made changes to all projects on github, it could be >>>>>> problematic as JIRA would be read-only while some projects may not have >>>>>> issues enabled yet >>>>>> >>>>>> The reason for #3 would be to migrate projects not all in one shot. >>>> All >>>>>> projects use the same permission scheme in JIRA. I think changing the >>>>>> scheme would require JIRA administrator privileges, so I don't think >>>> any >>>>>> PMC member can do that easily. However, I know some projects which >>>> have >>>>>> done such migration and used JIRA and GH in parallel. I.e. the source >>>>> for >>>>>> release notes would be switched to GH and issues would be either GH >>>>> issues >>>>>> or JIRA issues. This is the least disrupting option. At some point, >>>> we >>>>>> can decide to go to #2. >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> -- >>>>>> >>>>>> Guillaume Nodet >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Guillaume Nodet >>>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> >>>> -- >>>> Arnaud Héritier >>>> Twitter/GitHub/... : aheritier >>>> >>> >>> > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Re: [DISCUSS] Switch to GitHub issues
> On 14. Dec 2024, at 18:16, Slawomir Jaranowski wrote: > > On Fri, 13 Dec 2024 at 12:12, Gerd Aschemann wrote: >> >> I see some drawbacks >> >> Before opening a new issue, I would like to search for similar issues (and >> in particular if there are already solutions, workarcounds, more information >> about the environment etc.). Where should I search? First du a Jira search, >> then a GitHub search? >> If I find something in Jira, but it is not yet in GH, how could I refer to >> it? Put in some link to Jira in some new GH issue manually. This is not >> recognised by Jira, so linking between related issues in the two systems get >> lost). Well, you can build some GH Action around it, but its complicated and >> error prone as it is hard do formalize. >> If people ignore the hint in Jira that the issue was moved to GH and keep on >> commenting, things become inconsistent as this something like a split brain >> on issue level. Can this be prevented for single issues as soon as they are >> migrated, but left open for non-migrated Jira issues (I doubt that it is >> possible)? >> If a user or contributor wants to comment or work/elaborate on an issue >> which is not yet migrated they first might need to find/convince a committer >> to migrate it. >> >> That said, I think partial migration (on issue-by-issue) could be >> semi-automated: Open a new GH issue with a particular template providing the >> Jira issue number. Then have a GH Action to perform the migration (and first >> check whether the issue is not yet migrated; then directly close the new >> issue as duplicate). >> > > We always have similar problems ... every time we will have a > duplicate issue, duplicate comments and so on ... Well, I had the assumption, that once you migrate a project from Jira to GitHub (completely), the respective Jira project is set to read-only (no more changes possible, except perhaps for administrators). This would make GitHub the active issue asset and every work would be done there. And yes, that would be a reason to perform a complete migration (per project), not a partial one. Technically, Jira projects could also be archived, but then becoming more or less invisible, making a lot of links on the Internet immediately invalid besides other drawbacks. > >>> On 12. Dec 2024, at 12:05, Sylwester Lachiewicz >>> wrote: >>> >>> Yes, make sense - also +1 >>> >>> Sylwester >>> >>> czw., 12 gru 2024, 11:50 użytkownik Guillaume Nodet >>> napisał: >>> >>>> I'm also +1 on this way forward. >>>> >>>> Le jeu. 12 déc. 2024 à 10:58, Slawomir Jaranowski >>>> a écrit : >>>> >>>>> Hi, >>>>> >>>>> On Thu, 12 Dec 2024 at 10:15, Christoph Läubrich >>>>> wrote: >>>>>> >>>>>> I just wanted to note with Eclipse moved form Bugzilla > Github it was >>>>>> done the following way: >>>>>> >>>>>> 1. We have had a script adding a comment to each open issue in Bugzilla >>>>>> like this [1] >>>>>> 2. Then each developer that finds an issue important enough has >>>> migrated >>>>>> it manually with a link to the old. >>>>> >>>>> This is also my favorite way :-) >>>>> - enable GitHub Issues in project >>>>> - we can add a comment to open issues by bulk operation in jira >>>>> - disable creating new issues in jira >>>>> - do it project by project ... >>>>> >>>>>> 3. Close the the Bugzilla with a link to github >>>>>> >>>>>> This was actually a good thing, as a lot of old stuff no one cared >>>>>> anymore about is not ported to github, and still people can see the >>>>>> "link" for relevant discussions and if anyone wants to pickup it can be >>>>>> done anytime later. >>>>>> >>>>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502349#c11 >>>>>> >>>>>> Am 12.12.24 um 09:42 schrieb Olivier Lamy: >>>>>>> Agree too. >>>>>>> We can leave them open in Jira with a comment including the link to >>>>>>> the GH issue. >>>>>>> And if the people involved in the issue are really still interested >>>>>>> (few issues might be already fixed but we haven;t done triage becaus
Re: [DISCUSS] Switch to GitHub issues
gt; more devs spent more time triaging old bugs, they'd find more >> too. >>>>>>>>> >>>>>>>>> I agree with this! From a reporter point-of-view, it is extremely >>>>>>>>> demotivating to see a report that you wrote getting ignored for a >>> couple >>>>>>>>> of years only to be closed for "administration reasons". Don't do >>> this. >>>>>>>>> It made me stop contributing (by reporting issues) to a few >>> projects >>>>>>>>> already, because they basically didn't seem to care. >>>>>>>>> >>>>>>>>>> I'd also like to encourage people to deliberately close bugs >> that >>> are >>>>>>>>>> in fact invalid, unwise, or already fixed. Surprisingly often I >>> find a >>>>>>>>>> final comment from an active committer or PMC member that lays >>> out in >>>>>>>>>> detail how the bug has been addressed or why it shouldn't be >>>>>>>>>> addressed, but they have not pressed the button to close the >> bug. >>>>>>>>>> Please press the button. However, this needs to be done issue by >>>>>>>>>> issue, not as a bulk close of all issues older than some >> arbitrary >>>>>>>>>> date. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Rather do this. If we are sure something is not a bug, take the >>> time to >>>>>>>>> explain it and then close it. If the reporter thinks we're wrong, >>> they >>>>>>>>> can always re-open. Closing an issue with solid reasoning is much >>> better >>>>>>>>> than closing it because it was opened more than X years ago. >>>>>>>>> >>>>>>>>> >>>>>>>>> Maarten >>>>>>>>> >>>>>>>>> >>> - >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>> - >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>>> -- >>>>>>> Elliotte Rusty Harold >>>>>>> elh...@ibiblio.org >>>>>> >>>>>> >> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> >>> -- >>> Sławomir Jaranowski >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> -- >> >> Guillaume Nodet >> -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Re: Refactor (some) Maven builds for individual and reactor builds (M3.9.9 is working; M4.0.0-RC-2 in preparation)
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 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 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 >
Re: Refactor (some) Maven builds for individual and reactor builds (M3.9.9 is working; M4.0.0-RC-2 in preparation)
> On 13. Jan 2025, at 08:01, Hervé Boutemy 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/sup
Re: Refactor (some) Maven builds for individual and reactor builds (M3.9.9 is working; M4.0.0-RC-2 in preparation)
> On 13. Jan 2025, at 09:00, Slawomir Jaranowski wrote: > > On Mon, 13 Jan 2025 at 03:53, Gerd Aschemann 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. I didn’t want to start a QA tool discussion. Personally I have some experience with jQA(ssistant) and use it to work myself into large code bases. Though it covers some static analysis, for me the greatest strength is its modular architecture and its many plugins and extensions. This allows to scan many of the contents of a code base (also configurations and documentation) and reason about it. jQA can also scan byte code and load relationships across modules on a component and code base (and even Git) into its graph database. But as I said, I will not start a tool discussion. It will help me and I can show you some of it’s reports from time to time. We always should look critically to the results and reports as it is very powerful but you could also evaluate the wrong things. When some eventually thinks it is a benefit to make use of it on a broader base, we should discuss it. -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Refactor (some) Maven builds for individual and reactor builds (M3.9.9 is working; M4.0.0-RC-2 in preparation)
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-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 pr
Re: Using git forks
I am about to run some analysis of the overall Maven project with jQAssistant in the next weeks (currently I am fighting with some problems with the tool as it is really a large codebase).However, as a quick win I can provide some data about the number of branches.The attached Excel lists all (133) projects and their current number of branches. Some numbers are large (~30% have 10 or more branches).I hope I should be able to give more detailed reports in the next weeks. It should also be possible to correlate branches to Jira issues (if they are mentioned in the branch name or commit messages) and cross check whether they are still necessary.Additionally it should be possible to identify branches which are not correlated to some ticket and sort out with the latest committers what is the purpose of the branches. no-of-branches-per-component.xlsx Description: MS-Excel 2007 spreadsheet On 4. Jan 2025, at 21:12, Andy Law wrote:I’m a lurker on this list, albeit one that’s wanting to find time to add a feature to the enforcer plugin.I’m with Tamás on this, not least because then all code updates will be coming in through the same route, be they from you outstanding worthies or from us occasional self-interest contributors.Later,AndyFrom: Elliotte Rusty Harold Date: Saturday, 4 January 2025 at 18:02To: Maven Developers List Subject: Re: Using git forksThis email was sent to you by someone outside the University.You should only click on links or attachments if you are certain that the email is genuine and the content is safe.On Sat, Jan 4, 2025 at 4:20 PM Tamás Cservenák wrote:But to continue: what will happen to branches named like "mdo","apidoc", "copy", "null" etc in _cnonical maven repo_ if you gomissing?Branches are cheap, but the way these things work if these aren'tcleaned up manually, eventually the project will move off git andgithub and throw away its history. All this has happened before, andall this will happen again .I've worked on enough Github hosted projects where all committers usebranches and only branches to be reasonably confident that the problemis not the use of branches. Branches are how git works, and they workjust fine. Maven does seem to have a lot of old tooling that needswork, though I'm not sure who has the knowledge or permissions to dothat. But meanwhile adding more layers of rules for developers tofollow instead of fixing broken tooling — like apparently whatever issending commit messages to the mailing list — is not the way to go.--Elliotte Rusty Haroldelh...@ibiblio.org-To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgFor additional commands, e-mail: dev-h...@maven.apache.orgThe University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336. --Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)+49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Re: Leveraging SonarQube Cloud (fka SonarCloud)
> On 4. Jan 2025, at 22:28, Slawomir Jaranowski wrote: > > On Thu, 2 Jan 2025 at 14:10, Konrad Windszus wrote: >> >> Hi, >> Maven currently does not leverage SonarQube analysis (nor any other static >> code analysis). Although onboarding currently requires one INFRA ticket per >> repo >> (https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=SonarCloud+for+ASF+projects) >> this is a one time action and the benefits from my PoV outweigh the efforts. >> >> The UI exposes important metrics (look e.g. at >> https://sonarcloud.io/summary/new_code?id=apache_jackrabbit-filevault-package-maven-plugin&branch=master) >> and there is also integration in GitHub PRs >> (https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/) >> and IDEs >> (https://docs.sonarsource.com/sonarqube-cloud/improving/sonarlint/). In >> addition one can configure quality gates with regards to code coverage or >> issues >> (https://docs.sonarsource.com/sonarqube-cloud/improving/quality-gates/). >> >> Leveraging this would improve the code quality and gives some pointers on PR >> quality. >> WDYT about enabling this for https://github.com/apache/maven? > > I use sonar in my work and I like it but for analizes we need to > provide a token ... it will not be possible in a simple way for PR > from forked repo. > So we have analize on master branches ... and it will be too late > I am afraid that we have next reports like we have for checkstyle, pmd > which will not be maintained … Granting the “Execute Analysis” permissions to anyone should enable checks from local machines, as well as from PRs (GitHub actions). That being said, I was recently told by SonarCloud support staff that granting this permission to anyone is a bad idea: https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/7?u=ascheman - And that they even drop that in the future. It is not yet clear to me, why they consider this _a very bad idea_? Perhaps since one could also upload analysis results to the project? I have asked back what is the background: https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/12 I still think that it is nice to check for the quality gate, even anonymously. Probably it should not be possible to publish results to the server. Then they should split the permission: Enable analysis for anyone, but prohibit uploading of results unless particular upload permissions are set for the user represented by a token. -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Re: Leveraging SonarQube Cloud (fka SonarCloud)
The link is more than three years old. One of the replies from SonarQube contains a link that states that it is meanwhile (Aug 24) possible for projects configured for Automatic Analysis (https://portal.productboard.com/sonarsource/1-sonarqube-cloud/c/50-sonarcloud-analyzes-external-pull-request). > On 5. Jan 2025, at 10:21, Slawomir Jaranowski wrote: > > https://community.sonarsource.com/t/code-analysis-on-pull-request-from-forked-repository-with-github-actions/43986 > > On Sun, 5 Jan 2025 at 02:58, Gerd Aschemann wrote: >> >> >> >>> On 4. Jan 2025, at 22:28, Slawomir Jaranowski >>> wrote: >>> >>> On Thu, 2 Jan 2025 at 14:10, Konrad Windszus wrote: >>>> >>>> Hi, >>>> Maven currently does not leverage SonarQube analysis (nor any other static >>>> code analysis). Although onboarding currently requires one INFRA ticket >>>> per repo >>>> (https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=SonarCloud+for+ASF+projects) >>>> this is a one time action and the benefits from my PoV outweigh the >>>> efforts. >>>> >>>> The UI exposes important metrics (look e.g. at >>>> https://sonarcloud.io/summary/new_code?id=apache_jackrabbit-filevault-package-maven-plugin&branch=master) >>>> and there is also integration in GitHub PRs >>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/) >>>> and IDEs >>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/sonarlint/). In >>>> addition one can configure quality gates with regards to code coverage or >>>> issues >>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/quality-gates/). >>>> >>>> Leveraging this would improve the code quality and gives some pointers on >>>> PR quality. >>>> WDYT about enabling this for https://github.com/apache/maven? >>> >>> I use sonar in my work and I like it but for analizes we need to >>> provide a token ... it will not be possible in a simple way for PR >>> from forked repo. >>> So we have analize on master branches ... and it will be too late >>> I am afraid that we have next reports like we have for checkstyle, pmd >>> which will not be maintained … >> >> Granting the “Execute Analysis” permissions to anyone should enable checks >> from local machines, as well as from PRs (GitHub actions). >> >> That being said, I was recently told by SonarCloud support staff that >> granting this permission to anyone is a bad idea: >> https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/7?u=ascheman >> - And that they even drop that in the future. >> It is not yet clear to me, why they consider this _a very bad idea_? Perhaps >> since one could also upload analysis results to the project? I have asked >> back what is the background: >> https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/12 >> >> I still think that it is nice to check for the quality gate, even >> anonymously. Probably it should not be possible to publish results to the >> server. Then they should split the permission: Enable analysis for anyone, >> but prohibit uploading of results unless particular upload permissions are >> set for the user represented by a token. >> >> -- >> 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 > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
Re: Leveraging SonarQube Cloud (fka SonarCloud)
I have quickly started to analyze core/maven: https://sonarcloud.io/summary/overall?id=support-and-care_maven&branch=master As this project (and almost all of the other Maven projects) does not have any (JaCoCo) test coverage you can only see static analysis results. > On 2. Jan 2025, at 14:19, Elliotte Rusty Harold wrote: > > Can we have some examples of the output? I'd want close to zero false > positives and no log junk before doing this. > > Generally static analysis is useful on a one-off basis, but there are > rapidly diminishing returns for running it on the same codebase. > > > > On Thu, Jan 2, 2025 at 1:10 PM Konrad Windszus wrote: >> >> Hi, >> Maven currently does not leverage SonarQube analysis (nor any other static >> code analysis). Although onboarding currently requires one INFRA ticket per >> repo >> (https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=SonarCloud+for+ASF+projects) >> this is a one time action and the benefits from my PoV outweigh the efforts. >> >> The UI exposes important metrics (look e.g. at >> https://sonarcloud.io/summary/new_code?id=apache_jackrabbit-filevault-package-maven-plugin&branch=master) >> and there is also integration in GitHub PRs >> (https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/) >> and IDEs >> (https://docs.sonarsource.com/sonarqube-cloud/improving/sonarlint/). In >> addition one can configure quality gates with regards to code coverage or >> issues >> (https://docs.sonarsource.com/sonarqube-cloud/improving/quality-gates/). >> >> Leveraging this would improve the code quality and gives some pointers on PR >> quality. >> WDYT about enabling this for https://github.com/apache/maven? >> >> Regards, >> Konrad >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > 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
Re: 404 error
Hi, this looks like a Gradle issue and has presumably nothing to do with Apache Maven or the respective infrastructure (like Maven Central which was used by you). You can find the plugin on the Gradle Plugin Portal (GPP): https://plugins.gradle.org/search?term=gradle-scalastyle-plugin Perhaps you need to configure your Gradle project accordingly (e.g., drop your own customisations, as Gradle should resolve plugins automatically via GPP). Please consult with an Gradle expert if you cannot resolve it. Cheers Gerd > On 11. Mar 2025, at 13:59, Brian Proffitt wrote: > > Forwarded from apa...@apache.org. Please respond to the original sender, if > you choose to reply. > > BKP > > -- Forwarded message - > From: Yan Alexeenko > Date: Tue, Mar 11, 2025 at 3:23 AM > Subject: 404 error > To: > > > Hello! I'm trying to build our Java project and I'm getting a 404 error > when trying to download one of the dependencies: > https://repo.maven.apache.org/maven2/org/github/ngbinh/scalastyle/gradle-scalastyle-plugin_2.11/0.9.0/gradle-scalastyle-plugin_2.11-0.9.0.pom > > this file not found, please help, how can I download it? > > Best regards, > Yan Alexeenko. > > > > Brian Proffitt > VP, Marketing & Publicity > VP, Conferences -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
