[RESULT][VOTE] Require Java 17 for Maven 4

Hi all, the vote has passed with the following result: PMC +1: Anders Hammar, Arnaud Héritier, Benjamin Marwell, Guillaume Nodet, Hervé Boutemy, Karl Heinz Marbaise, Konrad Windszus, ,Maarten Mulders, Olivier Lamy, Romain Manni-Bucau, Sylwester Lachiewicz, Tamás Cservenák PMC majority quorum

Re: [VOTE] Require Java 17 for Maven 4

Elliotte, as per guidelines, it is not required. And I did not put it that way in my email. However, a reason would have helped in finding alternatives. Anyway, here's my +1. On Fri, 1 Mar 2024, 19:14 Elliotte Rusty Harold, wrote: > On Wed, Feb 28, 2024 at 2:31 AM Benjamin Marwell >

Re: [DISCUSS] Java version for Maven

At this point, we have discussed many aspects. Please feel to vote: User List: https://lists.apache.org/thread/ty321ns72qc6l26bjy58d9430ofg2w5t Dev List: https://lists.apache.org/thread/vngchrr3owd92v9y09lyfjjhwkl5hvtn - To

[VOTE] Require Java 17 for Maven 4

Hi Maven Devs/Users/Committers and PMC members! After several discussions on the mailing lists, I would like to start a vote in favour of setting the minimal Java bytecode target of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. This is a procedural majority vote [1*]: You can also

Re: [DISCUSS] Java version for Maven

Rusty Harold, wrote: > On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell > wrote: > > > > > 1. The Java version required by the project being built. That is, the > > byte code and API level of the project. > > > 2. The Java version used to compile the proj

Re: [DISCUSS] Java version for Maven

> 1. The Java version required by the project being built. That is, the byte code and API level of the project. > 2. The Java version used to compile the project. > 3. The Java version used to run Maven. > 4. The Java version used to compile and build Maven itself. > For #1, it is mandatory to

Re: [DISCUSS] Java version for Maven

Brian, any Chance you could make a stacked 100% graph for every *week* of the past two years? We could then see where we are heading… (or the raw numbers per week, so we could work with that). That's probably a lot to ask, but I think it will show us how "fast" the progression was (and will be).

Re: [DISCUSS] Java version for Maven

FWIW, bazel changed its runtime requirement to Java 21. But they are shipping their own Java Runtime, so their users won't notice. [1] I think they are the first build tool to do that. I say this as a FYI fact only, not implying anything. Make of it what you want. - Ben Am Di., 20. Feb. 2024

Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2

+1 for the release as it is +100 with the way Tamás put it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Use of jspecify in Maven

LL > > into it. If I'm too lazy to check my parameters than I deserve it to get > > NPE e.g. (funny enough an external coder with 20+ years of experience at > > my work just experience that exactly now, as he just relies that > > everything is always there...). > > &g

Re: Java version for Maven 4?

> we need to think about companies that pay for old JDK support There was a suggestion on slack that companies could provide "dev and release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose interest. This already works well for other projects. Even if no one stands up for

Re: Java version for Maven 4?

technical debt. It is just not justifiable for all the other users. I agree with Gary that an EOL schedule might be our best shot here. Am Mo., 5. Feb. 2024 um 19:56 Uhr schrieb Elliotte Rusty Harold : > > On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell wrote: > > > Why 17? 11 is o

Re: Java version for Maven 4?

