[GitHub] [maven-shared-incremental] olamy closed pull request #18: store last compilation time
olamy closed pull request #18: store last compilation time URL: https://github.com/apache/maven-shared-incremental/pull/18 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: maven.config / jvm.config / -D options
I believe the -D option noted was one that was not related to maven itself but rather jvm. We use -D there for very specific maven item only and its fine. The new lines are required for sure both in 3.9.0 and 4.0.0 alphas. We have already scaled this out as an automated change where I work to address the maven.config at some time maven bumps up via maven wrapper settings. To be more specific, we are using -Daether.checksums.algorithms=SHA512,SHA-256,SHA-1,MD5 in the maven.config as only -D in our case. I have many OSS projects too that have that same setup. Sure that also works moving it into jvm.config but its very maven specific so it makes more sense in maven.config IMHO. -Original Message- From: Christoph Läubrich Sent: Thursday, February 9, 2023 9:39 AM To: dev@maven.apache.org Subject: maven.config / jvm.config / -D options I have a question on this statement below that -D has not to go into maven.config but in jvm config. I think the difference is more that -D in jvm.config become a "real" system-property (because it is evaluated before maven jvm start up), but -D options specified in maven.config actually become user-propertties AND "soft" systemproperties (as they are set after the JVM has started) see the following code: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven%2Fblob%2Fmaster%2Fmaven-embedder%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fmaven%2Fcli%2FMavenCli.java%23L1465-L1492=05%7C01%7C%7C0e31227901824ea3f55008db0aab6565%7C84df9e7fe9f640afb435%7C1%7C0%7C638115503525180590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pqVdZ%2BxaeNpj83ER5ri%2FFpVKKN8MRvYaUd8C%2BgtdQaA%3D=0 So -D is a valid JVM option AND a valid mvn commandline option (named SET_USER_PROPERTY == -D) Also https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fref%2F3.9.0%2Fmaven-embedder%2Fcli.html=05%7C01%7C%7C0e31227901824ea3f55008db0aab6565%7C84df9e7fe9f640afb435%7C1%7C0%7C638115503525180590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=h8qBkhxbZXPCpYmmyfsKLnTpbGc0qxEgsI5IHDulW0w%3D=0 mention -D as a cli option! Also prior to 3.9.x the contents of the file was split by *any* space see: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven%2Fblob%2Fmaven-3.8.x%2Fmaven-embedder%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fmaven%2Fcli%2FMavenCli.java%23L380-L399=05%7C01%7C%7C0e31227901824ea3f55008db0aab6565%7C84df9e7fe9f640afb435%7C1%7C0%7C638115503525180590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=roUc9kOUHcO8R2%2FoYpCGkfy6WLTP5T3bE2s4c2T0b5Q%3D=0 Also reading this I can't find a indication that new lines are required: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fconfigure.html=05%7C01%7C%7C0e31227901824ea3f55008db0aab6565%7C84df9e7fe9f640afb435%7C1%7C0%7C638115503525180590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FC4oKQzRScoPPlk4rWIqAfI577SEZ9jrSLaqxRdRMgA%3D=0 Am 31.01.23 um 16:00 schrieb Michael Osipov: > Am 2023-01-31 um 01:35 schrieb Dan Tran: >> run into this issue >> >> "Unable to parse maven.config file options: Unrecognized maven.config >> file >> entries: [ -e --fail-fast -Djavax.xml.accessExternalSchema=all >> -Daether.connector.resumeDownloads=false]" >> >> The workaround is to break it into multiple lines > > This is not a workaround. Your input is wrong in two ways: > > 1. Each arg has to be in one line: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbo > x.apache.org%2Frepos%2Fasf%3Fp%3Dmaven.git%3Ba%3Dcommit%3Bh%3D331c5c34 > 35cdfa8dc3f35a7b38503bdac2654206=05%7C01%7C%7C0e31227901824ea3f55 > 008db0aab6565%7C84df9e7fe9f640afb435%7C1%7C0%7C63811550352 > 5180590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GVnU8ToabKngYqsv3Rm > T5On4r7WyglQuT19XlPwdlYk%3D=0 > 2. Java system props must *not* be passed via maven.config, but via > MAVEN_OPTS or jvm.config only, e.g., > -Djavax.xml.accessExternalSchema=all > > M > > > - > 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
maven.config / jvm.config / -D options
I have a question on this statement below that -D has not to go into maven.config but in jvm config. I think the difference is more that -D in jvm.config become a "real" system-property (because it is evaluated before maven jvm start up), but -D options specified in maven.config actually become user-propertties AND "soft" systemproperties (as they are set after the JVM has started) see the following code: https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1465-L1492 So -D is a valid JVM option AND a valid mvn commandline option (named SET_USER_PROPERTY == -D) Also https://maven.apache.org/ref/3.9.0/maven-embedder/cli.html mention -D as a cli option! Also prior to 3.9.x the contents of the file was split by *any* space see: https://github.com/apache/maven/blob/maven-3.8.x/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L380-L399 Also reading this I can't find a indication that new lines are required: https://maven.apache.org/configure.html Am 31.01.23 um 16:00 schrieb Michael Osipov: Am 2023-01-31 um 01:35 schrieb Dan Tran: run into this issue "Unable to parse maven.config file options: Unrecognized maven.config file entries: [ -e --fail-fast -Djavax.xml.accessExternalSchema=all -Daether.connector.resumeDownloads=false]" The workaround is to break it into multiple lines This is not a workaround. Your input is wrong in two ways: 1. Each arg has to be in one line: https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=331c5c3435cdfa8dc3f35a7b38503bdac2654206 2. Java system props must *not* be passed via maven.config, but via MAVEN_OPTS or jvm.config only, e.g., -Djavax.xml.accessExternalSchema=all M - 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
Re: Maven 3.9.0 plexus-utils issue in extension
Correction: It's also way too early to drop support for Maven <=3.9. "for Maven < 3.9". Also sorry for the formatting mess, I copied the error directly from the console. Cheers, Falko - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3.9.0 plexus-utils issue in extension
Hi all, I'm currently trying to get gitflow-incremental-builder (GIB) running in a GitHub Action using Maven 3.9.0 (and Java 17). https://github.com/gitflow-incremental-builder/gitflow-incremental-builder GIB is a maven extension that shall be usable in the following "flavors": 1. as a plugin with true 2. or as via extensions in pom.xml 3. or as a "core" extension via extension.xml which are all working fine with Maven 3.6.3 and 3.8.7. With 3.9.0 I was initially seeing the following weird exception in 2 of 3 integration tests: 1) [Guice/NullInjectedIntoNonNullable]: null returned by binding at LocatorWiring but UnchangedProjectsRemover.downstreamCalculator(UnchangedProjectsRemover.java:43) is not @Nullable at LocatorWiring at UnchangedProjectsRemover.downstreamCalculator(UnchangedProjectsRemover.java:43) \_ for field downstreamCalculator The two failing tests are the ones for flavor 1 and 2, meaning that the core extension case did not fail! To add even more confusion: I don't see any issues locally on two different Ubuntu 22.04 systems (one natively and one via WSL2). Anyway, after trying a few other things without luck, I tried adding an explicit dependency to plexus-utils which does fix this general issue! But that brings back another issue I already had before 3.9.0 in a specific use case / code path _and only for the third flavor_ (core extension): java.lang.ClassCastException: class org.codehaus.plexus.util.xml.Xpp3Dom cannot be cast to class org.codehaus.plexus.util.xml.Xpp3Dom Now, with 3.9.0 I can fix this issue by setting the new property in the integration test extension.xml: plugin But users cannot do that in 3.8.7. Long story short, I don't see how I can cover both 3.8.7 _and_ 3.9.0 for all cases: - If I don't add plexus-utils, I break flavors 1 & 2 with Maven 3.9. I could try to document that users shall add plexus-utils on their own, but that's only possible for the plugin case (flavor 1). - If I add plexus-utils, I break flavor 3 with Maven <=3.8.7 because users cannot set classLoadingStrategy yet and there is also no way to exclude plexus-utils via extension.xml. Am I missing an option? I really don't want to publish two different variants of GIB (one with and one without plexus-utils dependency). It's also way too early to drop support for Maven <=3.9. References: - initial PR: https://github.com/gitflow-incremental-builder/gitflow-incremental-builder/pull/644 - troubleshooting PR: https://github.com/gitflow-incremental-builder/gitflow-incremental-builder/pull/645 Thanks & cheers, Falko
Re: Bug report - maven shade plugin - transitive dependencies of provided dependency included in uber-jar
Hello, I took a quick look at the reproducing project you linked (https://github.com/cerveada/shade-plugin-issue) and I think the reason for the behavior you are seeing is the content of section in the bundle/pom.xml: org.apache.spark spark-core_2.12 2.4.8 provided org.apache.spark spark-parent_2.12 2.4.8 pom import You are specifying a provided scope for spark-core_2.12, and at the same time changing the scope for some of its transitive dependencies when importing the dependencyManagement from the spark-parent_2.12 POM. You should be able to see the resulting dependency tree (with scopes) by running 'mvn dependency:3.5.0:tree'. If I remove the spark-parent_2.12 from the section, then I am seeing the result you are probably expecting - everything is provided and the shaded jar is basically empty. I believe this is the current expected behavior when it comes to scopes/dependencyManagement in Maven. You would probably need to override the scope for all of the transitive dependencies as well, or remove the spark-parent_2.12 import. Thanks, Petr --- Original Message --- On Wednesday, February 8th, 2023 at 14:13, Adam Cervenka (ZA) wrote: > > > Hello, > > I would like to report a bug. > > I declared a dependency as provided, but the shade plugin still includes its > transitive dependencies in the uber-jar. > > To demonstrate the issue, I created following repository: > https://github.com/cerveada/shade-plugin-issue > > Using the poms and instructions in the repo it should be easy to replicate > the issue. > > Thanks, > Adam Cervenka > > Absa Bank Limited is a subsidiary of Absa Group Limited and is an Authorised > Financial Services Provider and Registered Credit Provider, registration > number: NCRCP7. > > Absa Bank Limited provides services to Absa Group Limited and its > subsidiaries. > > Absa is committed to complying with applicable data privacy laws and to > safeguarding the privacy and security of the personal information it collects > and processes, in respect of all current and prospective clients. To > understand more about how we collect, store, and process your personal > information, please view our privacy statement at absa.co.za > > This e-mail and any attachments are confidential and intended solely for the > addressee and may also be privileged or exempt from disclosure under > applicable law. If you are not the addressee, or have received this e-mail in > error, please notify the sender immediately, delete it from your system and > do not copy, disclose or otherwise act upon any part of this e-mail or its > attachments. Internet communications are not guaranteed to be secure or > virus-free. We do not accept responsibility for any loss arising from > unauthorised access to, or interference with, any Internet communications by > any third party, or from the transmission of any viruses. We may monitor > replies to this e-mail for operational or business reasons. Any opinion or > other information in this e-mail or its attachments that does not relate to > our business is personal to the sender and we do not endorse it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Deploy Plugin 3.1.0 released
The Apache Maven team is pleased to announce the release of the Maven Deploy Plugin 3.1.0! https://maven.apache.org/plugins/maven-deploy-plugin/ You should specify the version in your project's POM: org.apache.maven.plugins maven-deploy-plugin 3.1.0 Release Notes - Maven Deploy Plugin - Version 3.1.0 ** Bug * [MDEPLOY-200] - deployAtEnd fails if the last project to build skip deployment * [MDEPLOY-204] - Must deploy maven-metadata.xml last * [MDEPLOY-224] - Overriding deployAtEnd fails * [MDEPLOY-225] - DeployAtEnd fails when overriding skip * [MDEPLOY-226] - DeployAtEnd fails when module has extension * [MDEPLOY-305] - Improvement in DeployAtEnd ** New Feature * [MDEPLOY-206] - Support parallel deployment at end (needs resolver changes as well) * [MDEPLOY-272] - Add skip capability to deploy-file goal ** Task * [MDEPLOY-282] - Revert MDEPLOY-231 * [MDEPLOY-292] - Require Java 8 * [MDEPLOY-303] - Refresh download page * [MDEPLOY-304] - Clean up ITs Have fun, -The Apache Maven team