Those who need Java 8 to *run* Maven will probably not upgrade to Maven 4 anyway, as their builds will have other problems preventing them from upgrading. A few third-party plugins already moved to Java 11+, thinking of spotless. That said: +1 Stick with 8 for Maven 3.9.x and maybe a 3.10.x (not

[ANN] Apache Maven JLink Plugin 3.2.0 Released

The Apache Maven team is pleased to announce the release of the Apache Maven JLink Plugin, version 3.2.0 The JLink Plugin is intended to create modular Java Run-Time Images via jlink. https://maven.apache.org/plugins/maven-jlink-plugin/ You should specify the version in your project's plugin

[RESULT] [VOTE] Release Apache Maven JLink Plugin version 3.2.0

Hi, The vote has passed with the following result: +1 : Sylwester, Romain, Slawomir, Tamás, Olivier, Hervé PMC quorum: reached I will promote the source release zip file to the Apache distribution area, the staging site to the live location and the artifacts to the central repo. Thanks! - Ben

[VOTE] Release Apache Maven JLink Plugin version 3.2.0

Hi, We solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321432=12349496 There are still two issues left in JIRA: https://issues.apache.org/jira/projects/MJLINK/issues Staging repo: https://repository.apache.org/content/repositories/maven-2064

Re: Java version for Maven 4?

To add some more information, I have seen some extreme reduction in build times after switching from Java 11 to 17 or even 21 (just for build, not the runtime). We can still verify it runs on 11/17 by using the integration tests, but having the (possibly parallel) unit- and integration tests

Re: maven-javadoc-plugin CI is borked

Adopt-OpenJ9 is now Semeru, and their v21 will be released next week if I am not mistaken. I'd love to keep that in, because it is the only JVM which does not run on hotspot. On Wed, 10 Jan 2024, 15:40 Slawomir Jaranowski, wrote: > śr., 10 sty 2024 o 13:58 Romain Manni-Bucau > napisał(a):

Re: [VOTE] Release Apache Maven Compiler Plugin version 3.12.1

+1 Thanks for the quick fix! On Thu, 21 Dec 2023, 08:54 Slawomir Jaranowski, wrote: > Hi, > > We solved 2 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225=12354061 > > There are still a couple of issues left in JIRA: > >

Re: Changing Minimum Build Requirements for plugins to JDK11

> We (as Maven developers) will have to use Java 11 to build plugins but > not be able to use Java 11 features in the code. > That sounds frustrating to me :) > Or I don't understand the change you are trying to propose? Not at all. This is how I did it at work. This already removes a lot of

Re: Changing Minimum Build Requirements for plugins to JDK11

Big +1 I sometimes need to switch back from JDK 21 to 17 or earlier to build some of the plugins. If we start building with 11+, we can detect build errors easier for newer JDKs. The spotless profile might not be the only profile we can remove. One catch, though. Should we not test on JDK8?

Re: Surefire Plugin: Tests failure on abstract class only shows the abstract class name

Hi Tison, do you have access to the issue tracker? https://issues.apache.org/jira/projects/SUREFIRE/issues Am Mo., 16. Okt. 2023 um 07:51 Uhr schrieb tison : > > Bubble up. Or where I can file an issue to track if it's likely an > improvement. > > Best, > tison. > > > tison 于2023年9月23日周六

Re: [VOTE] Release Maven Javadoc Plugin version 3.6.2

+1 Am So., 5. Nov. 2023 um 20:32 Uhr schrieb Michael Osipov : > > Am 2023-11-03 um 21:42 schrieb Michael Osipov: > > Hi, > > > > We solved 7 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12353815 > > > > There are still a couple of issues left in JIRA: > >

Re: [VOTE] Release Apache Maven Clean Plugin version 3.3.2

+1 On Mon, 23 Oct 2023, 08:11 Slawomir Jaranowski, wrote: > Hi, > > We solved 4 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735 > > There are still a couple of issues left in JIRA: > >

Re: [VOTE] Release Maven Dependency Plugin version 3.6.1

+1, but consider removing the dependency upgrade for commons from the release notes. It's been removed anyway. Improvement [MDEP-832] - Remove commons-collections-4 vs Dependency upgrade [MDEP-869] - commons-collections to 4.4 On Fri, 20 Oct 2023, 23:28 Michael Osipov, wrote: > Hi, > >

Re: [VOTE] Release Maven JXR version 3.3.1

+1 - Ben Michael Osipov schrieb am Fr., 20. Okt. 2023, 21:45: > Hi, > > We solved 6 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12352247 > > There are still a couple of issues left in JIRA: > >

Re: [VOTE] Apache Maven 4.0.0-alpha-8 release

+1. -- thanks! - Ben Guillaume Nodet schrieb am Fr., 20. Okt. 2023, 23:38: > I'm starting a new vote to release this new alpha. > > This alpha release provides new cornerstone features for the future Maven > evolution. > In particular, the POM model which was set in stone to a 4.0.0 version >

Re: Maven 5 pom extension for agents

com/rmannibucau> | > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > < > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > >

Re: Maven 5 pom extension for agents

, wrote: > What about type=java-agent? Basically a new ArtifactHandler? > > See https://maven.apache.org/repositories/artifacts.html > > T > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell wrote: > > > Hey all, > > > > In a mockito issue, JDK maintainers sug

Maven 5 pom extension for agents

Hey all, In a mockito issue, JDK maintainers suggested to differentiate between agents and normal dependencies. Starting with JDK 21 already, this makes a lot of sense: dynamic loading of agents will be a no-go. One suggestion was: ... ...

Re: [VOTE] Retire Maven Docck Plugin

+1 On Tue, 17 Oct 2023, 00:50 Slawomir Jaranowski, wrote: > Hi, > > - Last release was in 2015 > - use Maven 2.2.1 > - we have a Maven Plugin Tools - which should be one project for build and > check Maven plugins > - no active development ... > > >

Re: HPI plugin

Basil, I am a Maven committer. If you want to have replies from specific persons, don't use the developer mailing list. There is no such role as a core committer. There's only the PMC, which are not necessarily the most active committers. To be honest, I don't think "core" committers will give

Re: HPI plugin

Hello Basil, I wrote the mail while the ITs were running. Please note the naming issue is not "minor". It will break the build very soon. There's a reason for this: SEE: https://maven.apache.org/guides/plugin/guide-java-plugin-development.html QUOTE: You will typically name your plugin

Re: HPI plugin

Hi Basil, the first issue I see when using Maven 3.9.2: [INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ maven-hpi-plugin --- [WARNING] Artifact Ids of the format maven-___-plugin are reserved for plugins in the Group Id org.apache.maven.plugins Please change your artifactId to the

Re: [VOTE] Release Maven WAR Plugin version 3.4.0

+1 Am So., 11. Juni 2023 um 22:14 Uhr schrieb Michael Osipov : > > Hi, > > we solved 17 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12350597 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWAR/issues > >

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

Big +1 for an alternative format, but not sure HOCON is the best of all those out there. It surely is one of the better ones, though. Big plus is easiness to humans, no deps, external docs. However, TOML gained some popularity. I'd say Maven should ship no more than one alternative to XML. And

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Hunter, please keep to facts and do not get on a personal level: > It isn't OK to just ignore their input But then you say: > Your personal taste shouldn't [...] I think you just ignored some other dev's input yourself, as some already voted for JDK11+. > If you leave Java8, you leave behind

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Ok, here's a benefit of Java 11/17 or two: * Reduce build matrix, save energy * Attract devs * CDS for non-OpenJ9-users * Better clarity of code (yes, I mean that) * No additional work (we don't need to migrate, just use the features when modifying a line for a bug/feature anyway) * We leave no

Re: GH issues and GH discussions

I am pretty sure if that happens (terms changes, GH not an option), we have plenty of time to migrate. The same has happened multiple times in the past: SourceForge, BerliOS, Google Code... Now it is ASF JIRA and maybe some day we will be migrating away from GitHub Issues to something else? But

Re: GH issues and GH discussions

Big +1, as more and more projects are already migrating (including Apache Shiro). I'd vote for maven-jlink-plugin: Not many issues currently. > not having to create an issue if a PR exists first I'd at least make milestones mandatory in that case. It is far less work than maintaining an issue.

Re: [DISCUSSION] Apache Maven plugins versioning

The advantage is simple. With "maven4" in the module name, you don't need a compatibility matrix on every plugins homepage or readme. Just look at npm modules and webpack... Tables over tables... On Sun, 26 Mar 2023, 19:29 Michael Osipov, wrote: > Am 2023-03-26 um 19:02 schrieb Romain

Re: [DISCUSSION] Apache Maven plugins versioning

+1 to your proposal org.apache.maven:maven4-xyz-plugin: I don't think it would cause too much trouble as Maven APIs will love for a few years. It will only occasionally break when a new major Maven release is published. I can live with that. Also, maven 3 plugins will be compatible for a while.

Re: [DISCUSS] Apache Maven 4.0 with UTF-8 by default

Big +1! On Wed, 15 Mar 2023, 15:17 Jorge Solórzano, wrote: > Hi Maven Devs, > > I want to bring up the discussion about the default encoding used in > Maven, specifically Maven 4.0+ (since it's still in alpha it could be > done for that release or possibly wait another decade), we are in >

Re: [DISCUSS] m-remote-resources-p

No one ever told me about this convention and I knew about it the moment I saw the version numbers. However, Elliote is right, that's not semver. The alternative would be to put a lookup / compatibility table in each plugin's readme. But that would be so annoying as a user, because Maven is just

Re: [DISCUSS] m-remote-resources-p

+1 for dropping. Make it a new minor Version. We may want to add a migration strategy. But then, if there's not even a hit on GitHub... Just go with it. We do have a well working mailing list. On Fri, 10 Mar 2023, 10:56 Olivier Lamy, wrote: > not sure how useful this feature is... > I would

Re: Halve the logging

Sadly, --ntp also disables upload progress and ANY information associated with this. Maybe it would be beneficial to have an option for that. On Sun, 19 Feb 2023, 18:26 Michael Osipov, wrote: > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau: > > Not sure we can find an agreement on this

Re: extracting XML classes from plexus-utils to plexus-xml

+1 to what Romain said. Let's reduce dependencies to other orgs where possible and feasible. It is, in this case. On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, wrote: > Hi Hervé, > > As mentionned in the thread I think it makes sense to freeze plexus and > slowly import to maven the related

TomEE maven build analyses: Why only "mvn install" works and what to do about it

Hello everyone! Richard asked me a few days ago to take a look at the TomEE maven build, as it takes up to a few hours to complete. One issue is the jenkins setup, granted. But I have two findings. 1. shading Because a few deps, e.g. Apache MQ RA Client, still do not provide artifacts with the

Re: .well-known/security.txt at maven.apache.org

> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le dim. 20 nov. 2022 à 18:48,

.well-known/security.txt at maven.apache.org

Hi! Due to the recent GH activities (eg [1]), it came to my attention that there is no file ".well-known/security.txt" on maven.apache.org. We really should adopt it! For some more information, please refer to [2]. WDYT? - Ben [1]: https://github.com/apache/maven-project-utils/pull/5 [2]:

Re: [DISCUSS] Quo Vadis Maven Site

Please do NOT consider jbake. We (shiro team) ported the page to jbake, and it is really a mess. Many things are not supported which can easily be done in other static site generators. There is absolutely no progress. No java.time support. JSON/YAML support is broken and needs a lot of

Re: Maven does'nt find jar

Hi Raivo! This is a better question for the users list. The developer list is for maven development. But long story short: javax.xml.bind got removed from Java 9+. So even if you are compiling TO java 8 (e.g. using switches like maven.compiler.release or maven.compiler.target), it will still

Re: Logging in Maven Plugins - Bridging

> Maven Plugin code should use Plugin Api for logging purpose > In shared libraries used by Maven and maintained by us - we will use SLF4J directly I asked to be allowed to put this on the logging site, but we never had consensus of this. I agree  here, but ut really needs to get documented. I

Re: [DISCUSS] Automatically format and sort imports

+1, BUT in addition to Hervé's answer: Create a file '.git-blame-ignore-revs', which seems to be a common convention: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame This way, we can see CODE changes via diff/blame without those nasty formatting changes. --- For the

Re: [DISCUSS] Release Maven 4.0.0-alpha-1 this week

Unpopular opinion: Deactivate automatic push. If release:perform went well, push main and the tags. Besides, push --delete works for tags, too (if PMC agrees). I doubt there are already forks from the tag active anywhere. But yes, bumping the version is what we used to do in this case. - Ben

Re: Surefire 3.0.0-M7 has different modular behavior when compiler's --source flag is set to certain values

xports > jdk.compiler/com.sun.tools.javac.code=com.foo.mymodule and my module reads > jdk.compiler. All of that is incompatible with --release. > > Best, > Laird > > On Thu, Sep 1, 2022 at 11:47 PM Benjamin Marwell > wrote: > > > Can you give us a hint why

Re: Surefire 3.0.0-M7 has different modular behavior when compiler's --source flag is set to certain values

Can you give us a hint why you are using source and target instead of the release parameter? Am Fr., 2. Sept. 2022 um 01:10 Uhr schrieb Laird Nelson : > > The problem was difficult to uncover due to the swallowed exception at >

Re: JUnit 5 in maven-plugin-testing-harness

Haven't seen a discussion in Slack or on the mailing list, so I guess no. But I like the idea. Be aware that there are still Junit3 tests iirc. Updating would be a breaking change, but that's okay for the upcoming Maven 4 release. On Fri, 12 Aug 2022, 01:37 Vladimir V. Bychkov, wrote: >

Re: Suggestion for soft-breaking Maven Plugin 4.0 changes

e > > > > +1 > > > > -DtrimStackTrace=false. > > > > surefire has been changed in 3.0.0-M6 with this default value ;) > > > > > > Le jeu. 21 juil. 2022 à 20:24, Benjamin Marwell a > > écrit : > > > > > Hi everyone, >

Re: Question - JDK Minimum of future Apache Maven 4.0.0

No, 2 JDKs are not required by default. Only if you use --release={<17} and don't trust running tests on 17 are the same as running tests on 8. Yes, there are changes (certificates, XML libs, rhino, etc). So, for most projects that's probably not needed. For those who think it is needed, I don't

Re: Question - JDK Minimum of future Apache Maven 4.0.0

> > Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell a > écrit : > > > I was going to answer: go for 17. > > > > But running the tests on the same language level is really a good > argument. > > So much changed: HttpClient, TLS and cipher suit

Suggestion for soft-breaking Maven Plugin 4.0 changes

Hi everyone, as discussed in Slack, here are a few ideas for Maven 4.0 Plugin default's changes. Rationale: Convention over configuration, but things have diverged from when Maven 3 was started. * Set the default Java Source file encoding to UTF-8. This seems to receive a broad agreement. Not

Re: Question - JDK Minimum of future Apache Maven 4.0.0

I was going to answer: go for 17. But running the tests on the same language level is really a good argument. So much changed: HttpClient, TLS and cipher suites, DNS resolution (starting with Java 18 it will be pluggable!) etc. Yes, in theory it should not fail. But this is (sadly) a strong

Re: MojoExecutionException and MojoFailureException

Here you go. https://issues.apache.org/jira/browse/MSHARED-1032 On Mon, 11 Jul 2022, 20:21 Benjamin Marwell, wrote: > > Please note there are more exceptions, e.g. in reporting. That's always > been a problem. Not sure, but I must have opened an issue for this > somewhe

Re: MojoExecutionException and MojoFailureException

Please note there are more exceptions, e.g. in reporting. That's always been a problem. Not sure, but I must have opened an issue for this somewhere. Just for the sake of completeness. On Mon, 11 Jul 2022, 14:12 Guillaume Nodet, wrote: > Yes, that's why I only kept a single exception in the

Re: Social Media Plug-ins - Apache Maven pages

You can use this solution. https://github.com/heiseonline/shariff The PHP part is not needed, only if you want to display share count. It's widely known in Germany due to the c't magazine, but not much maintained anymore. Same applies to the forks. However, works like a charm. WDYT? On Sat,

Re: [ANN] Apache Maven Wrapper 3.1.1 Released

Thanks everyone involved, and thank you to Brian Demers for starting this project in the first place! On Sat, 14 May 2022, 16:07 Hervé Boutemy, wrote: > The Apache Maven team is pleased to announce the release of the Apache > Maven > Wrapper, version 3.1.1. > > The Maven Wrapper is an easy

Re: Help to create Maven Plugin for Checker Framework

Hi Daniele, sorry that no one has answered you in more than a month. We can all help with specific questions, but I guess there are too few volunteers to make it an ASF project. However, there is also the mojohaus organization which has seen some activity lately. Would that work for you? Am

Re: Checkstyle 10.0, Java 11, Maven Checkstyle Plugin, and toolchain support

Hi Tim, tbh I did not even notice, because I use Java 11 to compile Java 8 projects. You can either use the properties maven.compiler.source/target or maven.compiler.release (recommended for Java 9+). This would require Java 11+ for your build, but the compiled bytecode will still be Java 8

Re: Switch to Matomo Tracking code

undation > V.P., Data Privacy > > > On Sun, Mar 6, 2022, at 18:37, Benjamin Marwell wrote: > > > Exactly for this question I CC'd Martijn . You accidentally clicked on > "reply" instead of "reply all", I guess... > > You can also find us in #pri

Re: Switch to Matomo Tracking code

estions. On Sun, 6 Mar 2022, 12:04 Olivier Lamy, wrote: > Hi > looks good. > how do we have access to manage tracking id etc? > > On Sat, 5 Mar 2022 at 22:41, Benjamin Marwell wrote: > > > Hi everyone! > > > > The ASF now runs a public Mato

Switch to Matomo Tracking code

Hi everyone! The ASF now runs a public Matomo instance [1]. They are open for more projects now. If it is okay with you, we could add a tracking code to our site.xml file [2]. It is an easy change, just add a body-head section [4]. Even if you do not agree to add Matomo, I will create a PR to

[MNG-7393] API change reguested for Maven 4

Hi everyone, I would like to change the API from the ReportMojo. I was recently looking at https://github.com/apache/maven-reporting-impl/blob/9050da0e7c2defed851621b62c0160b52716ba11/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L338-L342 But it seems the method boolean

Re: Commit Review Policy

Hi! Aside from typo fixes, PRs might slow down the dev speed, but greatly improve code quality. Even small PRs might have side effects you might not notice at first glance. But then, even with typo fixes I have seen people introducing more fixes or unintentionally thought they would fix

Re: Using of Travis

+1 to drop Am Fr., 17. Dez. 2021 um 10:24 Uhr schrieb Romain Manni-Bucau : > > +1 to drop > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Blog > | Github

Re: Maven Resolver + Wagon

Hi Tamas, this is great news! I agree with you that most protocols are either file:// (project-relative repositories) or https:// based nowadays. Thanks! Am Mi., 15. Dez. 2021 um 14:44 Uhr schrieb Guillaume Nodet : > > Such a massive performance improvement is really nice ! I don't know the >

Re: Maven Code Style and imports layouts

+1! Sandra and I tried similar Suggestions a while back. This will help new contributors a lot. Thanks for your efforts! On Mon, 18 Oct 2021, 07:10 Slawomir Jaranowski, wrote: > Hi, > > In order to help make decisions, I prepared PR [1] with the most used order > layout in Maven Core. > >

Re: [maven-gh-actions-shared] branch main updated: first workflow

+1, we also do this in Apache Shiro [1] and the aspectj-maven-plugin (mojohaus) [2]. We don't reuse workflows yet, but what you have is just great! Thanks! - Ben [1]: https://github.com/apache/shiro/blob/df2f5481260bd778226473a658d237c047b7e840/.github/workflows/maven.yml [2]:

Re: system path dependency warning, accurate or not?

Hi Michael! Setups like "${project.basedir}/m2/" are a common thing. While "system" scope was probably invented to use system (i.e. jdk-related) jar files, but otoh it is the only way to pull in artifacts which are stored next to the project's directory. If you don't think "system" scope should

Re: GitHub Actions on Maven projects

That won't work for all plugins. The jlink plugin and others are using complicated setups so they can use toolchains on GitHub Actions. It's a little bit complicated there because the plugin does work with java 8 as long as a java 9+ is configured via toolchains. Please make sure those actions

Re: Commandline inheritance

Yup, that's what I meant. Big +1! On Tue, 10 Aug 2021, 22:18 Tamás Cservenák, wrote: > A git like behavior sound good for me as well. > > So install/system-wise < user < project > > T > > > On Tue, Aug 10, 2021, 08:22 Benjamin Marwell wrote: > > > I read

Re: Commandline inheritance

there should be a list of other comparable tools with their order > > > Robert > > > [1] https://git-scm.com/docs/git-config#FILES > On 9-8-2021 15:09:30, Benjamin Marwell wrote: > Hi Robert, > > I would like to propose another solution. > According to the wiki pa

Re: Commandline inheritance

Hi Robert, I would like to propose another solution. According to the wiki page and to the documentation, we have user < installation (aka global) < project. where "<" means "is overridden by". >From what I understand from other build systems, a more common approach would >be installation

Re: JPMS, Maven and test jars

> So now you would have a maven module with only the main source and no tests, > and a second module > where the “main” source is actually the test classes > and the unit tests test the code in a different Maven > module with a module info that opens the module-info of the main source jar. >

Re: [VOTE] Import mvndaemon/mvnd project @ Apache

+1 (nb) On Wed, 16 Jun 2021, 08:50 Olivier Lamy, wrote: > Hi > As already proposed by Guillaume, it looks to be a good idea to > import mvndaemon/mvnd here at Apache. > > I'd like to propose a vote for this. > +1: import the project here > 0 : no real idea > -1 : no (please explain why) > >

Re: Supporting building with incompatible JDK versions on a single project

Tamás Cservenák, wrote: > Or xstream for that matter... > > ToP > > On Tue, Jun 15, 2021, 20:26 Tamás Cservenák wrote: > > > Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what > it > > needs to be opened up. > > > > T on phone > &g

Re: Supporting building with incompatible JDK versions on a single project

Tamás, which module do you open? In most cases I have encountered, adding jaxb as a dependency to the project is sufficient. But to be sure, we would need to see an example. I think this would have long been noticed if it was a common problem. Ben On Tue, 15 Jun 2021, 19:18 Tamás Cservenák,

Re: Build windows-jdk11

ged INFRA-21690 to blocker, but still no response. > > Robert > On 7-6-2021 15:32:29, Benjamin Marwell wrote: > I also opened > > https://issues.apache.org/jira/browse/INFRA-21954 > > #asfinfra on slack > > On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > > &g

Re: Build windows-jdk11

I also opened https://issues.apache.org/jira/browse/INFRA-21954 #asfinfra on slack On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: > > Build windows-jdk11 has been broken for a week+ now. Anyone want to > > take a look? I couldn't find

Re: Moving away from Modello

> - For some time, JAXB has been bundled with the JRE. > As of this writing, this still applies to Java 8. >In Java 9, and 10, there's --add-modules=java.xml.bind. > As of Java 11, it has been removed from the JDK. > I'd consider that to be a migration problem. You can just include

Re: Security/Versioning policy proposal

t keeps pushing this topic. > I noticed that it frustrates some and that it they loose their motivation > to work on Maven. > Please reconsider if it is still worth the discussion or that you can > solve it for yourself. > > thanks, > Robert > On 19-4-2021 20:05:53, Romain Manni

Re: Security/Versioning policy proposal

> Do we write 3.6 and 4 are active and maintained branches currently or do we > drop 3.x with first 4.x release? Dropping 3.x with the first 4.x release would not make sense from the point you presented earlier. I'd drop 3.x as soon as we reach 4.1.0. > maintenance branches on demands My vote

Re: [MJLINK] Create JavaFX application runtime

Glad it helped! I was thinking maybe this should be filed as an issue at the javafx mailing list. On Thu, 1 Apr 2021, 22:59 Abhinay, wrote: > Hi Robert, > > The issue can be reproduced using theJavaFX application hosted on Github >

Re: [MJLINK] Create JavaFX application runtime

Also had troubles, but in the end I got it working. You can use my simple GUI app for ROM manipulation as a template if you like. https://github.com/alttpj/MemeforceHunt It's a bit complicated as multiple OSes need to be supported. HTH Ben On Thu, 1 Apr 2021, 08:16 Abhinay Agarwal, wrote: >

Re: Why no mvn daemon?

ep posting your factual returns on experience: that's definitely > > useful > > > > Regards, > > > > Hervé > > > > [1] https://github.com/mvndaemon/mvnd > > > > Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit : > > > Le mar. 30

Re: Why no mvn daemon?

The class cache is also available since Java 8 in the OpenJ9 VM, which also has faster startup times in most cases (for me). Not sure if the scc is portable when using different Java language levels, though. But you can give it a try: https://www.eclipse.org/openj9/docs/shrc/ Other than that, I

Re: Core IT failures with AdoptOpenJDK 11 OpenJ9, but not with HotSpot

Hi Falko, I regularly work with OpenJ9 and encountered such issues. Sometimes it is a coding error which does not lead to an error in Hotspot, sometimes it is a J9 problem (e.g. JIT problems, class loading, etc.). If you want to dig in, there are a few things you can try: The JVM option

Re: JDeprscan plugin 3.0.0 ?

e was even added to the issue tracker at some point. > > Cheers, > Andres > > On Wed, Feb 24, 2021 at 12:08 PM Benjamin Marwell > wrote: > > > Sounds interesting! Is anyone using this yet? > > > > Seems to be a reasonable default plugin for builds, additional

Re: JDeprscan plugin 3.0.0 ?

Sounds interesting! Is anyone using this yet? Seems to be a reasonable default plugin for builds, additional to -Dmaven.compiler.showDeprecation=true Probably another (maybe even more useful) goal would be to scan compile- and runtime dependencies as well. Am Di., 23. Feb. 2021 um 20:40 Uhr

Re: Maven compiler plugin Unsupported major.minor version

the > second doesn't, in my multi-module project with a parent module plus 8 > child modules it fails on the second module with 'mvn clean compile' from > the parent. > > I hope it helps. > Andrea > > Il giorno mar 9 feb 2021 alle ore 21:46 Benjamin Marwell < > bmarw...@apache

  1   2   >