Re: Hmm ...
Hi, which Maven versions do you use? Which JDK versions do you use? Which plugin versions do you use in your builds? etc. There are missing so much information so I can not even guess what might be a point? Do you have tests running? How much? Have you measured the plain build time? With or without the tests etc. ? BTW: Which projects do you build ? Do you have example projects? Kind regards Karl Heinz Marbaise On 28.05.24 15:35, Tommy Svensson wrote: Performance problems When I bought my Apple MacBook Pro M1 machine with 10 cores (real, not threaded) and 64 GB memory, I was able to build one of my multimodule projects in around 4 seconds! The project had 4 modules at the time. I now build on Samsun external disk and it takes 29 seconds to build with 2 of the modules removed! So I first thought that it must be a difference in speed between external SSD and internal. "BlackMagic Disk Test" on Mac showed internal disk to be extremely must faster than external. Samsung: 791 apple internal: 4431. So I moved the code back to apples internal disk. That did however not make a difference!!! But I have earlier build same project with twice the amount of code in it at around 4 seconds on internal disk! The speed test shows it is still as fast as it was before. This makes me wonder if something has happened in maven that makes builds slower ? It is clearly not the disk speed that affects time it takes, so I can only assume Maven or Groovy! The latter is more complicated to verify, so I started with maven! This is not an accusation of any kind! Just wan't to se if I'm pretty much alone with this problem or not. Best Regards, Tommy Svensson to...@natusoft.se - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 28.02.24 08:30, Benjamin Marwell wrote: 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 vote with fractions and negative votes are not vetoes. Please also notice: * Maven 3 will stay at Java 8 no matter what. * We may raise Maven 4 to JDK 21 later if we feel like it (depending on the release date). This is not part of this vote. * The linked PR is not part of this vote (this is not a code vote). But you may take a look at it to understand the intended change. PR: https://github.com/apache/maven/pull/1430 Maven-Parent will not be raised with this vote, the other PR is not part of this vote. Please refrain from starting discussions in this thread, but do include a reasoning on downvotes and feel free to start a new discussion on the mailing list, or comment on the existing ones. --- Vote open for 72 hours: [ ] +1 (set JDK17 min version for Maven 4.x) [ ] +0 [ ] -1 (please include reasoning) --- - Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 4.0 release timeline
Hi, first try to build your whole project on plain command lineand see if there are issuesafter that you can try your IDE .. because IntelliJ has an integrated version and also the support is not really ready to use... Kind regards Karl Heinz Marbaise On 18.12.23 23:19, Tamás Cservenák wrote: Well, IDE integrations are completely different stuff... What IDE do you use? Can I recommend you to try it out in Terminal instead? T On Mon, Dec 18, 2023 at 11:18 PM wrote: Thanks! Just tried in my IDE and it failed, but not sure if that's an issue with maven or with IDE. (I have a multi-module project and it tried to download the submodules instead of using the local source code) -Original Message- From: Tamás Cservenák Sent: Monday, December 18, 2023 5:08 PM To: Maven Users List Cc: subharaj.ma...@gmail.com Subject: Re: Maven 4.0 release timeline CAUTION: This email originated from outside our organisation - ta...@cservenak.net Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Howdy, And to reply to the "longer stuff": Current Maven 4 (on vote, so 3 days if vote passes OK and files land on Central) is alpha-10. As with any previous alphas, the _minimal_ requirement is that UT passes, Maven can build itself, and that to pass Maven IT suite. IT suite is currently, in this very moment 909 IT tests, but they grow constantly, as new bugs or new features are added, this link https://clicktime.symantec.com/15sM1Hx4Zk69FcT4Re31T?h=WCNYF5iZoo32qX5Hxyc8Qrzhc1t-HKpREAcWNL1r7t8==https://github.com/apache/maven-integration-testing/pulse/monthly shows there were 3 ITs added last, two bugs from alpha-9 and new feature regarding plugin validation. As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled: https://clicktime.symantec.com/15sMAxLdUyTL5W6uWkqJh?h=KbxkwIqLoMQYfHx5OCZ4V-Mu7NdrW7MXjqNgyyl25so==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MNG%2520AND%2520fixVersion%2520%253D%25204.0.0-alpha-11 Currently we work on stabilizing resolver and maven (both are alphas!), and ironing out the new Maven 4 API (thus converting MANY core plugins to use new API), see here: https://clicktime.symantec.com/15sM689M2MmjfZGyyCSA5?h=7_-nR2qTzP6RIZLBqH9pHMeQfYQjGw5njIatpLSW6_U==https://github.com/apache/maven/pull/1048 Basically we make sure that the new API delivers _everything_ we need in core plugins, and even more, as some information trickles from third party plugins as well. We have to do this "intelligence" work in alpha, where we can break APIs, as we really need to adjust, adapt and make sure all this once is set in stone (released as final), will work out for everyone doing plugin development. Good news is that Resolver 2.0.0 is pretty much "done": https://clicktime.symantec.com/15sMFnXuwb8vVSvq4KETK?h=djE-5RAYZwC_J0iiRHe3cw4LXST_S1deoAEfdJrJlfU==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MRESOLVER%2520AND%2520fixVersion%2520%253D%25202.0.0-alpha-6 I am not saying "resolver is done-done", just that we are "over the hill", as regarding issue numbers over there. Most probably will have some lurking bugs, like the last one was in Resolver 2 alpha-3 (plagues Maven 4 alpha-9) about new "jdk" transport. And for sure will have bugs regarding new transport features, as they are not ironed out fully. Maven core is completely different, especially due to its API. Hence, the more (intel) we get the merrier, as we see "core plugins" only. So please try out, test it and report back. Thanks T On Mon, Dec 18, 2023 at 9:39 PM wrote: I'm not the original asker but this kind of answer tends to annoy me. Yes, there is no "official" release timeline, you're obviously not going to promise anything, all this is (hopefully?) clear, BUT! You no doubt have GUESSES. And your guesses are no doubt better than that of most uninformed outsiders. As an outsider, I have no idea what the "status" of maven 4 is, and I can't even begin to guess how I would find out. Should I try to catch up on the last few years of traffic on the developer email lists? Or perhaps the answer can be divined from the issue tracker? If so, how? Is it expected that alpha-10 will be the last alpha, and the next build will be a beta? If that is NOT what you expect, then what's the primary hold up? Are there major features that have yet to be implemented? Or perhaps the features are mostly done but they're still a bit buggy? Or perhaps the code quality is pretty solid and you just want to reserve the right to make backwards incompatible changes, and there's a policy to not do that after hitting beta? You get the idea. As an insider, you probably think to yourself "there's no telling when we'll be done; it depends on a zillion unpredictable things". But as outsiders, we don't even know whether the ETA is a few
Re: maven-checkstyle-plugin using project dependencies?
On 15.12.23 18:01, David Hoffer wrote:
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
com.puppycrawl.tools
checkstyle
10.12.3
com.bs.arm.a2dl
a2dl-build-tools
${project.version}
a2dl/google_checks.xml
true
true
false
verify-checkstyle
verify
check
The problem is the plugin is looking in my .m2 folder or Maven proxy server
for this dependency.
com.bs.arm.a2dl
a2dl-build-tools
${project.version}
But it doesn't exist there yet as its a module of my/this project so its
one of the modules in the Maven build reactor. Is it possible to configure
the plugin to use the project modules for this?
-Dave
I would suggest to check the documentation:
https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 4.0 release timeline
On 18.12.23 06:27, Debraj Manna wrote: Can someone let me know when Maven 4 is expected to be released? Where can I view its release timelines? We are an open source project. We don't have a release timeline. Maven 4.0.0 will be there when it's there. If you want to help testing, there is 4.0.0-alpha-9 version available (at the moment the VOTE for 4.0.0-alpha-10 is running developers list).. https://maven.apache.org/download.cgi https://maven.apache.org/docs/history.html https://maven.apache.org/mailing-lists.html Kind regards Karl Heinz Marbaise Apache Maven PMC Chairman - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Inclusion of Failsafe plugin by default
On 09.12.23 23:28, Damiano Albani wrote: Hello, I'm a long-time Maven user but I've just recently discovered that, unless I'm mistaken, the Failsafe plugin isn't part of the default set of plugins which are configured "out of the box". Is this correct? If so, I find this quite strange given that Failsafe is mentioned on https://maven.apache.org/plugins/index.html as a "core plugin", just like its sibling Surefire, the latter being indeed included. In order to change that, would it simply be a matter of adding Failsafe to https://github.com/apache/maven/blob/maven-3.9.6/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml ? Or are there locations in the Maven codebase that would need to be changed? First your assumption is correct it's not part of the default life cycle[1] which means it is not bound by default. If you like to use it you have to make the binding yourself. Maven Failsafe Plugin is intended for running integration tests based on the naming schema "*IT.java" (etc.) So why isn't it added by default? The answer is more or less simple. Because it's not always needed nor used. I can give you some statistical information based on the downloads via central. The maven-surefire-plugin (over all versions) is downloaded ca. 30 million times a month. The maven-failsafe-plugin (over all versions) is downloaded ca. 5 million times a month[2]. In other words the majority of the cases people running unit tests but not integration tests... (ca. 1/6).. Another question would arise if you like to make it part of the default life cycle: Should both goals "integration-test" bound to the lifecycle as well as "verify" or just one of them? Another thing is very often people create a profile to activate the integration tests whenever they like based on the time consumption of integration tests. That's simply because integration tests are running a way longer than unit test. Something like "mvn verify -Prun-its" (which by the way the maven teams does as well for all the plugins). Another question arises: Is this enough because running integration test could require other things? For example starting a thing like tomcat/jetty etc. or docker containers and even many other things? Or would it be better to control that via the integration test itself (via testcontainers or alike) etc. Kind regards Karl Heinz Marbaise Apache Maven PMC [1]: https://maven.apache.org/ref/3.9.6/maven-core/default-bindings.html [2]: https://blog.soebes.io/posts/2023/08/2023-08-06-download-statistics-for-maven/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Self-inflicted wounds again.
Hi, The first what I see is that you are using an ancient old maven-assembly-plugin version (2.2-beta-5) ... Please upgrade first (most recent is currentl 3.6.0).. Here you find the overview of all plugins with the most recent versions: https://maven.apache.org/plugins/ Kind regards Karl Heinz Marbaise On 13.11.23 20:27, Joseph Kessselman wrote: Had generation of the multi-module distribution binary zipfile working yesterday. Came back today to find I had apparently stepped on it before pushing. Sigh. OK, I should be able to reproduce this, right? Unfortunately, no. I'm missing something obvious again. In context, currently broken as checked in: https://github.com/apache/xalan-java/tree/xalan-java-mvn-refactored Current error message is [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single (distro-assembly) on project distribution: Error reading assemblies: Error reading descriptor at: src/assembly/bin.xml: Unrecognised tag: 'useAllReactorProjects' (position: START_TAG seen ...\n ... @15:30) -> [Help 1] The bin.xml file mentioned currently contains something that is based directly off the multi-module assembly instructions, just changing which modules are included. Or at least that's the intent. http://maven.apache.org/ASSEMBLY/2.2.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0 http://maven.apache.org/xsd/assembly-2.2.0.xsd;> bin zip tar-gz false true xalan:serializer xalan:xalan xalan:samples modules/maven-assembly-plugin false ../target/site docs ../samples target/** src/site/** -- And the POM invoking this is likewise based pretty directly on the example: http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd;> 4.0.0 xalan xalan-project 2.7.3 distribution pom distribution xalan serializer 2.7.3 xalan xalan 2.7.3 xalan samples 2.7.3 maven-assembly-plugin distro-assembly package single src/assembly/bin.xml -- I'm undoubtedly looking right past my error. Which foot am I shooting off this time? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: war plugin incompatibility
On 09.11.23 23:46, Rick Hillegas wrote: I am trying to install a Derby release into my local maven repository. The world has changed underneath me in the last year and a half since I published the last Derby release. The Derby maven-based publication poms can be found under https://svn.apache.org/repos/asf/db/derby/code/trunk/maven2/ The Derby publication poms don't do much. They just sign the Derby artifacts and copy them into the repository. No jars or wars are actually built by the publication poms. That happens elsewhere. On my first attempt, I used the maven version I used a year and a half ago: 3.8.6. One of the Derby artifacts is a war file and its associated publication pom contained this plugin stanza: org.apache.maven.plugins maven-war-plugin 2.1.1 Why using such ancient version? https://maven.apache.org/plugins/ Upgrade the plugin versions Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven CI Friendly Versions
Thanks Tamás.. Kind regards Karl Heinz Marbaise On 10.11.23 17:24, Tamás Cservenák wrote: It changed domain https://blog.soebes.io/posts/2017/04/2017-04-02-maven-pom-files-without-a-version-in-it/ HTH T On Fri, Nov 10, 2023 at 5:19 PM Eric B wrote: Many years ago Karl Heinz Marbaise had written a blog about the beginning of Maven 3.5's support of CI versioning numbers with the specific parameters that are interpolated by maven. I always used to refer new developers to that blog that were trying to understand the complexities of using Maven and versioning in a CI environment. It used to be hosted at: http://blog.soebes.de/blog/2017/04/02/maven -pom-files-without-a-version-in-it/ <http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/> But that site is now unfortunately dead (404). I had always found that it was a very good intro to the problem and helped clarify things well, including the need for using the flatten-plugin, etc. Does anyone know if that blog is still available, but posted elsewhere, or alternatively any good sites to help newcomers to the CICD problems with Maven? Clearly, there is the default documentation on Maven itself ( https://maven.apache.org/maven-ci-friendly.html) but is anything additional that I can reference newcomers to? Specifically, I am looking for best-practices for automated Jenkins builds/pipelines/etc when integrated with CI variables. Thanks! Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can the jar plugin respect .gitignore?
On 10.11.23 19:42, Joseph Kessselman wrote: (Or, equivalently be told to take exclude list from a file in .gitignore syntax and then be told .gitignore was that file.) If not, I'd consider that worth adding. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Please make an example or post a link to the appropriate project... because jar plugin and .gitignore does not make sense... also for maven-assembly-plugin it sounds a bit weird to be honest? ... What exactly are you trying to achieve? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-assembly-plugin, bin example is giving me trouble
On 11.11.23 04:54, Alexander Kriegisch wrote: Tried making my top-level module dependent on all the others Don't! That does not make any logical sense. Checked in on xalan-java branch xalan-java-mvn-refactored Please always provide a link. I have no idea where to find your project. To you, that might be obvious. to others, it is not. Don't do that because the parent runs first ... if you need some dependency order define the appropriate dependencies in your modules which automatically orders the build reactor accordingly. If you have other issue please show a real example what exactly the problem is... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to log in surefire which test classes are executed in which surefire thread?
On 30.05.23 07:24, Debraj Manna wrote:
Thanks, Nils for replying.
In JUnit5 it looks like running tests in parallel is still an experimental
feature.
Technically you are correct... but it's already a long time there I
doubt that it will be removed.
> So I was checking if it is possible to do the same via Surefire.
I recommend to use JUnit Jupiter...
Btw: JUnit Jupiter is available in version 5.9.3 and also 5.10.0-M1 is
available as milestone one...
Furthermore the users guide of 5.10.0-M1
(https://junit.org/junit5/docs/5.10.0-M1/user-guide/index.html#writing-tests-parallel-execution)
shows that the WARNING about experimental feature has been removed...
https://junit.org/junit5/docs/current/user-guide/
https://junit.org/junit5/
On Mon, May 29, 2023 at 9:05 PM Nils Breunese wrote:
I don’t have answers for your Surefire questions, but I wanted to mention
that you can also tell JUnit 5.9.2 to execute tests in parallel:
https://junit.org/junit5/docs/5.9.2/user-guide/index.html
Nils.
Op 29 mei 2023 om 16:13 heeft Debraj Manna
het volgende geschreven:
I updated by command like below
mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
But I am observing that all my test classes are being executed in
ThreadStreamConsumer
[ThreadedStreamConsumer] [INFO] Running
com.spotnana.servicetests.profile.ProfileCreatePersonalUserTest
...
[ThreadedStreamConsumer] [INFO] Running
com.spotnana.servicetests.profile.PlanServiceTest
So can someone let me know if this is the correct way of logging the
parallel execution identifier in maven output logs? If yes then what am I
doing wrong which is causing all test classes to execute in a single
thread?
Junit Version - 5.9.2
On Mon, May 29, 2023 at 6:53 PM Debraj Manna
wrote:
I want to execute test classes concurrently in the same JVM. So my
surefire-plugin config looks like below
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
$${surefire.forkNumber}
-Xms512m -Xmx${surefire.max.heap}
-XX:MaxDirectMemorySize=${surefire.max.direct.memory}
-XX:MaxMetaspaceSize=${surefire.metaspace.size}
-XX:+HeapDumpOnOutOfMemoryError @{argLine}
suitesAndClasses
false
${surefire.threadCount}
1
true
Can someone let me know if there is a way for me to know which test
classes are being executed in which surefire thread?
Mit freundlichem Gruß
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Inhaber Dipl.Ing.(FH) Karl Heinz Marbaise USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen https://www.soebes.de
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Artifact Resolver not seeing latest plugins on Maven Central on my machine
Hi, as I wrote on SO... are you in a corporate environment and using a repository manager ? Kind regards Karl Heinz Marbaise On 24.05.23 18:04, Garret Wilson wrote: I'm writing to this list on the advice of Andrzej Jarmoniuk on [Versions Maven Plugin Issue #959](https://github.com/mojohaus/versions/issues/959). I have also opened a [Stack Overflow question](https://stackoverflow.com/q/76307809) with a bounty, but so far there have been no responses. In short Maven Artifact Resolver on my machine seems to be stuck at some previous point in time; it does not see the latest versions on Maven Central when I am requested updated plugin versions using Versions Maven Plugin. It shows that there are newer versions available, but the ones it shows are not the latest available. Before deleting my entire `C:\Users\user\.m2\repository\` directory tree I would prefer to know what is caused this scenario so that it won't happen again in the future. But at the moment I don't even understand what condition (e.g. incorrect timestamps or whatever) is currently causing this behavior. I am using Maven 3.9.1 on Windows 10. I also use Eclipse EE 2023-03, which contains m2e (Eclipse's support for Maven). I start with [this `pom.xml`](https://github.com/globalmentor/globalmentor-root/blob/bce5bdbac7797b5b9114a72e5da2f4d76f3e24a7/pom.xml), which uses `org.codehaus.mojo:versions-maven-plugin:2.12.0`, which in turn (I am told) uses Maven Artifact Resolver. (Note that I've tried the latest `org.codehaus.mojo:versions-maven-plugin:2.15.0` as well, with the same results. I'm using this POM because it's available online and does not contain any version ignores to cause confusion.) I wanted to see what plugins were out of date, so I ran: ```bash mvn versions:display-plugin-updates ``` It shows this: ``` [INFO] The following plugin updates are available: [INFO] maven-failsafe-plugin .. 2.22.2 -> 3.0.0-M7 [INFO] maven-release-plugin 2.5.3 -> 3.0.0-M6 [INFO] maven-site-plugin .. 3.12.1 -> 4.0.0-M3 [INFO] maven-surefire-plugin .. 2.22.2 -> 3.0.0-M7 [INFO] org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.0.5 ``` However in Versions Maven Plugin Issue #959 (see link above), Andrzej Jarmoniuk ran the same command and came up with different answers. Here are two examples: ``` [INFO] org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.1.0 ``` Note that my output is only showing v3.0.5 is available for `org.springframework.boot:spring-boot-maven-plugin`. Furthermore there are later versions available for some of the other plugins as well. ``` [INFO] com.akathist.maven.plugins.launch4j:launch4j-maven-plugin 2.1.3 -> 2.4.1 ``` My output doesn't even show `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`; apparently it thinks thje v2.1.3 listed in the POM is the latest available! It would appear that Maven Artifact Resolver is somehow "stuck" at some earlier point in time on my machine. I ran Maven with the `-X` option, and here is part of the output related to `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`: ``` … [DEBUG] Checking com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates newer than 2.1.3 [DEBUG] Could not find metadata com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml in local (C:\Users\user\.m2\repository) [DEBUG] Skipped remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, locally cached metadata up-to-date [DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].version=2.1.3 [DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].artifactVersion=2.1.2 [DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3 [DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true … ``` This debug information seems to be saying that it can't find `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml`. And in fact that file does not exist! Instead I have `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml`. (I don't know what the differences are.) The more ominous line is this one: > `[DEBUG] Skipped remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, locally cached metadata up-to-date` What might be causing Maven Resolver on my machine to get "stuck" at an earlier point in time, and/or to skip checking Maven Central altogether for newer versions of many plugins? Garret Wilson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Support for Java 9+
Hi, On 20.04.23 17:32, Rodrigo Bourbon wrote: Hi, I'm currently working with Java 11 and my project relies upon the maven-model <https://github.com/apache/maven/tree/master/maven-model> and maven-model-builder <https://github.com/apache/maven/tree/master/maven-model-builder> artifacts. The problem is that both have the package org.apache.maven.model.merge, hence giving a split package issue when compiling with Java 9+. Is there any plan on being compatible with Java 9+ in the short term? What alternatives do you suggest? Thanks in advance, Rodrigo. Why does your project rely on maven-model? Creating a plugin or alike? And what do you mean by Java 9+ compatible... ? Are you talking about Java Module System? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven slow
Hi, That sounds very good.. Tip: Do not use "install" use "verify" instead... Kind regards Karl Heinz Marbaise On 10.04.23 10:50, Tommy Svensson wrote: Hello maven users, I provided an update on this yesterday, but I'm not sure it was sent. My Mac was in a really bad state. The problem is solved, and maven is and was 100% innocent here! :-). There were a new macos update that I missed that solved the general slugishness of my machine. The real culprit here is IntelliJ IDEA! It still takes 43 seconds to build within IDEA. Doing a "mvn clean install" in a terminal takes 7 seconds! A rather extreme diff! This is a multimodule project of about 5 modules. BR, Tommy På 9 april 2023 till 17:00:51, Tommy Svensson (to...@natusoft.se(mailto:to...@natusoft.se)) skrev: Tommy Svensson to...@natusoft.se wrote: I'm running Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) That is what the latest version of IDEA gives me. If you add Maven Wrapper [0] to your project, you can use any version of Maven you like, including the latest 3.9.1 release. Nils. [0] https://maven.apache.org/wrapper/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven slow
Hi, On 06.04.23 17:15, Tommy Svensson wrote: Hello maven users, I have an observation that does not make sense to me: I have a multi module build of about 5 modules. I do an "mvn clean install" and it takes 43 seconds. I then do an "mvn install" and it takes 43 seconds ! The second time everything was already built, so no compilation at all should have been done. So why does it still take 43 seconds ? I can do "mvn install" over and over again and it takes 43 seconds. No diff between "mvn clean install" and "mvn install" when everything is already built. Is the compile so extremely fast that it doesn't even take a second while everything else maven does takes 43 seconds ? 1. What kind of project are you working with? 2. Are you running on plain command line? (not from within your IDE!!!) If not do all the tests from plain command line (Terminal in MacOS): 3. Is this a single module project or a multi module project? 4. Run "mvn clean" separately and afterwards do mvn verify another time do "mvn verify -DskipTests" compare those times? Also very important: Do you use the most recent versions of plugins? Check that against https://maven.apache.org/plugins Check the log output for something like "Nothing to compile - all classes are up to date" (at least from the maven-compiler-plugin) if not you are not using the most recent versions of those plugin... 4. If this is a multi module build you can try to build in parallel: mvn verify -T 3 5. If you identified the tests as the culprit check if those tests are true unit tests... if so try to parallelize them.. depending on which unit testing framework you are using (for example JUnit Jupiter can do that)... 6. tip: "mvn install" is more or less never needed. "install" will deploy the built artifacts into your local cache "$HOME/.m2/repository" It's only necessary if you want to consume your built artifacts from an other maven project... otherwise it's not necessary. Kind regards Karl Heinz Marbaise I have a Mac M1 with 10 cores and 64 GB of memory (and no buss, processor and memory in same chip). The maven speed difference between my machine and the work machine (Intel I5 2 cores and 8GB memory) doesn't really differ that much. That is with maven. For other things there is a big difference. Is there any good explanation for this ? I have used maven for a very long time and this is the first time I have noticed this. New faster machines have always improved build speed before. I'm running Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) That is what the latest version of IDEA gives me. BR, Tommy Svensson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: MalformedInputException: Input length = 1
Hi, On 21.01.23 14:02, Nils Breunese wrote: I’d say it’s pretty common to have binary files under src/main/resources actually. Images, movies, etc. for instance. That's correct but you should never filter them... that's the issue here.. In general two options: Change the configuration for filtering and exclude the binary formats for example: https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html or create two different directories and use the following configuration: src/test/filtered-resources true src/test/resources false src/main/filtered-resources true src/main/resources false That simply means the default directory src/main/resources contains only resources which are not filtered and src/main/filtered-resources will contain resources which will be filtered... Kind regards Karl Heinz Marbaise It’s also pretty common to commit Gradle Wrapper or Maven Wrapper JAR files, but in this case it looks like this Gradle Wrapper JAR is not used for building the codebase itself, but possibly for some other use case. I myself for instance maintain an application based on Spring Initializr, which also has these build tool wrapper JARs in its resources, because it can generate new projects with these files included. I don’t know if the presence of this JAR makes sense in this case, but you indeed might want to exclude it from resource filtering. Nils. Op 20 jan. 2023 om 17:22 heeft Karl Heinz Marbaise het volgende geschreven: Accidentially not included the list... Forwarded Message Subject: Re: MalformedInputException: Input length = 1 Date: Fri, 20 Jan 2023 13:50:52 +0100 From: Karl Heinz Marbaise Reply-To: i...@soebes.de To: Tom Corcoran Hi, On 18.01.23 17:23, Tom Corcoran wrote: Hi, I am working on upgrading my use of the openapi-generator-maven-plugin for Spring Boot 3. My API gets generated and includes the expected pom.xml & gradle elements (I only used the former). Anyway then your plugin is used to copy 62 resourees, maven-resources-plugin:3.3.0 and I get the message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources (default-resources) on project ABC: filtering ...\src\main\resources\v1\gradle\wrapper\gradle-wrapper.jar to ...\target\classes\v1\gradle\wrapper\gradle-wrapper.jar failed with MalformedInputException: Input length = 1 Any ideas are much appreciated!! Why is a JAR file in your src/main/resources directory? (binary file?) does not make sense nor can you filter a binary file correctly... That is the reason. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: MalformedInputException: Input length = 1
Accidentially not included the list... Forwarded Message Subject: Re: MalformedInputException: Input length = 1 Date: Fri, 20 Jan 2023 13:50:52 +0100 From: Karl Heinz Marbaise Reply-To: i...@soebes.de To: Tom Corcoran Hi, On 18.01.23 17:23, Tom Corcoran wrote: Hi, I am working on upgrading my use of the openapi-generator-maven-plugin for Spring Boot 3. My API gets generated and includes the expected pom.xml & gradle elements (I only used the former). Anyway then your plugin is used to copy 62 resourees, maven-resources-plugin:3.3.0 and I get the message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources (default-resources) on project ABC: filtering ...\src\main\resources\v1\gradle\wrapper\gradle-wrapper.jar to ...\target\classes\v1\gradle\wrapper\gradle-wrapper.jar failed with MalformedInputException: Input length = 1 Any ideas are much appreciated!! Why is a JAR file in your src/main/resources directory? (binary file?) does not make sense nor can you filter a binary file correctly... That is the reason. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to issue to maven
Hi, On 21.11.22 12:34, 孙杰成 wrote: Dear, Hello, I saw the email subscription list on the official website, but I didn't quite understand it. I met a maven problem, and I want to ask maven how to handle the issue? Please help me This is first a good location to ask for issues. The first step is to describe your problem and what you think is the correct way... Best would be having an example project so see what actually is done and how. Also add which Maven version, JDK version and how you call Maven. Kind regards Karl Heinz Marbaise maven user - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Deploy fails
Hi, On 11.11.22 08:40, e...@zusammenkunft.net wrote: Hello, I think the /usr/bin/mvn (i.e. "not in path") and /usr/share/maven/ points to a non-pristine distribution shipped Maven (Debian?). The distro we are talking about is Ubuntu.. I would start with using an upstream Maven distribution archive to make sure its no packaging error. )And also use a supported JDK by fixin PATH and JAVA_HOME. If its a packaging problem the Distribution would be the right place to get support. It does not look like that... (But we already mentioned a few ttimes as a developer you might want to have multiple pristine maven installs independent of your distribution anyway). Gruss Bernd Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Deploy fails
Hi, an add-on to that topic: I've analyzed more or the less the same on SO a number of times. https://stackoverflow.com/questions/67481742/cant-run-maven-3-6-3-on-jdk7/67482132#67482132 Here it's related to JDK7 but the cause is the same. Kind regards Karl Heinz Marbaise On 11.11.22 08:26, Karl Heinz Marbaise wrote: Hi, which puzzles me is that you don't have an entry either for /opt/.. or /usr/share/maven/bin in your PATH variable...(checked in the env.lst).. Are you using the same user for calling Maven in both cases? Because the following does not show any user: >>>>> mvn install:install-file -Durl=file://repo >>>>> -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar >>>>> -DgroupId=lib >>>>> -DartifactId=bind -Dpackaging=jar -Dversion=1.0 while: >>> raivo@Hydra:~/teamengine$ mvn -version >>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) in contradiction does. Please test to add /opt/apache-maven-3.6.3/bin to your PATH or use the absolute path explicitly (/opt/apache-maven-3.6.3/bin/mvn ...) and retry to call the install-file goal. The part you have sent me: /usr/share/maven/lib/guice.jar shows that this is the installed version of Maven via Ubuntu. Please check the hash shasum -a 256 /usr/share/maven/lib/guice.jar and compare that output with shasum -a 256 /opt/apache-maven-3.6.3/lib/guice-4.2.1-no_aop.jar I bet they are different. Kind regards Karl Heinz Marbaise On 10.11.22 21:22, Raivo Rebane wrote: Hi I send You all wanted Raivo On 10.11.22 21:36, Karl Heinz Marbaise wrote: Hi, so there is a difference between the output you have posted: > Maven home: /opt/apache-maven-3.6.3 and the output in the error: >>> (file:/usr/share/maven/lib/guice.jar) to method Can you make a "ls -al /opt/apache-maven-3.6.3/lib" and "ls -la /usr/share/maven/lib/"... Also can you check if you have set an environment variable which starts with "M" (something like M2_HOME?? or alike? Kind regards Karl Heinz Marbaise On 10.11.22 20:21, Raivo Rebane wrote: Hi To me seems it is Apache Maven. raivo@Hydra:~/teamengine$ mvn -version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /opt/apache-maven-3.6.3 Java version: 11.0.16, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-52-generic", arch: "amd64", family: "unix" Am I right ? Regards Raivo On 10.11.22 20:23, Karl Heinz Marbaise wrote: Hi, On 10.11.22 15:58, Raivo Rebane wrote: Hello My Maven deploy fails : mvn install:install-file -Durl=file://repo -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar -DgroupId=lib -DartifactId=bind -Dpackaging=jar -Dversion=1.0 and gives error : WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This output looks strange, because the output of the file "guice.jar" is an indication that you are not using Apache Maven. It looks like you are using a repackaged variant of Apache Maven... which causes issues. First I would suggest to show what: "mvn --version" prints out... and can you please post that here? Tests [pom] [WARNING] Error injecting: org.apache.maven.wagon.providers.http.HttpWagon$__sisu20 java.lang.ExceptionInInitializerError at javax.crypto.Cipher.getInstance (Cipher.java:540) at sun.security.ssl.JsseJce.getCipher (JsseJce.java:190) at sun.security.ssl.SSLCipher.isTransformationAvailable (SSLCipher.java:509) at sun.security.ssl.SSLCipher. (SSLCipher.java:498) at sun.security.ssl.SSLCipher. (SSLCipher.java:81) at sun.security.ssl.CipherSuite. (CipherSuite.java:65) at sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuites (SSLContextImpl.java:348) at sun.security.ssl.SSLContextImpl$AbstractTLSContext. (SSLContextImpl.java:580) at java.lang.Class.forName0 (Native Method) at java.lang.Class.forName (Class.java:315) What I do wrong ? And what is the true way of deply ? This looks also very strange... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Deploy fails
Hi, which puzzles me is that you don't have an entry either for /opt/.. or /usr/share/maven/bin in your PATH variable...(checked in the env.lst).. Are you using the same user for calling Maven in both cases? Because the following does not show any user: >>>>> mvn install:install-file -Durl=file://repo >>>>> -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar >>>>> -DgroupId=lib >>>>> -DartifactId=bind -Dpackaging=jar -Dversion=1.0 while: >>> raivo@Hydra:~/teamengine$ mvn -version >>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) in contradiction does. Please test to add /opt/apache-maven-3.6.3/bin to your PATH or use the absolute path explicitly (/opt/apache-maven-3.6.3/bin/mvn ...) and retry to call the install-file goal. The part you have sent me: /usr/share/maven/lib/guice.jar shows that this is the installed version of Maven via Ubuntu. Please check the hash shasum -a 256 /usr/share/maven/lib/guice.jar and compare that output with shasum -a 256 /opt/apache-maven-3.6.3/lib/guice-4.2.1-no_aop.jar I bet they are different. Kind regards Karl Heinz Marbaise On 10.11.22 21:22, Raivo Rebane wrote: Hi I send You all wanted Raivo On 10.11.22 21:36, Karl Heinz Marbaise wrote: Hi, so there is a difference between the output you have posted: > Maven home: /opt/apache-maven-3.6.3 and the output in the error: >>> (file:/usr/share/maven/lib/guice.jar) to method Can you make a "ls -al /opt/apache-maven-3.6.3/lib" and "ls -la /usr/share/maven/lib/"... Also can you check if you have set an environment variable which starts with "M" (something like M2_HOME?? or alike? Kind regards Karl Heinz Marbaise On 10.11.22 20:21, Raivo Rebane wrote: Hi To me seems it is Apache Maven. raivo@Hydra:~/teamengine$ mvn -version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /opt/apache-maven-3.6.3 Java version: 11.0.16, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-52-generic", arch: "amd64", family: "unix" Am I right ? Regards Raivo On 10.11.22 20:23, Karl Heinz Marbaise wrote: Hi, On 10.11.22 15:58, Raivo Rebane wrote: Hello My Maven deploy fails : mvn install:install-file -Durl=file://repo -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar -DgroupId=lib -DartifactId=bind -Dpackaging=jar -Dversion=1.0 and gives error : WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This output looks strange, because the output of the file "guice.jar" is an indication that you are not using Apache Maven. It looks like you are using a repackaged variant of Apache Maven... which causes issues. First I would suggest to show what: "mvn --version" prints out... and can you please post that here? Tests [pom] [WARNING] Error injecting: org.apache.maven.wagon.providers.http.HttpWagon$__sisu20 java.lang.ExceptionInInitializerError at javax.crypto.Cipher.getInstance (Cipher.java:540) at sun.security.ssl.JsseJce.getCipher (JsseJce.java:190) at sun.security.ssl.SSLCipher.isTransformationAvailable (SSLCipher.java:509) at sun.security.ssl.SSLCipher. (SSLCipher.java:498) at sun.security.ssl.SSLCipher. (SSLCipher.java:81) at sun.security.ssl.CipherSuite. (CipherSuite.java:65) at sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuites (SSLContextImpl.java:348) at sun.security.ssl.SSLContextImpl$AbstractTLSContext. (SSLContextImpl.java:580) at java.lang.Class.forName0 (Native Method) at java.lang.Class.forName (Class.java:315) What I do wrong ? And what is the true way of deply ? This looks also very strange... Kind regards Karl Heinz Marbaise ----- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Mit freundlichem Gruß Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Inhaber Dipl.Ing.(FH) Karl Heinz Marbaise USt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen https://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Deploy fails
Hi, so there is a difference between the output you have posted: > Maven home: /opt/apache-maven-3.6.3 and the output in the error: >>> (file:/usr/share/maven/lib/guice.jar) to method Can you make a "ls -al /opt/apache-maven-3.6.3/lib" and "ls -la /usr/share/maven/lib/"... Also can you check if you have set an environment variable which starts with "M" (something like M2_HOME?? or alike? Kind regards Karl Heinz Marbaise On 10.11.22 20:21, Raivo Rebane wrote: Hi To me seems it is Apache Maven. raivo@Hydra:~/teamengine$ mvn -version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /opt/apache-maven-3.6.3 Java version: 11.0.16, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-52-generic", arch: "amd64", family: "unix" Am I right ? Regards Raivo On 10.11.22 20:23, Karl Heinz Marbaise wrote: Hi, On 10.11.22 15:58, Raivo Rebane wrote: Hello My Maven deploy fails : mvn install:install-file -Durl=file://repo -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar -DgroupId=lib -DartifactId=bind -Dpackaging=jar -Dversion=1.0 and gives error : WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This output looks strange, because the output of the file "guice.jar" is an indication that you are not using Apache Maven. It looks like you are using a repackaged variant of Apache Maven... which causes issues. First I would suggest to show what: "mvn --version" prints out... and can you please post that here? Tests [pom] [WARNING] Error injecting: org.apache.maven.wagon.providers.http.HttpWagon$__sisu20 java.lang.ExceptionInInitializerError at javax.crypto.Cipher.getInstance (Cipher.java:540) at sun.security.ssl.JsseJce.getCipher (JsseJce.java:190) at sun.security.ssl.SSLCipher.isTransformationAvailable (SSLCipher.java:509) at sun.security.ssl.SSLCipher. (SSLCipher.java:498) at sun.security.ssl.SSLCipher. (SSLCipher.java:81) at sun.security.ssl.CipherSuite. (CipherSuite.java:65) at sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuites (SSLContextImpl.java:348) at sun.security.ssl.SSLContextImpl$AbstractTLSContext. (SSLContextImpl.java:580) at java.lang.Class.forName0 (Native Method) at java.lang.Class.forName (Class.java:315) What I do wrong ? And what is the true way of deply ? This looks also very strange... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Deploy fails
Hi, On 10.11.22 15:58, Raivo Rebane wrote: Hello My Maven deploy fails : mvn install:install-file -Durl=file://repo -Dfile=/usr/java/jdk1.8.0_261-amd64/lib/javax.xml.bind.jar -DgroupId=lib -DartifactId=bind -Dpackaging=jar -Dversion=1.0 and gives error : WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This output looks strange, because the output of the file "guice.jar" is an indication that you are not using Apache Maven. It looks like you are using a repackaged variant of Apache Maven... which causes issues. First I would suggest to show what: "mvn --version" prints out... and can you please post that here? Tests [pom] [WARNING] Error injecting: org.apache.maven.wagon.providers.http.HttpWagon$__sisu20 java.lang.ExceptionInInitializerError at javax.crypto.Cipher.getInstance (Cipher.java:540) at sun.security.ssl.JsseJce.getCipher (JsseJce.java:190) at sun.security.ssl.SSLCipher.isTransformationAvailable (SSLCipher.java:509) at sun.security.ssl.SSLCipher. (SSLCipher.java:498) at sun.security.ssl.SSLCipher. (SSLCipher.java:81) at sun.security.ssl.CipherSuite. (CipherSuite.java:65) at sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuites (SSLContextImpl.java:348) at sun.security.ssl.SSLContextImpl$AbstractTLSContext. (SSLContextImpl.java:580) at java.lang.Class.forName0 (Native Method) at java.lang.Class.forName (Class.java:315) What I do wrong ? And what is the true way of deply ? This looks also very strange... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: testCompile with multiReleaseOutput main classes
Hi,
On 23.07.22 18:28, Stanimir Stamenkov wrote:
I want to produce a Java 8 compatible library that provides some Java 9+
classes, packaged as a Multi-Release JAR:
The best suggestion I can give is is to use a multi module setup.
https://github.com/khmarbaise/mrelease
Furthermore I'm not sure if you really need toolchains in your case?.
Kind regards
Karl Heinz Marbaise
*
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
I've taken a slimmed down _Multi-Release Parent_
<http://www.russgold.net/sw/2018/04/easier-than-it-looks/> approach, and
the main compilation and packaging seems just right:
maven-compiler-plugin
3.10.1
8
8
compile-java9
compile
compile
9
9
${project.basedir}/src/main/java9
true
maven-jar-plugin
3.2.2
true
Now I've added some test sources exercising the Java 9+ only classes,
but the `testCompile` goal seems unable to find them. Is it possible to
configure the `default-testCompile` execution to see the classes from
the `multiReleaseOutput` of the main compile?
FWIW, my current work-in-progress could be seen at:
* https://github.com/stanio/xbrz-java/commit/8c9564ee874
Re: Maven-Assembly-Plugin v3.4.1 not correctly processing assembly descriptors?
Hi,
You can verify that if you simply add the maven-common-artifact-filters
version in the dependencies part of the plugin configuration where you
defined the
dvtm.base
Assembly
Kind regards
Karl Heinz Marbaise
On 19.07.22 12:55, Jean Pierre URKENS wrote:
Looks like the issue is already reported:
https://issues.apache.org/jira/projects/MASSEMBLY/issues/MASSEMBLY-969?filter=allopenissues
and solved by
https://github.com/apache/maven-common-artifact-filters/pull/29.
Maven-Assembly-Plugin v3.4.1 uses maven-common-artifact-filters v3.3.0 ->
fails
Maven-Assembly-Plugin v3.3.0 uses maven-common-artifact-filters v3.1.0 ->
works
I will need maven-common-artifact-filters v3.3.1 released on 16/07/2022.
-Original Message-
From: Karl Heinz Marbaise
Sent: dinsdag 19 juli 2022 12:39
To: Maven Users List
Subject: Re: Maven-Assembly-Plugin v3.4.1 not correctly processing assembly
descriptors?
Hi,
can you make an example project on github or alike...
Kind regards
Karl Heinz Marbaise
On 19.07.22 12:07, Jean Pierre URKENS wrote:
I am trying to re-zip some deliverables into one packaging using the
maven-assembly-plugin.
My plugin configuration looks like:
org.apache.maven.plugins
*maven-assembly-plugin*
3.4.1
dvtm.base
Assembly
${dvtm.base.assembly.version}
unziprezip
I.e. the descriptor unziprezip is located in the artifact
dvtm.base.Assembly and contains a dependencySet as follows:
provided
/
false
true
**
dvtm*:*:zip:deliverables
Now if I try to execute ‘mvn assembly:single’ I get the error: Error
creating assembly archive deliverables: archive cannot be empty ->
[Help 1]
Looking at the maven log file I see that:
0.The plugin configuration looks like:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-assembly-plugin:3.4.1:single' with
basic configurator -->
[DEBUG] (s) appendAssemblyId = true
[DEBUG] (f) attach = true
[DEBUG] (s) basedir =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent
[DEBUG] (s) descriptorRefs = [unziprezip]
[DEBUG] (f) dryRun = false
[DEBUG] (f) encoding = UTF-8
[DEBUG] (s) finalName = AEO-KMO-Portefeuille-Parent-6.0.0-SNAPSHOT
[DEBUG] (f) ignoreDirFormatExtensions = true
[DEBUG] (f) ignoreMissingDescriptor = false
[DEBUG] (f) ignorePermissions = false
[DEBUG] (f) includeProjectBuildFilters = true
[DEBUG] (s) localRepository = id: local
[DEBUG] (f) mavenSession =
org.apache.maven.execution.MavenSession@586cc15d
[DEBUG] (s) outputDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target
[DEBUG] (f) project = MavenProject:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:6.0.0-SNAPSHOT @
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\pom.xml
[DEBUG] (s) reactorProjects = [MavenProject:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:6.0.0-SNAPSHOT @
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\pom.xml
]
[DEBUG] (f) recompressZippedFiles = true
[DEBUG] (f) remoteRepositories = […]
[DEBUG] (f) runOnlyAtExecutionRoot = false
[DEBUG] (s) siteDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\
site
[DEBUG] (f) skipAssembly = false
[DEBUG] (s) tarLongFileMode = warn
[DEBUG] (s) tempRoot =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\
archive-tmp
[DEBUG] (f) updateOnly = false
[DEBUG] (f) useJvmChmod = false
[DEBUG] (s) workDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\
assembly\work
[DEBUG] -- end configuration --
1.My project dependencies are included (and they do exist):
[DEBUG] Dependencies for project:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:jar:6.0.0-SNAPSHOT are:
dvtm.aeo.kmop:AEO-KMO-Portefeuille:zip:deliverables:6.0.0:provided
dvtm.aeo.kmop:AEO-KMO-Portefeuille-EAWS-webservice:zip:deliverables:2.
0.2:provided
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Emittent:zip:deliverables:4.0.0:pro
vided
…
2.All my dependencies are filtered out when processing the dependencySet:
[DEBUG] Processing DependencySet (output=/)
[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency
path information.
[DEBUG] dvtm.aeo.kmop:AEO-KMO-Portefeuille:zip:deliverables:6.0.0 *was
removed by one or more filters*.
…
3.In the end nothing is included in my assembly hence the final error
‘archive cannot be empty’
My project dependencie
Re: Maven-Assembly-Plugin v3.4.1 not correctly processing assembly descriptors?
Hi,
can you make an example project on github or alike...
Kind regards
Karl Heinz Marbaise
On 19.07.22 12:07, Jean Pierre URKENS wrote:
I am trying to re-zip some deliverables into one packaging using the
maven-assembly-plugin.
My plugin configuration looks like:
org.apache.maven.plugins
*maven-assembly-plugin*
3.4.1
dvtm.base
Assembly
${dvtm.base.assembly.version}
unziprezip
I.e. the descriptor unziprezip is located in the artifact
dvtm.base.Assembly and contains a dependencySet as follows:
provided
/
false
true
**
dvtm*:*:zip:deliverables
Now if I try to execute ‘mvn assembly:single’ I get the error: Error
creating assembly archive deliverables: archive cannot be empty -> [Help 1]
Looking at the maven log file I see that:
0.The plugin configuration looks like:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-assembly-plugin:3.4.1:single' with basic
configurator -->
[DEBUG] (s) appendAssemblyId = true
[DEBUG] (f) attach = true
[DEBUG] (s) basedir =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent
[DEBUG] (s) descriptorRefs = [unziprezip]
[DEBUG] (f) dryRun = false
[DEBUG] (f) encoding = UTF-8
[DEBUG] (s) finalName = AEO-KMO-Portefeuille-Parent-6.0.0-SNAPSHOT
[DEBUG] (f) ignoreDirFormatExtensions = true
[DEBUG] (f) ignoreMissingDescriptor = false
[DEBUG] (f) ignorePermissions = false
[DEBUG] (f) includeProjectBuildFilters = true
[DEBUG] (s) localRepository = id: local
[DEBUG] (f) mavenSession =
org.apache.maven.execution.MavenSession@586cc15d
[DEBUG] (s) outputDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target
[DEBUG] (f) project = MavenProject:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:6.0.0-SNAPSHOT @
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\pom.xml
[DEBUG] (s) reactorProjects = [MavenProject:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:6.0.0-SNAPSHOT @
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\pom.xml]
[DEBUG] (f) recompressZippedFiles = true
[DEBUG] (f) remoteRepositories = […]
[DEBUG] (f) runOnlyAtExecutionRoot = false
[DEBUG] (s) siteDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\site
[DEBUG] (f) skipAssembly = false
[DEBUG] (s) tarLongFileMode = warn
[DEBUG] (s) tempRoot =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\archive-tmp
[DEBUG] (f) updateOnly = false
[DEBUG] (f) useJvmChmod = false
[DEBUG] (s) workDirectory =
f:\Documents\Workspaces\AEO-Gitlab\aeo-kmo-portefeuille-parent\target\assembly\work
[DEBUG] -- end configuration --
1.My project dependencies are included (and they do exist):
[DEBUG] Dependencies for project:
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Parent:jar:6.0.0-SNAPSHOT are:
dvtm.aeo.kmop:AEO-KMO-Portefeuille:zip:deliverables:6.0.0:provided
dvtm.aeo.kmop:AEO-KMO-Portefeuille-EAWS-webservice:zip:deliverables:2.0.2:provided
dvtm.aeo.kmop:AEO-KMO-Portefeuille-Emittent:zip:deliverables:4.0.0:provided
…
2.All my dependencies are filtered out when processing the dependencySet:
[DEBUG] Processing DependencySet (output=/)
[DEBUG] Filtering dependency artifacts WITHOUT transitive dependency path
information.
[DEBUG] dvtm.aeo.kmop:AEO-KMO-Portefeuille:zip:deliverables:6.0.0 *was
removed by one or more filters*.
…
3.In the end nothing is included in my assembly hence the final error
‘archive cannot be empty’
My project dependencies (see point 1) do match with the -filter of
my dependencySet.
Referring to
https://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html
, I do not understand why my dependencies are are filtered out?
Is there a reference manual describing the exact configuration of the maven
element ?
*NOTE:* with maven-assembly-plugin set to version 3.3.0 the archive is
correctly assembled.
Regards,
J.P.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: JUnit 5 test suites not running again
On 08.07.22 18:09, David Karr wrote:
Inline.
On Fri, Jul 8, 2022 at 8:17 AM Karl Heinz Marbaise mailto:khmarba...@gmx.de>> wrote:
Hi,
On 08.07.22 16:18, David Karr wrote:
> I had gotten help here with our JUnit 5 transition, and I thought
I had it
> all working, but now I see that I'm back to the state where our
JUnit 5
> test suites are being ignored.
>
>>From what I understood, I had to ensure that
"junit-platform-runner" was
> excluded as a dependency. What I have seems to have done this,
but only
> halfway. The "dependency-tree" doesn't have that artifact.
However, when
> I generated the effective pom, I DID see that artifact. I'm not
sure what
> that means.
>
> I run this command line:
>
> mvn -U -Dtest=ComponentTestSuite test
>
> Here's an excerpt of the output:
> --
> [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> PlatformPilotMs ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> --
>
> As you can see, I'm using v3.0.0-M7 of Surefire. I'm using v1.8.2 of
> junit-platform, and v5.8.2 of junit-jupiter.
>
> I've designed a parent pom hierarchy that looks like this:
>
> sdk-java-parent:
> dependencyManagement includes "ext-bom" pom with scope "import"
> dependencies has a block like this:
> --
>
> ...
> seed-sdk-core
>
>
> org.junit.platform
> junit-platform-runner
>
>
>
> --
>
> The effective pom also has this:
> --
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M7
>
> 1
> false
>
> true
> ${surefireArgLine}
> false
>
> **/contract/*.java
> **/integration/*.java
> **/component/*.java
>
>
>
> ---
>
> What could we be missing?
>
Which dependencies do you have defined for running junit jupiter tests?
These are the resulting junit-jupiter dependencies in the effective pom:
junit-jupiter
junit-jupiter-api
junit-jupiter-engine
junit-jupiter-migrationsupport
junit-jupiter-params
Migrationsupport means JUnit 4... not JUnit Jupiter..
Check the example:
https://github.com/khmarbaise/youtube-videos/tree/episode-4/episode-4
Kind regards
Karl Heinz Marbaise
And these are the resulting junit-platform dependencies (still not sure
why junit-platform-runner is in here, when I'm excluding it AND it
doesn't appear in dependency:tree):
junit-platform-commons
junit-platform-console
junit-platform-engine
junit-platform-jfr
junit-platform-launcher
junit-platform-reporting
junit-platform-runner
junit-platform-suite
junit-platform-suite-api
junit-platform-suite-commons
junit-platform-suite-engine
junit-platform-testkit
Why do you think you need to exclude junit jupiter runner?
Not jupiter, but "junit-platform-runner". Looking at the message
history, I see that "Slawomir Jaranowski" at least, had said this.
Do you use the dependency junit-jupiter-engine as a dependency:
Are you using @Suite annotation of JUnit Jupiter?
Have you defined a class for example `ComponentTestSuite` like this:
@Suite
@SelectPackages("package.xxx")
@IncludeClassNamePatterns(".*Pattern")
class SuiteDemoTests {
}..
This is an excerpt of my test suite:
import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;
@Suite
@SelectClasses({...
--
If you like to run suites you have to have two dependencies:
org.junit.platform
junit-platform-suite-engine
test
org.junit.jupiter
junit-jupiter-engine
test
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: JUnit 5 test suites not running again
Hi,
On 08.07.22 16:18, David Karr wrote:
I had gotten help here with our JUnit 5 transition, and I thought I had it
all working, but now I see that I'm back to the state where our JUnit 5
test suites are being ignored.
From what I understood, I had to ensure that "junit-platform-runner" was
excluded as a dependency. What I have seems to have done this, but only
halfway. The "dependency-tree" doesn't have that artifact. However, when
I generated the effective pom, I DID see that artifact. I'm not sure what
that means.
I run this command line:
mvn -U -Dtest=ComponentTestSuite test
Here's an excerpt of the output:
--
[INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
PlatformPilotMs ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
--
As you can see, I'm using v3.0.0-M7 of Surefire. I'm using v1.8.2 of
junit-platform, and v5.8.2 of junit-jupiter.
I've designed a parent pom hierarchy that looks like this:
sdk-java-parent:
dependencyManagement includes "ext-bom" pom with scope "import"
dependencies has a block like this:
--
...
seed-sdk-core
org.junit.platform
junit-platform-runner
--
The effective pom also has this:
--
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
1
false
true
${surefireArgLine}
false
**/contract/*.java
**/integration/*.java
**/component/*.java
---
What could we be missing?
Which dependencies do you have defined for running junit jupiter tests?
Why do you think you need to exclude junit jupiter runner?
Do you use the dependency junit-jupiter-engine as a dependency:
Are you using @Suite annotation of JUnit Jupiter?
Have you defined a class for example `ComponentTestSuite` like this:
@Suite
@SelectPackages("package.xxx")
@IncludeClassNamePatterns(".*Pattern")
class SuiteDemoTests {
}..
If you like to run suites you have to have two dependencies:
org.junit.platform
junit-platform-suite-engine
test
org.junit.jupiter
junit-jupiter-engine
test
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified
Hi,
On 17.06.22 20:46, David Karr wrote:
Ok, what is the proper way to do that, considering I have the following in
a bom imported by my parent pom:
org.junit
junit-bom
import
pom
5.8.2
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
Do I add an exclusion to one or both of these?
This is to have the available dependencies.
You have to add junit-jupiter-engine
like this (not inside dependencyManagement):
org.junit.jupiter
junit-jupiter-engine
test
org.springframework.boot
spring-boot-starter-test
test
If you have a mix of JUNit 4 and JUnit 5 you have to go this way:
org.junit.jupiter
junit-jupiter-engine
test
org.junit.vintage
junit-vintage-engine
test
org.springframework.boot
spring-boot-starter-test
test
The vintage-engine is responsible for executing the JUnit 4 tests.
I have made an simple example with Spring Boot using JUnit 4 and JUnit 5.
Also added exemplary integration tests where one is JUnit 4 based and
one JUnit 5 based.
https://github.com/khmarbaise/minimal-junit4-junit5
Furthermore you shouldn't define the provider for surefire explicit
because it's identifying it itself. (In the given example I have not
defined the provider).
Kind regards
Karl Heinz Marbaise
On Fri, Jun 17, 2022 at 11:37 AM Slawomir Jaranowski
wrote:
Do you have on your classpath - junit-platform-runner?
Please remove it.
pt., 17 cze 2022 o 20:23 David Karr
napisał(a):
I'm posting a new note, as this might be a different issue.
I recently got good advice on this list about how to properly specify the
version overrides for the junit-bom artifacts. When I implemented that,
I
saw that I was consistently getting the correct versions for those
artifacts.
However, I'm now confused by the behavior that I'm seeing from
Surefire. I
currently have a mix of JUnit 4 and JUnit 5 tests. I'm pretty sure that
I
had this working before, but now I see that it is not running any of the
JUnit 5 tests.
Note the following excerpt from my build:
---
[INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
PlatformPilotMs ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junit4.JUnit4Provider
--
I'm using the very latest M version, as that resolves other issues we've
been having. When I look to see what tests were executed, I see that it
doesn't include any of my JUnit 5 tests.
I ran "mvn dependency:tree" to verify what versions of JUnit are in the
classpath, and it has BOTH JUnit 4.13 and junit-platform 1.8.2 and
junit-jupiter 5.8.2. The surefire doc page says "Surefire normally
automatically selects which test-framework provider to use based on the
version of TestNG/JUnit present in your project's classpath". Is the fact
that both are in the classpath causing this? Am I going to have to
manually
specify both the junit 4 and junit 5 providers in the surefire
dependencies? That is additionally annoying as I also have to redundantly
specify the versions of those artifacts (I tried not specifying a
version,
and it complained).
--
Sławomir Jaranowski
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to properly override junit-platform and junit-jupiter in a parent pom
Hi, On 17.06.22 02:27, David Karr wrote: Sorry, can you clarify exactly what you mean by that? Usually you have something in your pom file to use the spring boot dependencies: org.springframework.boot spring-boot-dependencies 2.3.12.RELEASE import pom That means by default you will use the junit-jupiter version which is defined by the spring-boot-dependencies. If you like to overwrite that you have to define the junit-bom before the spring boot dependencies like this: org.junit junit-bom 5.8.2 import pom org.springframework.boot spring-boot-dependencies 2.3.12.RELEASE import pom After using this in your parent pom all of the junit jupiter dependencies have to be in version 5.8.2 Furthermore if you check the dependency tree via mvn dependency:tree you should check which version of the maven-dependency-plugin you are using? (Most recent one?)... PS.: The version of spring boot which is used is already out of support (https://spring.io/projects/spring-boot#support). Kind regards Karl Heinz Marbaise On Thu, Jun 16, 2022 at 4:14 PM Karl Heinz Marbaise wrote: Hi, It's important to define the junit-bom import before the spring-boot-dependencies import part in dependencyManagement which assumes you don't use spring-boot-parent? Kind regards Karl Heinz Marbaise On 16.06.22 23:54, David Karr wrote: We have a bunch of services running Spring Boot 2.3.12, which by default uses junit-platform 1.6.3 and junit-jupiter 5.6.3. We are trying to instead use junit-platform 1.8.2 and junit-jupiter 5.8.2. All the artifacts and versions we need are in junit-bom-5.8.2. We want to control this in our parent pom(s), as we have dozens of similar services all using the same parent pom. I thought I had this working, but now it appears it's not, and I'm not sure what I'm missing. At one time I had thought all I had to do was include junit-bom v5.8.2 in the "dependencies" list in the parent pom, but that never worked. For lack of any other solution, I simply pasted the contents of the "dependencies" list from junit-bom-5.8.2 into the "dependencies" list of my parent pom. At one point, I thought this was working. Today, I'm looking at one service that uses that parent pom, but for some reason it's not getting the newer versions of the artifacts, it's still getting 1.6.3 and 5.6.3. I'm looking at both "mvn dependency:tree" and the "Dependency Hierarchy" view in Eclipse. I'm not completely certain how to interpret what I'm seeing. The first thing I want to know is what is the best way to do this sort of thing. I find it hard to believe pasting the entire contents of the bom that I want into the parent pom was the right way to do it, but I couldn't get it to work any other way, and now it's not working anyway. I can provide more details of specific poms and parent poms, but I wanted to see if there was a simple solution first. I am basically aware of the difference between "dependencyManagement" and "dependencies" in a parent pom. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to properly override junit-platform and junit-jupiter in a parent pom
Hi, It's important to define the junit-bom import before the spring-boot-dependencies import part in dependencyManagement which assumes you don't use spring-boot-parent? Kind regards Karl Heinz Marbaise On 16.06.22 23:54, David Karr wrote: We have a bunch of services running Spring Boot 2.3.12, which by default uses junit-platform 1.6.3 and junit-jupiter 5.6.3. We are trying to instead use junit-platform 1.8.2 and junit-jupiter 5.8.2. All the artifacts and versions we need are in junit-bom-5.8.2. We want to control this in our parent pom(s), as we have dozens of similar services all using the same parent pom. I thought I had this working, but now it appears it's not, and I'm not sure what I'm missing. At one time I had thought all I had to do was include junit-bom v5.8.2 in the "dependencies" list in the parent pom, but that never worked. For lack of any other solution, I simply pasted the contents of the "dependencies" list from junit-bom-5.8.2 into the "dependencies" list of my parent pom. At one point, I thought this was working. Today, I'm looking at one service that uses that parent pom, but for some reason it's not getting the newer versions of the artifacts, it's still getting 1.6.3 and 5.6.3. I'm looking at both "mvn dependency:tree" and the "Dependency Hierarchy" view in Eclipse. I'm not completely certain how to interpret what I'm seeing. The first thing I want to know is what is the best way to do this sort of thing. I find it hard to believe pasting the entire contents of the bom that I want into the parent pom was the right way to do it, but I couldn't get it to work any other way, and now it's not working anyway. I can provide more details of specific poms and parent poms, but I wanted to see if there was a simple solution first. I am basically aware of the difference between "dependencyManagement" and "dependencies" in a parent pom. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problem using maven to gpg-sign artifacts
On 10.06.22 19:26, Karl Heinz Marbaise wrote: Hi Rick, On 10.06.22 17:55, Rick Hillegas wrote: I am having trouble signing maven artifacts. The details of the problem are described at https://issues.apache.org/jira/browse/INFRA-23348. The maven error message is terse. No additional useful information comes back when I run the maven command with -e and -X switches. I haven't found any useful information on the web. My environment is as follows: Mac OSX 11.2.3 Apache Maven 3.5.0 gpg (GnuPG) 2.3.6 (libgcrypt 1.10.1) openjdk version "11" 2018-09-25 This is the command which fails... mvn -Dgpg.passphrase="blah blah blah my passphrase" clean deploy ...and this is the error message I see: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.3:sign (sign-artifacts) on project derby-project: Exit code: 2 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.3:sign (sign-artifacts) on project derby-project: Exit code: 2 I would appreciate any advice you can give me about how to debug this problem. Ah furthermore what I missed I strongly recommend to upgrade the Maven version as well.... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problem using maven to gpg-sign artifacts
Hi Rick, On 10.06.22 17:55, Rick Hillegas wrote: I am having trouble signing maven artifacts. The details of the problem are described at https://issues.apache.org/jira/browse/INFRA-23348. The maven error message is terse. No additional useful information comes back when I run the maven command with -e and -X switches. I haven't found any useful information on the web. My environment is as follows: Mac OSX 11.2.3 Apache Maven 3.5.0 gpg (GnuPG) 2.3.6 (libgcrypt 1.10.1) openjdk version "11" 2018-09-25 This is the command which fails... mvn -Dgpg.passphrase="blah blah blah my passphrase" clean deploy ...and this is the error message I see: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.3:sign (sign-artifacts) on project derby-project: Exit code: 2 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.3:sign (sign-artifacts) on project derby-project: Exit code: 2 I would appreciate any advice you can give me about how to debug this problem. The first and important thing is that you should upgrade your maven-gpg-plugin version because 1.3 is very old (ten years old).. https://maven.apache.org/plugins/maven-gpg-plugin/ Kind regard Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to retrieve target folder / jar paths from multi-module Maven project
Hi, On 07.06.22 05:22, Laurian Angelescu wrote: Is it possible to invoke *mvn* on the command line to output either 1) the paths to all target folders where jars get packaged or 2) the file paths of the jars themselves? For example, in a multi-module project like https://github.com/apache/httpcomponents-core.git, I would like to invoke: *mvn * and have output to standard out: //httpcore5/target/httpcore5-5.2-beta1.jar //httpcore5-h2/target/httpcore5-h2-5.2-beta1.jar ... etc. I want to essentially be able to get a list of the JARs created in *any *Maven multimodule project. Can you explain why you need those directory information? What kind of problem are you trying to solve? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Apache Maven Daemon 0.8.0 released
Hi, On 11.05.22 11:12, Guillaume Nodet wrote: The Apache Maven team is pleased to announce release of the Apache Maven Daemon version 0.8.0. Apache Maven Daemon is a daemon infrastructure for Maven with caching capabilities and a native client for a better and faster user experience. This is the 1st release of the Apache Maven Daemon since its donation to the ASF. This release embeds Apache Maven 3.8.5. The release is available for download at: https://downloads.apache.org/maven/mvnd/0.8.0/ Regards, The Apache Maven Team Is there a reason why the tags on the Git Hub repo is currently only at "draft" level? Furthermore there is no changelog as done in 0.7.1 (https://github.com/apache/maven-mvnd/releases/tag/0.7.1). Furthermore what about having a release notes content as we have for other plugins/components here...(we have no JIRA entry for that which is fine)... can be created from the changelog (would be very good). The idea is to send this information through the announcement mailing on the announcement mailing list ... And also it could be posted to the ASF blog... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Apache Maven JLink Plugin Version 3.0.0 Released
Hi, would you please leave such comments of this list... This is the users mailing list of Apache Maven... Kind regards Karl Heinz Marbaise On 13.05.22 09:18, Caroline Revin wrote: Bonjour, Je vous contacte car j’avais noté un échange avec vous courant avril 2022 afin de faire le point sur vos besoins informatiques pour les mois à venir Avez-vous un moment à m’accorder à ce sujet ? Je vous remercie, Cordialement, Caroline Revin IT Resourcer Prestation et Recrutement 24 rue Poncelet 75017 Paris caroline.re...@prestation-recrutement.com -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@apache.org] Sent: mercredi 25 novembre 2020 20:50 To: annou...@maven.apache.org; users@maven.apache.org Cc: d...@maven.apache.org Subject: [ANN] Apache Maven JLink Plugin Version 3.0.0 Released The Apache Maven team is pleased to announce the release of the Apache Maven JLink Plugin, version 3.0.0 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. https://maven.apache.org/plugins/maven-jlink-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jlink-plugin 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-jlink-plugin/download.cgi Release Notes - Maven JLink Plugin - Version 3.0.0 * Bugs: * [MJLINK-4] - NPE on execution * [MJLINK-5] - Parameter 'compression' is wrong. It is 'compress' * [MJLINK-23] - Allow setting additional modulepaths * New Features: * [MJLINK-9] - Add support for multi module projects * [MJLINK-18] - Add support for JLink launcher * Improvements: * [MJLINK-1] - Dependency Report produces exception based on JDK 9 based JAR file... * [MJLINK-3] - Improve verbose output during build * [MJLINK-6] - Allow set the jmods path * [MJLINK-14] - Let POM parent do it's work * [MJLINK-15] - Upgrade plexus-java 0.9.7 * [MJLINK-26] - Can not create an image from a single module project without a dependency * [MJLINK-28] - Add WARNING in case of duplicate module names * [MJLINK-45] - make build Reproducible * [MJLINK-50] - Upgrade to Java 8 / Maven 3.1.0 * Dependency upgrades * [MJLINK-8] - Upgrade plexus-java 0.9.5 * [MJLINK-10] - Upgrade maven-plugin-plugin to 3.5.1 * [MJLINK-11] - Upgrade parent to 31 * [MJLINK-13] - Remove hard code version for maven-site-plugin * [MJLINK-16] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MJLINK-17] - Add documentation information for GitHub * [MJLINK-20] - Upgrade plexus-archiver to 3.6.0 * [MJLINK-21] - Upgrade test dependencies * [MJLINK-22] - Upgrade maven-plugins parent to version 32. * [MJLINK-24] - Upgrade bound plugins * [MJLINK-25] - Upgrade bounded plugins (maven-resources-plugin to 3.1.0) * [MJLINK-29] - Upgrade maven-compiler-plugin to version 3.8.0 in IT's * [MJLINK-30] - Upgrade parent to version 33 * [MJLINK-31] - Upgrade plexus-java 0.9.11 * [MJLINK-32] - Upgrade plexus-archiver 3.7.0 * [MJLINK-33] - Upgrade maven-archiver 3.3.0 * [MJLINK-34] - Upgrade java-language to 1.0.1 * [MJLINK-35] - Upgrade plexus-archiver - 4.1.0 * [MJLINK-37] - Upgrade maven-archiver to 3.4.0 * [MJLINK-38] - Upgrade plexus-java 1.0.3 * [MJLINK-43] - upgrade plexus-java 1.0.5 * [MJLINK-44] - Upgrade maven-plugins to 34 * [MJLINK-46] - Upgrade maven-archiver to 3.5.0 Enjoy, -The Apache Maven team Mit freundlichem Gruß Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen https://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclusions are not being applied
Hi,
On 27.04.22 01:40, Jacques Etienne Beaudet wrote:
Exclusions are not yet supported at the dependencyManagement level. See
https://stackoverflow.com/questions/39276024/import-dependency-management-with-exclusion
for more informations or the corresponding unmerged PR
https://github.com/apache/maven/pull/295
This is related to dependencyManagement and import scope (for BOM's)...
Not to that case.
Kind regards
Karl Heinz Marbaise
Exclude it when you include the dependency in the meantime.
On Apr 26, 2022, 7:35 PM -0400, David Hoffer , wrote:
I have a project where I am trying to use exclusions to exclude transitive
dependencies but they are not being excluded. Here is an example from my
dependencyManagement top level pom.
com.bs.component-library.model
model
${model.version}
io.swagger.core.v3
swagger-jaxrs2
Then in the build this is in the dependency section.
com.bs.component-library.model
model
However when I run mvn dependency:tree
I still see io.swagger.core.v3:swagger-jaxrs2:jar:2.1.11:compile as a
first level dependency under the model dependency.
Why is it not being excluded?
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin Version 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.3.0 https://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 3.3.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-shade-plugin/download.cgi Release Notes Maven Shade Plugin 3.3.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348391=Text=12317921 * Bugs: * [MSHADE-252] - shadeSourcesContent is broken when combined with partial relocation * [MSHADE-396] - Improve SourceContent Shading * New Feature: * [MSHADE-36] - Add option to include dependency reduced POM instead of original one * Improvements: * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag * [MSHADE-371] - Update Shade Apache[Notice/LICENSE]ResourceTransformer to use also [NOTICE/LICENSE].md * [MSHADE-373] - Source transformation on source jar can break OSGi resolution due to duplicated bundle name * [MSHADE-382] - Add an option to skip execution * [MSHADE-391] - Do not modify class files, if nothing was relocated * [MSHADE-405] - ShowOverlapping Uses http instead of https Tasks: * [MSHADE-389] - Get rid of old baggage * [MSHADE-390] - Implement Sisu index transformer * [MSHADE-401] - Improve ServiceResourceTransformer * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with manifest transformer Dependency upgrades: * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0 * [MSHADE-386] - Update JDependency to 2.6.0 * [MSHADE-407] - Update ASM to 9.2 to support Java 17 Enjoy - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible protocol error, handshake_error when using Maven
Hi, can you please write which exact version of the JDK you are using? Furthermore the Maven version you are using a bit out of time... Simplest try would be to upgrade to most recent version of Maven... Kind regards Karl Heinz Marbaise On 28.01.22 18:08, christopher.mil...@gd-ms.com wrote: Using Maven 3.5.4 on RHEL 8.1 with OpenJDK 1.8. I've been using maven okay for awhile now and now I'm getting the following error when running a pom.xml file. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project SOFTWARE_Build_Media: Execution default-jar of goal org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: Plugin org.apache.maven.plugins:maven-jar-plugin:2.4 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-jar-plugin:jar:2.4 -> org.apache.maven:maven-archiver:jar:2.5: Failed to read artifact descriptor for org.apache.maven:maven-archiver:jar:2.5: Could not transfer artifact org.apache.maven:maven-archiver:pom:2.5 from/to central (https://repo.maven.apache.org/maven2): Received fatal alert: handshake_failure -> [Help 1] If I add -X to the end of my mvn command, I see this error often: Received fatal alert: handshake_failure Googling around, might be a TLS mismatch issue. Is there anyway to tell and correct it? I've tried to add the following tag to my settings.xml, true and get the same error. Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Question for Maven Plugin developers/maintainers
On 28.01.22 14:52, Tamás Cservenák wrote: Howdy, We'd like to get some feedback from anyone who implemented, maintained or plans to implement a Maven Plugin (Mojo): Did any of you see a Maven Plugin that is NOT implemented in Java (but uses Ant or Beanshell scripting)? No... Currently implementing Maven Plugins with these scripting solutions is possible, we are not aware of any uses of it. Hence, we would like to deprecate support for these (naturally, based on user responses). Yes please. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is Apache Maven vulnerable to log4shell
Hi, On 15.12.21 17:32, Sesterhenn, Jörg wrote: Hi, we are wondering if Apache Maven (in any version) might be vulnerable to log4shell in any way. Can someone please provide a response to this question. Thank you in advance! First Maven itself will not run in a Server app only on command line once...so in general it is not possilbe in the way as log4jshell problem is described. Furthermore if you check the dependencies in Maven itself there is no dependency to log4j-* ... To be clear there could be other ways to inject something malicious via other ways ... Kind regards Karl Heinz Marbaise Regards, Jörg Sesterhenn -- Jörg Sesterhenn Hauptreferent Debeka Krankenversicherungsverein a. G. Debeka Lebensversicherungsverein a. G. Debeka Allgemeine Versicherung AG Debeka Pensionskasse AG Debeka Bausparkasse AG Abteilung IT-Grundlagen & -Engineering IT-Prozesse und Automatisierung (IE/P) 56058 Koblenz Telefon: (02 61) 4 98 - 14 55 Telefax: (02 61) 4 98 - 15 41 E-Mail: joerg.sesterh...@debeka.de<mailto:joerg.sesterh...@debeka.de> Internet: www.debeka.de<http://www.debeka.de> Besuchen Sie uns auch in sozialen Netzwerken. Unsere Adressen finden Sie hier: www.debeka.de/socialmedia<http://www.debeka.de/socialmedia> Pflichtangaben der Debeka-Unternehmen gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben<http://www.debeka.de/pflichtangaben> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can not use a snapshot version in parent
Hi, On 04.10.21 12:46, mar...@aldrin.net wrote: I did a rename of another build job. I changed the version postfix from BLACK to SNAPSHOT, and then the same issues started to happen for regular dependencies. This is something we have had for years working with the name BLACK, and suddenly when I renamed it to SNAPSHOT. During that change I also changed the repository to our snapshot repository, but they are configured very identical on the nexus server. Except that we allow re-deploy for snapshots. So I get the feeling that something differs between regular releases and Snapshots. Of course there is a big difference between SNAPSHOT and Releases. Releases are immutable which means they will not being deleted. SNAPSHOT's are only temporarily. Depending how your Nexus is configured on a regular base the SNAPSHOT's will be deleted (older ones) and creating a release would delted the related SNAPSHOTs.. Kind regards Karl Heinz Marbaise /Martin On October 4, 2021 at 8:35:44 am +02:00, mar...@aldrin.net wrote: Hi again, I tried to reproduce the fault with more logs, but I'm not able to do that. So I guess the problem is related to when I try to uplift the parent in many project at the same time. So it might be that the .m2 get corrupt for the snapshot version, but I have never seen the same issue when I do the same for regular releases. I have 30 servers, and each of them have it is own .m2 repository, but I allow 3 executors per server, so 3 jobs can share the same local repository. Maybe I must have a local repository per Jenkins executor. Regards /Martin On October 3, 2021 at 11:52:35 pm +02:00, Hervé BOUTEMY wrote: can you please share the xxx part of your pom.xml, please? and look at logs of "mvn -X", to see precisely what urls are fetched? Regards, Hervé Le samedi 2 octobre 2021, 10:58:14 CEST Martin Aldrin a écrit : Hi, thanks for the answer. 1. We have used this format for years in our CI. And it works perfect for all other dependencies. 2. Yes, the artifact exist on our nexus server. And it works perfect if I first fetch it to my local repository. Regards /Martin On 2 Oct 2021, at 09:53, Hervé BOUTEMY mailto:herve.bout...@free.fr>> wrote: Hi Martin, I'm replying to users@maven.apache.org <mailto:users@maven.apache.org> because iss...@maven.apache.org <mailto:iss...@maven.apache.org> is not a mailing list where anybody answers :) Looking at the log, I see "Could not find artifact com.x.commonlibrary:cl- parent:pom:1.5.39-20210922124845805-SNAPSHOT" It seems you referenced parent POM as "1.5.39-20210922124845805-SNAPSHOT" when: 1. you should not add the "-SNAPSHOT" suffix but "1.5.39-20210922124845805": Maven detects that the suffix represents a SNAPSHOT 2. are you sure of your "-20210922124845805" value, as it is represented in your repository? With usual format (that I think is the only one supported), it should be "-20210922.124845-805" Regards, Hervé Le vendredi 1 octobre 2021, 13:46:42 CEST mar...@aldrin.net <mailto:mar...@aldrin.net> a écrit : Hi, My problem is that I want to test uplift our parent on 400 project to test the combability with Java 17 without releasing the new parent. It works perfect for regular releases, but not if I using a snapshot with time prefix. Do any one have a idea if this can be solved in any way or if I'm doing something wrong. It works if first trigger a download of the snapshot artifact, but I don't want to do that manually on all different servers, I hope the snapshot could be downloaded automatically as it works for regular dependencies. mvn -U help:evaluate -f pom.xml -Dexpression=project.properties Exit Code: 1[Pipeline]ech)Warning: A secret was passed to "echo" using Groovy String interpolation, which is insecure. Affected argument(s) used the following variable(s):[FUNCTIONAL_CRED_USR] See[<https://jenkins.io/redirect/groovy-string-interpolatio <https://jenkins.io/redirect/groovy-string-interpolatio>>|<https://j
Re: installation from source rat "too many unapproved licenses"
Hi Roger, On 08.03.21 20:30, Roger Pack wrote: Hello. After doing a git clonehttps://github.com/apache/maven.git, I try this, following the instructions from the bottom of the README to install from source: $ mvn -DdistributionTargetDir="$HOME/app/maven/apache-maven-3.7.x-SNAPSHOT" clean package It fails with this message: [INFO] Rat check: Summary over all files. Unapproved: 1, unknown: 1, generated: 0, approved: 18 licenses. ... [INFO] Apache Maven ... FAILURE [ 49.494 s] ... [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.13:check (rat-check) on project maven: Too many files with unapproved license: 1 See RAT report in: /redacted.../target/rat.txt -> [Help 1] rat.txt file shows this culprit. !? distro/bin/m2.conf Can you please describe exactly which branch you are using? Which JDK you are using and which Maven version you are using to build? because I can't reproduce this... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Removing the text "Generated by maven-plugin-tools 3.5 on 2021-02-11"
On 05.03.21 15:02, jagmohan bisht wrote: After creating a maven plugin I am seeing the automated text "Generated by maven-plugin-tools 3.5 on 2021-02-11" on my plugin.xml file. I want this text message to be removed . How to achieve this? As I already asked on So... What exactly is causing the issue? Why do you build several times? Do you don't make a release of your plugin to get a reliable state of your plugin? Please show a full example.. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Apache Maven JLink Plugin Version 3.0.0 Released
Hi, On 26.11.20 18:33, Jörg Schaible wrote: Hallo Karl- Heinz, Am Mittwoch, 25. November 2020, 20:49:52 CET schrieb Karl Heinz Marbaise: The Apache Maven team is pleased to announce the release of the Apache Maven JLink Plugin, version 3.0.0 Here we have the description for the dependency plugin: The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. Bad Copy issue... Sorry... Kind regards Karl Heinz Marbaise [snip] Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven JLink Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JLink Plugin, version 3.0.0 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. https://maven.apache.org/plugins/maven-jlink-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jlink-plugin 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-jlink-plugin/download.cgi Release Notes - Maven JLink Plugin - Version 3.0.0 * Bugs: * [MJLINK-4] - NPE on execution * [MJLINK-5] - Parameter 'compression' is wrong. It is 'compress' * [MJLINK-23] - Allow setting additional modulepaths * New Features: * [MJLINK-9] - Add support for multi module projects * [MJLINK-18] - Add support for JLink launcher * Improvements: * [MJLINK-1] - Dependency Report produces exception based on JDK 9 based JAR file... * [MJLINK-3] - Improve verbose output during build * [MJLINK-6] - Allow set the jmods path * [MJLINK-14] - Let POM parent do it's work * [MJLINK-15] - Upgrade plexus-java 0.9.7 * [MJLINK-26] - Can not create an image from a single module project without a dependency * [MJLINK-28] - Add WARNING in case of duplicate module names * [MJLINK-45] - make build Reproducible * [MJLINK-50] - Upgrade to Java 8 / Maven 3.1.0 * Dependency upgrades * [MJLINK-8] - Upgrade plexus-java 0.9.5 * [MJLINK-10] - Upgrade maven-plugin-plugin to 3.5.1 * [MJLINK-11] - Upgrade parent to 31 * [MJLINK-13] - Remove hard code version for maven-site-plugin * [MJLINK-16] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MJLINK-17] - Add documentation information for GitHub * [MJLINK-20] - Upgrade plexus-archiver to 3.6.0 * [MJLINK-21] - Upgrade test dependencies * [MJLINK-22] - Upgrade maven-plugins parent to version 32. * [MJLINK-24] - Upgrade bound plugins * [MJLINK-25] - Upgrade bounded plugins (maven-resources-plugin to 3.1.0) * [MJLINK-29] - Upgrade maven-compiler-plugin to version 3.8.0 in IT's * [MJLINK-30] - Upgrade parent to version 33 * [MJLINK-31] - Upgrade plexus-java 0.9.11 * [MJLINK-32] - Upgrade plexus-archiver 3.7.0 * [MJLINK-33] - Upgrade maven-archiver 3.3.0 * [MJLINK-34] - Upgrade java-language to 1.0.1 * [MJLINK-35] - Upgrade plexus-archiver - 4.1.0 * [MJLINK-37] - Upgrade maven-archiver to 3.4.0 * [MJLINK-38] - Upgrade plexus-java 1.0.3 * [MJLINK-43] - upgrade plexus-java 1.0.5 * [MJLINK-44] - Upgrade maven-plugins to 34 * [MJLINK-46] - Upgrade maven-archiver to 3.5.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven ignoring JUnit5 tests when run from command line
Hi,
the configuration in your pom file is wrong...
Several parts.. not using the most recent version of JUnit Jupiter
(current 5.7.0) furthermore not the right version of
maven-surefire-pugin as described in the JUnit Jupiter documentation ...
Also mixing assertions in JUnit 4 test vs .JUnit 5 Test...
In your JUnit 5 Tests only imports from:
org.junit.jupiter.api.* should be there...
Assertions.fail(mess);
instead of: Assert.fail(mess);
I have attached the cleaned up pom file which you can take a look ...
Also you should check the names of your test methods ... ... the prefix
"test__" is not needed anymore since JUnit 4 ...
Kind regards
Karl Heinz Marbaise
On 24.11.20 18:15, Alain Désilets wrote:
I am trying to upgrade from JUnit4 to JUnit5 and am experiencing a
strange issuewhereby:
- JUnit4 tests are fine
- JUnit5 tests work when run through intelliJ, but are ignored when run
through the maven command line
I attach a small project (zip file) that illustrates the issue. Also
attached is the output (footest.txt) of running this command:
mvn clean install > footest.txt
If you look in that file, you see a failure message for test__JUnit4Test
which proves that the test was run. But there are no failure message
for test__JUnit5Test which proves that this test was NOT run.
When I run the tests in intelliJ, I see failures for both tests which
proves that they were both run.
From my reading, I see that several people have reported this issues
but none of the proposed fixes work for me. Any help would be appreciated.
BTW: Here is the info about my maven version
*Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)*
Maven home: /opt/apache-maven
Java version: 1.8.0_102, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
Thx.
Alain Désilets
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen https://www.soebes.de
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
ca.nrc.spikes
spike-junit
1.0.0-SNAPSHOT
1.8
1.8
UTF-8
UTF-8
4.12
org.junit
junit-bom
5.7.0
pom
import
org.junit.jupiter
junit-jupiter
test
junit
junit
${junit.version}
test
maven-surefire-plugin
3.0.0-M5
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Creating JAR file in WAR module leads to error in EAR creation
XXX-web-${project.version}.war
/XXX
/
The specifies that the type of the artifact must be WAR.
So the maven-ear-plugin tries to match that against the artifacts of the project
(means the ).
And that also works.
But it seems that the maven-install-plugin and / or maven-deploy-plugin
overwrite the file-path of the WAR at runtime of the Maven build in memory.
I don't know why and I also don't know how to prevent it.
Best regards,
Gerrit
Best would be to have an example project on Github or alike where we can
take a look on it ...and help here...
Kind regards
Karl Heinz Marbaise
-Ursprüngliche Nachricht-
Von: Hohl, Gerrit
Gesendet: Donnerstag, 12. November 2020 13:33
An: Maven Users List (users@maven.apache.org)
Betreff: Creating JAR file in WAR module leads to error in EAR creation
Hello everyone,
I have a project consisting of several modules, one being a WAR module and one
being an EAR module.
The EAR module has a dependency on the WAR module.
It turned out that I need the classes of that WAR module also as a JAR file for
our UI project.
So I added a install-file goal for the maven-install-plugin and a deploy-file
goal for the maven-deploy-plugin.
The WAR module build now creates the JAR file successfully and also deploys it.
But now my EAR module fails:
Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.0.2:ear
(default-ear) on project XXX-ear: Cannot copy a directory:
C:\XXX\XXX-pom\XXX-web\target\classes; Did you package/install
XXX:XXX-web:war:1.0.18:compile? -> [Help 1]
I looked up the code of the maven-ear-plugin. It seems it the following line is
the problem:
https://github.com/apache/maven-ear-plugin/blob/b289e6c271d50172c871e528105dda81d6f702b8/src/main/java/org/apache/maven/plugins/ear/EarMojo.java#L424
For some reason the file attribute of the Artifact object seems to contain the
path to the classes directory if the JAR file is build.
If I uncomment the JAR file creation in the WAR module it seems it contains the
WAR file path.
Things get even more interesting: When I created the JAR file, but build the
WAR and the EAR independently (not by building the parent project), it works
perfectly.
Seems something overwrites that information (the path of the WAR) and that
information is kept also during the build step of the EAR file.
So I'm not sure what I'm doing wrong or how I can fix it.
Anyone faced a similar problem in the past?
Best regards,
Gerrit
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven goal for dependencies
On 11.11.20 10:16, Milan Tomic wrote: Hello I have a Maven Java project which produces a JAR (packaging = JAR). I am using external SonarQube scanner to scan my source code (SonarQube is not configured inside pom.xml). I am first building my project using "mvn clean package", then I execute SonarQube Scanner on it. The issue is that SonarQube requires my project's dependencies to be on the path in order to properly scan my code. So, I need some Maven goal which will collect all dependencies in my project and place them inside of the /lib folder. Which Maven goal should I use? Final result should be /lib folder containing apache, spring... dependencies. Thank you in advance,Milan will handle that on plain command line without copying dependencies etc. you might need to configure the sonar host/branch/login via the given properties: mvn clean verify \ -Dsonar.host.url=URL \ -Dsonar.login=SONARTOKEN \ -Dsonar.branch.name=NAME \ org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Preferred way to execute Maven goals/phases from Maven plugins
Hi, the Maven Release Plugin 3.0.0-M1... supports of writing own rules #1 .. etc. Furthermore I would use simply things like versions-maven-plugin otherwise (or tycho versions plugin to support OSGi with some script steps in Jenkins for git magic (which I used a long time ago)... What is the problem with release branches? ... Kind regards Karl Heinz Marbaise #1: https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#releaseStrategyId On 02.11.20 14:07, Nick Stolwijk wrote: Hi Karl, Unfortunately, the Maven-Release-Plugin doesn't cut it for us. 1. It doesn't support Tycho builds with regard to versions [1] 2. We do use release branches on our products (Eclipse RCP and docker containers) to do some acceptance testing. That's why we used to use the Atlassian Gitflow plugin (alas, they didn't support Tycho either) and are now migrating to the aforementioned plugin. [1] https://www.eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/set-version-mojo.html With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, Nov 2, 2020 at 2:00 PM Karl Heinz Marbaise wrote: Hi, On 02.11.20 11:27, Nick Stolwijk wrote: Hi folks, We are struggling with our buildserver (Jenkins) and the Git-Flow Maven Plugin[1] with regards to execute the Maven executable to run specific goals and phases during release (i.e. run versions plugin to change version or run `mvn verify` to check project). In Jenkins you should run simple things like: mvn clean verify or if you deploy your artifacts to a repository manager: mvn clean deploy And check if your Jenkins uses the correct settings.xml (can be handled via config-file-provider plugin in Jenkins). If you like to make a release in Jenkins use a freestyle job to execute that... via `mvn release:prepare release:perform` I doubt that it would be a good idea to use git-flow-maven-plugin to create a release ... Apart from that I think that git-flow is to complex cause usually you don't need git flow with the complex branching model... Kind regards Karl Heinz Marbaise The gitflow-m-p uses a flag to set the executable which needs to know if it is on Linux (run mvn) or Windows (run mvn.cmd). I was wondering what is the 'right' way to execute Maven from a plugin. I've taken a look at the Maven Release Plugin and that one uses an internal Executor framework. I have thought about Toolchain, but I didn't find an example of a toolchain with Maven itself. Can anyone enlighten me? [1] https://github.com/aleksandr-m/gitflow-maven-plugin With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Preferred way to execute Maven goals/phases from Maven plugins
Hi, On 02.11.20 11:27, Nick Stolwijk wrote: Hi folks, We are struggling with our buildserver (Jenkins) and the Git-Flow Maven Plugin[1] with regards to execute the Maven executable to run specific goals and phases during release (i.e. run versions plugin to change version or run `mvn verify` to check project). In Jenkins you should run simple things like: mvn clean verify or if you deploy your artifacts to a repository manager: mvn clean deploy And check if your Jenkins uses the correct settings.xml (can be handled via config-file-provider plugin in Jenkins). If you like to make a release in Jenkins use a freestyle job to execute that... via `mvn release:prepare release:perform` I doubt that it would be a good idea to use git-flow-maven-plugin to create a release ... Apart from that I think that git-flow is to complex cause usually you don't need git flow with the complex branching model... Kind regards Karl Heinz Marbaise The gitflow-m-p uses a flag to set the executable which needs to know if it is on Linux (run mvn) or Windows (run mvn.cmd). I was wondering what is the 'right' way to execute Maven from a plugin. I've taken a look at the Maven Release Plugin and that one uses an internal Executor framework. I have thought about Toolchain, but I didn't find an example of a toolchain with Maven itself. Can anyone enlighten me? [1] https://github.com/aleksandr-m/gitflow-maven-plugin With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Issues when compiling basic Java SE using Maven
Hi, the problem is simply you are trying to access central repository via http instead of https So you have to change the configuration in Maven as well as in Netbeans to use the https://repo.maven.apache.org/maven2 Since 15. January 2020 access to central only via https: https://support.sonatype.com/hc/en-us/articles/360041287334-Central-501-HTTPS-Required Kind regards Karl Heinz Marbaise On 07.10.20 08:34, rafa wrote: Hi everyone, I am new on Maven and I am trying to create project and compile project using Netbeans IDE. I have successfully installed Maven Then I have created a Java SE application using Maven in Netbeans. Find attached the pom.xml When trying to compile it through netbeans, I get next: /cd C:\Datos\Java\MavenTest; "JAVA_HOME=C:\\Program Files\\Java\\jdk1.8.0_151" cmd /c "\"\"C:\\Program Files\\NetBeans 8.2\\java\\maven\\bin\\mvn.bat\" -Dmaven.ext.class.path=\"C:\\Program Files\\NetBeans 8.2\\java\\maven-nblib\\netbeans-eventspy.jar\" -Dfile.encoding=UTF-8 install\""/ /Scanning for projects.../ // /Building MavenTest 1.0-SNAPSHOT/ // /The POM for org.apache.maven.plugins:maven-resources-plugin:jar:2.5 is missing, no dependency information available/ // /BUILD FAILURE/ // /Total time: 0.095s/ /Finished at: Wed Oct 07 08:12:03 CEST 2020/ /Final Memory: 7M/155M/ // /Plugin org.apache.maven.plugins:maven-resources-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.5: Failure to find org.apache.maven.plugins:maven-resources-plugin:pom:2.5 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]/ /To see the full stack trace of the errors, re-run Maven with the -e switch./ /Re-run Maven using the -X switch to enable full debug logging./ /For more information about the errors and possible solutions, please read the following articles:/ /[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException/ After googling a lot, I found some suggestions about the proxy settings. However, when using /netsh winhttp show proxy /in cmd, I get that no proxy is used. Please find attached my settings.xml config. This is used on: my\path\to\maven\apache-maven-3.6.3\conf C:\Program Files\NetBeans 8.2\java\maven\conf C:\Users\Gladys Pluas\.m2 If I try to compile the project using mvn compile from command line, I get: Any idea of what I am missing? Kind Regards, - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Plugins & Confusing Versioning
Hi, On 03.10.20 11:47, Thomas Broyer wrote: Wait, you mean that you don't even follow your own rules for versions ⁉️ where milestones sit between beta and RC versions. Can you explain which rules you are referencing? We are doing that for a very long time... The point not using RC's is simply we do not see any advantage over a 3.1.2 ? we usually release a plugin lets say 3.1.0 .. .. So now someone finds a bug that means we will release 3.1.1 etc. In this case releasing an RC1 would not help here and would produce a intermediate release 3.1.1-RC1 ... which in the end finally has no difference to 3.1.1 ? So no advantage only formal steps (vote's etc.).. The part M... is from our perspective a milestone in direction to a particular set of features that has nothing to do with not stable... for example see https://maven.apache.org/surefire/maven-failsafe-plugin/ I'm for example using maven-release-plugin:3.0.0-M1 in production... You can take a look into the CI results (https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/) or the tests which are running on them: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/ The question based on that is comming up: What do you define as "unstable" ? All of those plugins are already running very long (I mean very long) in production environments ... so of course sometimes people find bugs ... As Enrico alrady mentioned ...we don't release unstable plugins... (but it drills down to the question: What is a unstable plugin?) Kind regards Karl Heinz Marbaise Le sam. 3 oct. 2020 à 09:57, Enrico Olivelli a écrit : Lukas, The general rule is that we are not releasing unstable versions so it is generally safe and good to upgrade to lasted version. The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x than it should work with Maven 3. But it was released when the reference Maven version was 2.x) The Mx suffix is only an internal version to the dev team of Maven. We mean that it is a milestone in a sense that we would have wanted to deliver a feature that is not implemented completely yet. You should care about that only of you write extensions that depend of that specific plugin. We are usually cutting versions only from the master branch and the master branch is continuously tested against a big matrix of OSs, Maven versions and Java version. I hope that helps Enrico Il Sab 3 Ott 2020, 09:30 ha scritto: Hi All & Maven Devs My name is Lukas, I'm a software engineer working at some very little company located in Switzerland (called Quatico). I wanted to let you know that the versioning that is used in (as far as I can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is very confusing . I can see on the corresponding Website (e.g. https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the these milestone releases are declared to be stable. My company did not upgrade plugin versions basically for some years now because (when just seeing the version itself) decided "Nope, its only a milestone, thus not stable". So in contrast to the maven plugin versions, the community is pretty clear about what x.y.z-M1 means: It's a pre-release for early testing purposes (e.g. see you "partner" projects explanation for it here https://en.wikipedia.org/wiki/Software_versioning ). I don't want to complain (I now know the versions are stable) but the usage of your new version would probably pike much quicker around the work if you followed the "regular" versioning scheme. Why use the Major part (3), then completely ignoring Minor (always 0) and Patch (always 0 as well) parts, to then fall back to Milestones? I cannot see an advantage in it. Hope the input might help! Cheers Lukas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions about POM
Hi, On 29.09.20 13:06, R. Diez wrote: Hi all: I am new to Maven, and I am reading now the documentation about resources: https://maven.apache.org/pom.html#Resources I have a few questions that are not covered there: 1) Do I need to specify ? If not, what is its default value? The default is simply to copy the files... 2) I just need to include a single resource file in the JAR. I guess I must nevertheless specify , and an element for that single file. Or is there a better way? No need to specify things like include/excludes etc. just put the file into src/main/resources directory ... If the resource is only needed for tests put it into src/test/resources... 3) What happens if I do not specify ? Will all other files in that be included in the JAR too? Yes... Kind regards Karl Heinz Marbaise Thanks in advance, rdiez - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3
Hi, as already mentioned on SO the behaviour can't be reproduced with the example project. Tested with Maven 3.6.0, 3.6.1, 3.6.2 and 3.6.3... Kind regards Karl Heinz Marbaise On 29.08.20 08:34, Debraj Manna wrote: Hi In one of my project I am trying to use DependencyConvergence rule with maven enforcer plugin. I am observing that if I use maven 3.6.1 then the enforcer is failing with the below error but the same has been working fine with maven 3.6.3. Can someone let me know if this expected? If yes can someone point me to the relevant jira under which this issue is fixed in maven 3.6.3. I have placed a sample project in https://github.com/debraj-manna/es-plugins where this issue can be reproduced. maven-enforcer-plugin - 3.0.0-M2 Debrajs-MacBook-Air:es-plugins debrajmanna$ ~/Downloads/apache-maven-3.6.1/bin/mvn validate [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] es-plugins [pom] [INFO] dedup [jar] [INFO] [INFO] ---< org.example:es-plugins --- [INFO] Building es-plugins 1.0-SNAPSHOT [1/2] [INFO] [ pom ]- [INFO] [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (javaversion-dependencyconvergence) @ es-plugins --- [INFO] [INFO] -< org.example:dedup -- [INFO] Building dedup 1.0-SNAPSHOT [2/2] [INFO] [ jar ]- [INFO] [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (javaversion-dependencyconvergence) @ dedup --- [WARNING] Dependency convergence error for com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths to dependency are: +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.apache.lucene:lucene-test-framework:8.5.1 +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2 [WARNING] Dependency convergence error for commons-logging:commons-logging:1.2 paths to dependency are: +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpclient:4.5.10 +-commons-logging:commons-logging:1.2 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpasyncclient:4.1.4 +-commons-logging:commons-logging:1.2 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-commons-logging:commons-logging:1.1.3 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1 +-commons-logging:commons-logging:1.1.3 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-commons-logging:commons-logging:1.1.3 [WARNING] Dependency convergence error for org.apache.httpcomponents:httpcore:4.4.12 paths to dependency are: +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpclient:4.5.10 +-org.apache.httpcomponents:httpcore:4.4.12 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpcore:4.4.12 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpasyncclient:4.1.4 +-org.apache.httpcomponents:httpcore:4.4.10 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1 +-org.apache.httpcomponents:httpcore:4.4.12 [WARNING] Dependency convergence error for org.apache.httpcomponents:httpclient:4.5.10 paths to dependency are: +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpclient:4.5.10 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1 +-org.apache.httpcomponents:httpasyncclient:4.1.4 +-org.apache.httpcomponents:httpclient:4.5.6 and +-org.example:dedup:1.0-SNAPSHOT +-org.elasticsearch.test:framework:7.7.1 +-org.elasticsearch.client:elasticsearch-rest-
Re: Resource plugin - LifecycleExecutionException - Input length = 1
Hi, On 12.08.20 21:44, Tobias wrote: Hi, a new version of the maven-resources-plugin (3.2.0) has been released recently. Trying to take advantage of this I added org.apache.maven.plugins maven-resources-plugin 3.2.0 org.apache.maven.shared maven-filtering 3.2.0 org.apache.maven.shared maven-shared-utils 3.3.3 to the pom.xml file (the version of maven-resources-plugin had not been specified before). This is the most important thing you should always define the versions of all your plugins. I don't understand why you have defined maven-shared-utils, and maven-filtering as plugins? Cause they are no plugins. And not needed by usual project... Apart from I recommend to make a directory where the filtered resources can be put into. I use the usual resources directory. A separate directory which contains the files which should not being filtered like `non-filtered-resources` that makes the configuration easier and makes very clear for users what is being done. Kind regards Karl Heinz Marbaise When running maven I see in the output that now version 3.2.0 of the resource plugin is used (before it was 2.x). However, it now results in the following error : Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:testResources (default-testResources) on project XXX: Input length = 1 See [2] below for a more detailed stack trace. Do you know what goes wrong and how this can be fixed? [Help1] says that "The concrete meaning of the exception depends on the plugin so please have a look at its documentation." I took at look at [1] but didn't find "Input length = 1" mentioned somewhere - could you maybe point me to the right direction? Unfortunately, I can't share the the full pom. I hope this information is sufficient. Best regards Tobias [1] https://maven.apache.org/plugins/maven-resources-plugin/index.html [2] 11:46:07,007 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:testResources (default-testResources) on project XXX: Input length = 1 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:testResources (default-testResources) on project XXX: Input length = 1 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:218) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:151) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:115) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.lambda$createBuildCallable$0 (MultiThreadedBuilder.java:191) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624) at java.lang.Thread.run (Thread.java:748) Caused by: org.apache.maven.plugin.MojoExecutionException: Input length = 1 at org.apache.maven.plugins.resources.ResourcesMojo.execute (ResourcesMojo.java:362) at org.apache.maven.plugins.resources.TestResourcesMojo.execute (TestResourcesMojo.java:75) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:136) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:151) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:115) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.lambda$createBuildCallable$0 (MultiThreadedBuilder.java:191) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624) at java.lang.Thread.run (Thread.java:748) Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Input length = 1 at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile (DefaultM
Re: maven-ear-plugin bundleFileName don't change the name of the war i want to bundle with the ear
Hi,
On 04.06.20 14:17, Bram Patelski wrote:
You can use the finalName property in the build-section of the Maven
pom-file:
test
. . .
This will only change the name in target directory but not the name in
the EAR file ...
Kind regards
Karl Heinz Marbaise
https://stackoverflow.com/questions/14488509/maven-how-to-rename-the-war-file-for-the-project
PGP key:
https://keys.mailvelope.com/pks/lookup?op=get=0xF31094A567CE732E
On Wed, Jun 3, 2020 at 9:44 PM Meir Yanovich
wrote:
im using the latest version of the maven-ear-plugin
i like to bundle the test.war into my ear
but the output is always :
test1-test21999.test-SNAPSHOT.war
which is always the default :
outputFileNameMapping = @{groupId}@-@{artifactId}@-@{version}@
@{dashClassifier?}@.@{extension}@
how do i force it to be:test.war
http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
">
4.0.0
com.test.id
artifact_name
1999_app
Test
ear
Test
${project.groupId}
test1
war
myapp
myapp
org.apache.maven.plugins
maven-ear-plugin
test1
Test1
test.war
test.war
/myapp
here is the log after running with -X:
please notice when it copy and ignoring the renaming
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] --- maven-ear-plugin:3.0.1:ear (default-ear) @ web-pserver-ear
---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-ear-plugin:3.0.1, parent:
sun.misc.Launcher$AppClassLoader@4e25154f]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear' with basic
configurator -->
[DEBUG] (f) earSourceDirectory = C:\foo\ear\src\main\application
[DEBUG] (f) earSourceIncludes = **
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) escapedBackslashesInFilePath = false
[DEBUG] (f) filtering = false
[DEBUG] (f) finalName =
web-pserver-ear-2020.vanilla-engage.1-SNAPSHOT
[DEBUG] (f) generatedDescriptorLocation = C:\foo\target
[DEBUG] (f) includeLibInApplicationXml = false
[DEBUG] (f) outputDirectory = C:\foo\target
[DEBUG] (f) outputFileNameMapping = @{groupId}@-@{artifactId}@
-@{version}@@{dashClassifier?}@.@{extension}@
[DEBUG] (f) project = MavenProject: foo-ear:1999.foo1-SNAPSHOT @
C:foo\ear\pom.xml
[DEBUG] (f) session =
org.apache.maven.execution.MavenSession@7569ea63
[DEBUG] (f) skinnyWars = false
[DEBUG] (f) skipClassPathModification = false
[DEBUG] (f) tempFolder =C:\foo\target
[DEBUG] (f) useJvmChmod = true
[DEBUG] (f) version = 7
[DEBUG] (f) workDirectory = C:\foo\target\foo-SNAPSHOT
[DEBUG] -- end configuration --
[DEBUG] Resolving artifact type mappings ...
[DEBUG] Initializing JBoss configuration if necessary ...
[DEBUG] Initializing ear execution context
[DEBUG] Resolving ear modules ...
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] Copy ear sources to C:\foo\target\foo-SNAPSHOT
[DEBUG] Jar archiver implementation
[org.codehaus.plexus.archiver.jar.JarArchiver]
[DEBUG] Excluding [] from the generated EAR.
[DEBUG] Including [**] in the generated EAR.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: bad links
Hi Robert, On 22.05.20 19:21, Roger Pack wrote: As a note all the url's under "usages" here: https://maven.apache.org/plugins/maven-deploy-plugin/index.html are 404's... Cheers! Unfortunately I can not acknowledge this? working fine from my site. Yes they are shown as "not secure" cause there are some http links in there. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven jdk Error
Hi, sorry my first message I pressed the button wrongly. Can you please upgrade the surefire version cause you are using a very old one... Also if you want to go JDK 14 I recommend to upgrade other plugins as well. Kind regards Karl Heinz Marbaise On 14.05.20 22:43, Oguz wrote: Hi, I got this error when I changed jdk to 14 (PreviewFailed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project Cookies: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? Here is my output when I deployed /Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home/bin/java -Dmaven.multiModuleProjectDirectory=/Users/oguzkeremyildiz/Dropbox/Cookies "-Dmaven.home=/Applications/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3" "-Dclassworlds.conf=/Applications/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3/bin/m2.conf" "-Dmaven.ext.class.path=/Applications/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven-event-listener.jar" "-javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=58562:/Applications/IntelliJ IDEA.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Applications/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3/boot/plexus-classworlds.license:/Applications/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3/boot/plexus-classworlds-2.6.0.jar" org.codehaus.classworlds.Launcher -Didea.version2020.1.1 deploy [INFO] Scanning for projects... [INFO] [INFO] < io.github.oguzkeremyildiz:Cookies - [INFO] Building Cookies 1.2.4 [INFO] ---[ jar ] [INFO] [INFO] — maven-resources-plugin:2.6:resources (default-resources) @ Cookies — [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 0 resource [INFO] [INFO] — maven-compiler-plugin:3.6.1:compile (default-compile) @ Cookies — [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @ Cookies — [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /Users/oguzkeremyildiz/Dropbox/Cookies/src/test/resources [INFO] [INFO] — maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @ Cookies — [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] — maven-surefire-plugin:2.12.4:test (default-test) @ Cookies — [INFO] Surefire report directory: /Users/oguzkeremyildiz/Dropbox/Cookies/target/surefire-reports --- T E S T S --- org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.UnsupportedClassVersionError: Preview features are not enabled for Test (class file version 58.65535). Try running with '--enable-preview' at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:719) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:642) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.apache.maven.surefire.util.DefaultScanResult.loadClass(DefaultScanResult.java:131) at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:95) at org.apache.maven.surefire.junit
Re: Maven jdk Error
-- [INFO] BUILD FAILURE [INFO] [INFO] Total time: 4.223 s [INFO] Finished at: 2020-05-14T21:33:21+03:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project Cookies: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException Thank you. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen https://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The POM for org.apache.maven.plugins:maven-resources-plugin:jar:2.6 is missing
Hi, Does your repository manager correctly contact central repository? Does it do that via https instead http? Kind regards Karl Heinz Marbaise On 10.05.20 04:14, Malvika Mistry wrote: Hi , How are you? Hope all is well with you !! I am try to upload artifacts from remote repository to nexus proxy repository using attached settings.xml file and pom.xml file. getting below error. if possible, could you please help me to resolve this issue? - maven error - -- C:\nexus3\test_project_nexus_proxy>mvn package [INFO] Scanning for projects... [INFO] [INFO] --< com.example:nexus-proxy >--- [INFO] Building nexus-proxy 1.0-SNAPSHOT [INFO] [ jar ]- [WARNING] The POM for org.apache.maven.plugins:maven-resources-plugin:jar:2.6 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.205 s [INFO] Finished at: 2020-05-09T20:11:04-06:00 [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failure to find org.apache.maven.plugins:maven-resources-plugin:jar:2.6 in http://localhost:8081/repository/mulesoft was cached in the local repository, resolution will not be reattempted until the update interval of mulesoft has elapsed or updates are forced -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException -- Thank you in Advance for your help !! Thank you , Malvika Mistry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen https://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem building maven-filtering 3.1.1: Error generating metadata
Hi, On 26.04.20 15:13, Tobias wrote: Hi, I used svn checkout https://svn.apache.org/repos/asf/maven/shared/tags/maven-filtering-3.1.1 maven-filtering This is the wrong location we have moved to Git a long time ago.. correct location now: https://github.com/apache/maven-filtering It looks like we need a new releasecause the web site points to the old location...but will only being updated with a new release... Kind regards Karl Heinz Marbaise to access the source code and ran mvn install. I got the following error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project maven-filtering: Compilation failure: Compilation failure: [ERROR] Source option 6 is no longer supported. Use 7 or later. [ERROR] Target option 6 is no longer supported. Use 7 or later. and therefore added org.apache.maven.plugins maven-compiler-plugin 13 13 to the pom.xml. Running mvn install again now yields the following error: [INFO] --- plexus-component-metadata:1.6:generate-metadata (default) @ maven-filtering --- [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.050 s [INFO] Finished at: 2020-04-26T15:08:48+02:00 [INFO] [ERROR] Failed to execute goal org.codehaus.plexus:plexus-component-metadata:1.6:generate-metadata (default) on project maven-filtering: Error generating metadata: : Failed to extract descriptors: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.plexus:plexus-component-metadata:1.6:generate-metadata (default) on project maven-filtering: Error generating metadata: at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) [...] The full log can be found here: https://pastebin.com/JKHML3Lv Do you know how to fix this? Best regards Tobias - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor module dependency tree resolution
Hi,
On 24.04.20 14:47, Christian Domsch wrote:
Hi,
I would like to be able to get access to the reactor module tree. I have a
specific plugin that is executed for each reactor module and it needs to
check, if for a predefined set of modules in the reactor (in our case war
archives that contain a subset of all modules) see if the current module is
actually contained in that war (directly or via transitive dependencies).
Can you explain more in detail what the use case is? If an artifact is
part of a war? Why would like to check that? Can be seen in the war module?
What I tried so far, but isn't working, is using the aether dependency
resolution mechanism. The reason why it isn't working is fairly obvious:
checking the transitive dependencies of these war modules, aether tries to
download all artifacts first and fails because they haven't been build by
the reactor, yet, and thus are unknown. This makes a lot of sense, but also
means this way won't help me.
Now, the reactor itself has to be able to calculate those dependencies, as
it will calculate a certain order of building the modules, depending on how
those modules depend on each other. This (what I will call) reactor module
tree is exactly the information I need.
The reactor is the part which contains the parents/modules and order of
building the modules...this can be accessed via:
@Parameter(defaultValue = "${session}", required = true, readonly = true)
MavenSession session;
By using the above session you could:
* session.getProjectDependencyGraph().getSortedProjects();
The sortedProjects is exactly the order of the reactor ..
If you like to know the dependencies you have to go via dependency
resolution in your plugin:
Something like:
@Mojo(name = "xxx", defaultPhase = LifecyclePhase.PRE_INTEGRATION_TEST,
requiresDependencyResolution = ResolutionScope.RUNTIME, threadSafe
= true)
The important part is:
requiresDependencyResolution = ResolutionScope.RUNTIME
which you now gives you the option to access the dependencies:
project.getArtifacts();
where mvnProject:
@Parameter(defaultValue = "${project}", required = true, readonly = true)
private MavenProject project;
Kind regards
Karl Heinz Marbaise
Is there a way to access this information from a plugin? ${reactorProjects}
does not tell me that. Or am I missing sth very obvious?
Thx,
Christian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: error netbeans 11.3
Hi, On 22.04.20 04:27, carlos serrano wrote: Hi, I have a problem I do not know how to resolve, I want to create web proyect whit maven. this is the error: Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/2.4/maven-archetype-plugin-2.4.pom BUILD FAILURE Total time: 1.039 s Finished at: 2020-04-21T20:20:24-06:00 Final Memory: 7M/152M Plugin org.apache.maven.plugins:maven-archetype-plugin:2.4 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-archetype-plugin:jar:2.4: Could not transfer artifact org.apache.maven.plugins:maven-archetype-plugin:pom:2.4 from/to central (https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version -> [Help 1] To see the full stack trace of the errors, re-run Maven with the -e switch. Re-run Maven using the -X switch to enable full debug logging. Based on the error message my assumption is that you are running on JDK 7...which means you have to configure TLSv1.2 otherwise you can't download any dependencies...I strongly recomment to use JDK8+ If you have to stuck to JDK7 you have to add to your command line: -Dhttps.protocols=TLSv1.2 Kind regards Karl Heinz Marbaise For more information about the errors and possible solutions, please read the following articles: [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException Carlos Serrano T??cnico en Sistemas de la Computaci??n - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NullPointerException in maven-jlink-plugin
Hi, On 16.03.20 15:50, Thorsten Heit wrote: Hello, I tried to use maven-jlink-plugin to create a modular Java runtime image for an internal application. I've followed the description in the docs, but finally got a NullPointeException during execution of "mvn package"; the same error as in MJLINK-41. Do you have an example project which shows the behaviour? Version 3.0.0-alpha-1 was release september 2017, and since then there were a couple of changes in the project. Is a new release planned / in the making? I hope I will time within the next weeks to get another release for it..yeah it's long time ago... Kind regards Karl Heinz Marbaise Or is there a possible workaround / fix for the NPE? Regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is key 0x0CDE80149711EB46DFF17AE421A24B3F8B0F594A for Karl Heinz Marbaise trusted?
Hi, On 19.02.20 17:04, Ward, Evan wrote: Hi, I have been attempting to verify the signatures on maven plugins using the instructions on the downloads page, e.g. [1]. Several plugins have been signed by the key 0x0CDE80149711EB46DFF17AE421A24B3F8B0F594A which nominally belongs to Karl Heinz Marbaise, but this key is not present in the KEYS file at [2]. Does this key truly belong to an Apache Committer? Yes it does. https://maven.apache.org/team.html#khmarbaise If so please add it to the keys file. Karl has other keys in the KEYS file - is there a reason this specific key is not trusted? What do you mean exactly by "not trusted" ? ...You are checking via gpg --verify ? Kind regards Karl Heinz Marbaise This issue applies to at least the install plugin version 2.5.2 and the deploy plugin version 2.8.2. Best Regards, Evan [1] https://maven.apache.org/plugins/maven-deploy-plugin/download.cgi [2] https://www.apache.org/dist/maven/KEYS - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
Hi, On 01.02.20 16:08, Anton Vodonosov wrote: Hello. In order to speed up the build of a big multi-module project, I'd like to reuse the artifacts of modules that haven't changed. Manual versioning is tedious and error-prone. Can you explain more in detail what you exactly mean and what kind of problem you have best would be having an example project which shows the issues... Kind regards Karl Heinz Marbaise Is it possible to automatically assign versions so that versions only change if module sources or dependencies change? In result, only those modules will be recompiled and retested, and all other modules will be reused from artifact repository. For example, this could be done if versions are computed as hash-of( hash-of(module sources) + hashes of all dependencies). In this approach, every change in code will modify such hash-based version of all dependent modules automatically. This would be similar to Nix package manager. How such things (has based or to do that in maven? Best regards, - Anton - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: warning default invalid module name Errors Replicated
Hi,
On 05.01.20 22:54, zahid wrote:
Thank you. These files has been generated by NETBEANS IDE.
I have my doubts that plugins generated as dependencies by Netbeans if
so this is simply a bug
*Netbeans uses a very old version Apache Maven 3.3.9 and these warnings
do not appear.
This means you don't have defined all your used plugins correctly within
your pom.xml (pluginManagement as you already done with
maven-compiler-plugin) with their appropriate versions.
Older plugins versions didn't even know something about Java Module
system (JPMS) names etc. (This is what you get with Maven 3.3.9..) That
looks like that those warnings have gone but they are still there
because older plugins didn't recogzined them...
*
*I still get these warnings with the revised pom.xml
*
kub18@UB18:~/javafx/helloapp$ mvn javafx:run
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$1
(file:/usr/share/maven/lib/guice.jar) to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Scanning for projects...
[INFO]
[INFO] --< co.uk.backbutton:HelloFX
>--
[INFO] Building HelloFX 1.0-SNAPSHOT
[INFO] [ jar
]-
[INFO]
[INFO] --- javafx-maven-plugin:0.0.3:run (default-cli) @ HelloFX ---
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 3.934 s
[INFO] Finished at: 2020-01-05T21:51:22Z
[INFO]
This is something completely different.
If the pom is the one your are using than you should use Maven 3.6.3 and
correctly check your environment if it's pointing to the correct Maven
installation... (Do you use M2_HOME or MAVEN_HOME environment variables?
Only add the bin directory of the Maven installation to the PATH nothing
else).
I suppose /usr/share/maven/lib/guice.jar) is from your Maven
installation on your system?
Kind regards
Karl Heinz Marbaise
*REVISED pom.xml*
kub18@UB18:~/javafx/helloapp$ cat pom.xml
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
co.uk.backbutton
HelloFX
1.0-SNAPSHOT
UTF-8
UTF-8
11
11
org.openjfx
javafx-controls
14-ea+6
org.openjfx
javafx-fxml
13
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
${maven.compiler.source}
org.openjfx
javafx-maven-plugin
0.0.3
HelloFX
On 05/01/2020 20:53, Karl Heinz Marbaise wrote:
Hi,
On 05.01.20 21:31, zahid wrote:
mvn -version
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 11.0.5, vendor: Private Build, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family:
"unix"
*ls -l
*total 24
-rw-rw-r-- 1 kub18 kub18 4770 Jan 3 15:02 nbactions.xml
-rw-rw-r-- 1 kub18 kub18 455 Jan 1 21:58 pom_old.xml
-rwxrwxrwx 1 kub18 kub18 2520 Jan 3 15:17 pom.xml
drwxrwxr-x 3 kub18 kub18 4096 Jan 1 21:45 src
drwxrwxr-x 7 kub18 kub18 4096 Jan 5 09:24 target
*
*
*consol output**
*
kub18@UB18:~/javafx/helloapp$ mvn javafx:run
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$1
(file:/usr/share/maven/lib/guice.jar) to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future
release
[INFO] Scanning for projects...
[INFO]
[INFO] --< co.uk.backbutton:HelloFX
>-
Re: warning default invalid module name Errors Replicated
Hi, On 05.01.20 21:31, zahid wrote: mvn -version Apache Maven 3.6.0 Maven home: /usr/share/maven Java version: 11.0.5, vendor: Private Build, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family: "unix" *ls -l *total 24 -rw-rw-r-- 1 kub18 kub18 4770 Jan 3 15:02 nbactions.xml -rw-rw-r-- 1 kub18 kub18 455 Jan 1 21:58 pom_old.xml -rwxrwxrwx 1 kub18 kub18 2520 Jan 3 15:17 pom.xml drwxrwxr-x 3 kub18 kub18 4096 Jan 1 21:45 src drwxrwxr-x 7 kub18 kub18 4096 Jan 5 09:24 target * * *consol output** * kub18@UB18:~/javafx/helloapp$ mvn javafx:run WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release [INFO] Scanning for projects... [INFO] [INFO] --< co.uk.backbutton:HelloFX >-- [INFO] Building HelloFX 1.0-SNAPSHOT [INFO] [ jar ]- [INFO] [INFO] --- javafx-maven-plugin:0.0.3:run (default-cli) @ HelloFX --- [WARNING] Can't extract module name from plexus-container-default-1.0-alpha-6.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier [WARNING] Can't extract module name from plexus-container-default-1.0-alpha-30.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier [WARNING] Some dependencies encountered issues while attempting to be resolved as modules and will not be included in the classpath; you can change this behavior via the 'includePathExceptionsInClasspath' configuration parameter. [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 15.673 s [INFO] Finished at: 2020-01-05T20:20:17Z [INFO] * * *kub18@UB18:~/javafx/helloapp$ cat pom.xml* http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> 4.0.0 co.uk.backbutton HelloFX 1.0-SNAPSHOT UTF-8 UTF-8 11 11 org.openjfx javafx-controls 14-ea+6 org.openjfx javafx-fxml 13 plexus plexus-container-default 1.0-alpha-6 org.apache.maven.plugins maven-source-plugin 3.2.1 org.apache.maven.plugins maven-javadoc-plugin 3.1.1 org.apache.maven.plugins maven-deploy-plugin 3.0.0-M1 org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 org.openjfx javafx-maven-plugin 0.0.3 HelloFX Never use maven plugins as dependencies also do not use plexus-container-default as a dependency. So remove the dependency definition: maven-source-plugin maven-javadoc-plugin maven-deploy-plugin also remove the dependency: plexus-container-default from your pom file... If you want to define your plugins in your pom which is a good idea you should use pluginManagement instead ... This will remove the warnings you have gotten The issue had been the wrong dependencies.. Kind regards Karl Heinz Marbaise *kub18@UB18:~/javafx/helloapp$ cat nbactions.xml * rebuild * clean install javafx:run build * install javafx:run build-with-dependencies also-make * clean install javafx:run run
Re: warning default invalid module name
Hi, sorry but you seemed not to read my questions: without a full pom and it's dependencies it's impossible to see where the warning is comming from cause it looked like there is a dependency (plexus--...) extreme old one which does not has a module information and can't be used as it...that means there is a dependency somewhere in your project? or maybe in the used plugin javafx ? Furthermore the output: Java version: 11.0.5, vendor: Private Build is very interesting..Have you build your own JDK ? ... As I already mentioned. It would be helpful to have a full example project as GitHub project ... Kind regards Karl Heinz Marbaise On 05.01.20 19:08, zahid wrote: *Running in NETBEANS IDE * *mvn error message* "you can change this behavior via the 'includePathExceptionsInClasspath' configuration parameter." .. *I would like to see an example syntax setting in pom.xml file of ** * *'includePathExceptionsInClasspath' ** * *then I can fix it next time this happens.* * * > Also do not change on the top menu, > Which menu? In Maven there is no menu? ... *NETBEANS IDE menu at the top drop down list below options Run Debug.** * * * ** The error was in NETBEANS IDE when running an archetype application. NETBEANS IDE comes with mvn version Apache Maven 3.3.9 As you can see below I reverted back to system installation of mvn 3.3.9 same as NETBEANS IDE. I do not now get warning when creating command line archetypes. *Console output of mvn -version ** * Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 11.0.5, vendor: Private Build Java home: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family: "unix" *NETBEANS ABOUT DIALOGUE* Product Version: Apache NetBeans IDE 11.2 Java: 11.0.5; OpenJDK 64-Bit Server VM 11.0.5+10-post-Ubuntu-0ubuntu1.118.04 Runtime: OpenJDK Runtime Environment 11.0.5+10-post-Ubuntu-0ubuntu1.118.04 System: Linux version 5.0.0-37-generic running on amd64; UTF-8; en_GB (nb) User directory: /home/kub18/.netbeans/11.2 Cache directory: /home/kub18/.cache/netbeans/11.2 openjdk version "11.0.5" 2019-10-15 *KUBUNTU KInfocentre** * KDE plasma version 5.12.9 Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic On 05/01/2020 17:26, Karl Heinz Marbaise wrote: On 05.01.20 18:06, zahid wrote: I can't honestly remember which application I was having this problem with. Unfortunately this means I can't help here.. BUT all my applications are running fine without errors or warnings. without a concrete example it's more or less impossible to help ...I don't know what versions of Maven you exactly using, which dependencies, which plugin versions, which JDK version etc. etc... I found most of these kind of *GOTCHAS* is to reset the mvn goals to "clean install". That is to say go to project -> properties -> right click -> actions > scroll through resetting the execute goals. Which project properties? Running in IDE? Sounds like you don't run on plain command line? Have you checked so?... Also do not change on the top menu, Which menu? In Maven there is no menu? ... Kind regards Karl Heinz Marbaise that will also cause different kind of warnings or errors. You can change it to release-profile see what happens then change it back again :) Also some times you have errors and warnings when you run by selecting the double arrows. Then you have to "run file" by being in the java class where the "psvm" is and right click -> "run file" . Then the double arrow will run correctly after that. On 05/01/2020 15:50, Karl Heinz Marbaise wrote: Hi, On 03.01.20 18:57, zahid wrote: what is the solution to solve this warning. running form NETBEANS IDE. module name from plexus-container-default-1.0-alpha-6.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Can't extract module name from plexus-container-default-1.0-alpha-30.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Some dependencies encountered issues while attempting to be resolved as modules and will not be included in the classpath; you can change this behavior via the 'includePathExceptionsInClasspath' configuration parameter. Do you have a full working example of this? Best would be a GitHub project? Kind regards Karl Heinz Marbaise - b/r Zahid -- www.backbutton.co.uk ¯\_(ツ)_/¯ Marriage between loose and tight coupling = healthy applications - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: warning default invalid module name
On 05.01.20 18:06, zahid wrote: I can't honestly remember which application I was having this problem with. Unfortunately this means I can't help here.. BUT all my applications are running fine without errors or warnings. without a concrete example it's more or less impossible to help ...I don't know what versions of Maven you exactly using, which dependencies, which plugin versions, which JDK version etc. etc... I found most of these kind of *GOTCHAS* is to reset the mvn goals to "clean install". That is to say go to project -> properties -> right click -> actions > scroll through resetting the execute goals. Which project properties? Running in IDE? Sounds like you don't run on plain command line? Have you checked so?... Also do not change on the top menu, Which menu? In Maven there is no menu? ... Kind regards Karl Heinz Marbaise that will also cause different kind of warnings or errors. You can change it to release-profile see what happens then change it back again :) Also some times you have errors and warnings when you run by selecting the double arrows. Then you have to "run file" by being in the java class where the "psvm" is and right click -> "run file" . Then the double arrow will run correctly after that. On 05/01/2020 15:50, Karl Heinz Marbaise wrote: Hi, On 03.01.20 18:57, zahid wrote: what is the solution to solve this warning. running form NETBEANS IDE. module name from plexus-container-default-1.0-alpha-6.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Can't extract module name from plexus-container-default-1.0-alpha-30.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Some dependencies encountered issues while attempting to be resolved as modules and will not be included in the classpath; you can change this behavior via the 'includePathExceptionsInClasspath' configuration parameter. Do you have a full working example of this? Best would be a GitHub project? Kind regards Karl Heinz Marbaise - b/r Zahid - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: warning default invalid module name
Hi, On 03.01.20 18:57, zahid wrote: what is the solution to solve this warning. running form NETBEANS IDE. module name from plexus-container-default-1.0-alpha-6.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Can't extract module name from plexus-container-default-1.0-alpha-30.jar: plexus.container.default: Invalid module name: 'default' is not a Java identifier Some dependencies encountered issues while attempting to be resolved as modules and will not be included in the classpath; you can change this behavior via the 'includePathExceptionsInClasspath' configuration parameter. Do you have a full working example of this? Best would be a GitHub project? Kind regards Karl Heinz Marbaise - b/r Zahid - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to avoid forking in a maven build?
Hi, based on what I can identify in your pom files/output is that in your currenty configuration the maven-javadoc-plugin is configured to use the goal: aggregate[1] which is a goal which forkes the lifecycle. There is an equivalent "aggregate-no-fork"[2] which could be used instead... The question is also why running javadoc everytime? Apart from that you have configured the maven-source-plugin with the goal "jar" which also forkes the lifecycle[3] this could be replaced by using the "jar-no-fork" goal[4]. Furthermore your configuration can be simplyfied by using the junit-bom instead of each dependency separately to import the dependencies for junit-jupiter ... The question is: Why have you bound the maven-resources-plugin to validate life cycle phase? One thing: Why do you have configured wagon-ftp as extension? Kind regards Karl Heinz Marbaise [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html [2]: https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-no-fork-mojo.html [3]: https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html [4]: https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html On 31.12.19 16:04, Steinar Bang wrote: This project https://github.com/steinarb/authservice has a lot of messages like this in the build output: [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [INFO] Forking Authentication webapp 1.8.0-SNAPSHOT [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [INFO] [INFO] --- maven-resources-plugin:3.1.0:resources (filter-resources) @ authservice --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [INFO] Forking Authentication webapp definitions bundle 1.8.0-SNAPSHOT [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [INFO] [INFO] --- maven-resources-plugin:3.1.0:resources (filter-resources) @ authservice.definitions --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/sb/workspaces/ws03/authservice/authservice.definitions/src/main/filtered-resources [INFO] [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ authservice.definitions --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/sb/workspaces/ws03/authservice/authservice.definitions/src/main/resources ... A lot of the forking messages to be repeated, so I worry that it does some operations (e.g. the npm build of the frontend) way more times than it has to (ie. only once). Is the forking something that makes the build take longer than it has to? Or is it harmless and nothing worth spending time to fix? I have tried to figure out who the culprit is. Maybe there are more than one culprit...? I thought maybe my use of the maven-resources-plugin in the parent was the cause of the forking. So I moved the build of a master karaf feature repository out of the parent POM and into a module. But that only got rid of the first forking in the quoted text abote. The full output from "mvn clean install" can be seen at: https://gist.github.com/steinarb/169d179abec47f50d3aa5574ad8d7585 Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: repo.maven.apache.org returning 403 forbidden when running maven
On 30.12.19 15:04, Henke, Zachary wrote: Hello, My name is Zach Henke and I work at Verisign. I am currently receiving ERROR 403: Forbidden when attempting to access http://repo.maven.apache.org/maven2/ via linux server. On that same server, I am able to access the maven website (http://maven.apache.org/) which indicates public internet access. I am able to reach http://repo.maven.apache.org/maven2/ in browser from my local machine on a different IP/network than the linux server. This indicators implying more that you have to have a proxy access to the central repository http://repo.maven.org/maven2/ which seemed to be not given on the Linux machineI suppose you have a proxy/firewall issue... Furthermore the questions is: Does your company has a repository manager which is intended to download artifacts from central repository? Accesses via browser are usually going through a proxy with particular configurations in browsers...but the plain networks is something different... Can you simply ping: ping repo.maven.apache.org ? Can you do a: nslookup repo.maven.apache.org ? Kind regards Karl Heinz Marbaise These points make me think there is a blacklist of IPs in front of the maven repo causing the 403 Forbidden from the linux server. Anyone know how to confirm my IP isn’t in a blacklist? Any other suggestions to avoid the repo 403 issue would be great. Can you give all details of the error message...in particular on command line.. Kind regards Karl Heinz Marbaise Thanks, Zach - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Tests not running on Maven
Hi,
first you have to use junit-jupiter-engine[1] instead of api apart from
that you won't be able to get that running cause JUnit Jupiter requires
JDK8+ (see [2]).
furthermore dependencies to junit provider is simply not needed cause
this is automatically done by maven-surefire/maven-failsafe-plugin...
Kind regards
Karl Heinz Marbaise
[1]:
http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
[2]:
https://junit.org/junit5/docs/current/user-guide/#overview-java-versions
On 09.12.19 13:31, Jeronimo wrote:
Hi,
I am using Maven 3.6
$ mvn -version
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 11.0.4, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family: "unix"
My pom.xml seems like this:
$ cat pom.xml
http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
br.edu.ifrs
totalinventory
1.0-SNAPSHOT
war
totalinventory Maven Webapp
http://www.poa.ifrs.edu.br
UTF-8
1.7
1.7
junit
junit
4.11
test
org.junit.jupiter
junit-jupiter-api
5.5.2
test
javax.persistence
javax.persistence-api
2.2
javax.ejb
ejb-api
3.0
provided
javax.ws.rs
javax.ws.rs-api
2.1.1
javax.annotation
javax.annotation-api
1.3.2
org.apache.maven.surefire
surefire-junit47
2.22.1
totalinventory
maven-clean-plugin
3.1.0
maven-resources-plugin
3.0.2
maven-compiler-plugin
3.8.0
maven-surefire-plugin
2.22.1
org.apache.maven.plugins
maven-failsafe-plugin
2.22.1
maven-war-plugin
3.2.2
maven-install-plugin
2.5.2
maven-deploy-plugin
2.8.2
When trying to execute JUnit testes:
$ mvn clean test
[INFO] Scanning for projects...
[INFO]
[INFO] -< br.edu.ifrs:totalinventory
-
[INFO] Building totalinventory Maven Webapp 1.0-SNAPSHOT
[INFO] [ war
]-
[INFO]
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ totalinventory
---
[INFO] Deleting /home/jeronimo/Documents/maven-testes/totalinventory/target
[INFO]
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @
totalinventory ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
totalinventory ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 5 source files to
/home/jeronimo/Documents/maven-testes/totalinventory/target/classes
[INFO]
[INFO] --- maven-resources-plugin:3.0.2:testResources
(default-testResources) @ totalinventory ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/jeronimo/Documents/maven-testes/totalinventory/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
totalinventory ---
[INFO] Changes detected - recompiling the module!
[INFO] *Compiling 1 source file *to
/home/jeronimo/Documents/maven-testes/totalinventory/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @
totalinventory ---
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO]
[INFO] Results:
[INFO]
[INFO] *Tests run: 0,* Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 2.525 s
[INFO] Finished at: 2019-12-09T10:24:37-02:00
[INFO]
The phases seems to compile one test class but don't run any.
My Test class is on ./src/test/java
$ cat src/test/java/FabricanteTest.java
package br.edu.ifrs.test;
import static org.junit.jupiter.api.Assertions.assertEquals;
import br.edu.ifrs.model.Fabricante;
import org.junit.jupiter.api.Test;
public class FabricanteTest {
@Test
public void testGetName() {
Fabricante fabricante = n
Re: 2 issues with maven version range
Hi John, On 24.11.19 20:46, John Patrick wrote: i'm trying to start using maven version range more but having issues with things like guava and also it not excluding version i believe should be excluded. 1) i don't think this is possible but it might be, take a look a google guava, it has a jre and a android version. using maven version range how can i say any newer jre version, or any newer android version? https://search.maven.org/artifact/com.google.guava/guava something like [25,) but only the jre maybe [25*-jre,) Let us start with Guava. The issue with Guava is that they made the `-jre` part of the version number which is from a Maven point of view simply wrong. This should have been done via a clas^sifier. Because -jre, -android are specialized packages which are valid for only particular environments. From the documentation[1]: ``` The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. Another common use case for classifiers is to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files. ``` So an android package could simply be namind by using: g: com.google.guava a: guava v: 27.1 classifier: jre etc. classifier: android Unfortunately they had decided to put this into the version which causes the issues. This in result means you can not select the version correctly. [1]: https://maven.apache.org/pom.html 2) i'm trying to use the version range "[4.7.0,5) "for io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose -Dincludes=io.cucumber https://search.maven.org/artifact/io.cucumber/cucumber-core what do i need to change "[4.7.0,5)" to do it excludes anything starting 5? So next checking for version comparison: This can be checked via command line: (from the Apache Maven installation): $ java -jar maven-artifact-3.6.2.jar 4.7.0 5 Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 4.7.0 == 4.7 4.7.0 < 5 2. 5 == 5 This will show the obvious as you already know. Now let us check something different: lib$ java -jar maven-artifact-3.6.2.jar 5.0.0-alpha 5.0.0 Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 5.0.0-alpha == 5-alpha 5.0.0-alpha < 5.0.0 2. 5.0.0 == 5 So based on that your version range: [4,5) will include everything which starts with "5.0.0", "5.0", or "5" this will also include "-RC??", "-alpha" and "-SNAPSHOT" because they are less than "5", "5.0" or "5.0.0" etc. Furthermore I would say "5" < "5-SNAPSHOT" is from a Maven point of view is very intuitve cause the "SNAPSHOT" is on the timeline before releasing final release "5". (This is also true for "5.0.0" < "5.0.0-SNAPSHOT"). To prevent having "RC"'s etc. in your range the only way is to use "[4,4.999.9)" (Yes it looks strange.) for given example cucumber-core... Also see the discussion on the users list: https://lists.apache.org/thread.html/888730bd2479a9ae247e12b1f7ae6a85285feb395bdfe99c2e435a46@ Unfortunately I agree that from a user point of view this should be done better. This could be changed for Maven 4.X but never for Maven 3.X. In the end my opinion (and experience) is simply not to use version ranges at all cause that could break your build without knowing why ..(I've seen that several times already)... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven compiler plugin - test compiler arguments with double dash
Hi, this is documented on the documentation page[1] which can be achieved by using the following: [...] [...] org.apache.maven.plugins maven-compiler-plugin 3.8.1 --enable-preview wished supplemental option [...] [...] Kind regards Karl Heinz Marbaise [1]: https://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html On 09.10.19 14:23, Lovro Pandzic wrote: Hello, I'd like to pass -parameters and enable-preview arguments to the test compiler but I can't figure out how, the closest I got is: How can I pass two arguments to the test compiler where one of them requires double dash? Best Regards, [https://cf-cdn.infobip.com/email_signature/Infobip_logo_vertical_signature.png]<https://www.infobip.com?utm_medium=email_source=signature_campaign=reach%20%7C%20email%20%7C%20global%20%7C%20signature_term=all%20%7C%20recepient%20%7C%20mwc19_content=signature> Lovro Pandzic Division Lead, Enterprise Zagreb lovro.pand...@infobip.com<mailto:lovro.pand...@infobip.com> [https://cf-cdn.infobip.com/email_signature/line.png] Office: Zadarska 80, 6th floor, 1 Zagreb, Croatia Mobile: +385921001403 [https://cf-cdn.infobip.com/email_signature/roccovendor2019.png]<https://www.infobip.com/en/media/press-releases/rocco-awards-2019-infobip-rated-1-a2p-sms-messaging-vendor-by-enterprises-m> [https://cf-cdn.infobip.com/email_signature/spacer.png] [https://cf-cdn.infobip.com/email_signature/Facebook.png]<https://www.facebook.com/infobip> [https://cf-cdn.infobip.com/email_signature/Linkedin.png] <https://www.linkedin.com/company/infobip> [https://cf-cdn.infobip.com/email_signature/Twitter.png] <https://twitter.com/Infobip> [https://cf-cdn.infobip.com/email_signature/Instagram.png] <https://www.instagram.com/infobip/> [https://cf-cdn.infobip.com/email_signature/Youtube.png] <https://www.youtube.com/channel/UCUPSTy53VecI5GIir3J3ZbQ> www.infobip.com<https://www.infobip.com?utm_medium=email_source=signature_campaign=reach%20%7C%20email%20%7C%20global%20%7C%20signature_term=all%20%7C%20recepient%20%7C%20mwc19_content=signature> GSMA Associate Member / Mobey Forum Member This message is private and confidential. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Infobip d.o.o. If you have received this message in error, please notify us immediately via email to customer.supp...@infobip.com<mailto:customer.supp...@infobip.com> or telephone +442032864231. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Proposal: maven release lifecycle
Hi, first thanks... I have several question regarding your blog post ... Apart from beeing not accurate in some part I miss one very important thing: What is the real problem when doing a release via release plugin etc. which works well (I haven't said that it could be improved)... I want to know what the pain points are ? Kind regards Karl Heinz Marbaise On 03.10.19 15:38, Marco Schulz wrote: Hello Maven Dev & Community Sine a long time I thought, it would be cool to have a well defined process to prepare a release of an artifact and deploy it on mvn central. Now I got a bit time to formulate a short proposal of my idea. I published a description of my thought on my bolg: https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/ A poll is also created, may to see what other people think about it. Please feel free to leave also comments, every feedback is welcome. warm regards & thanks to the maven dev team for the great job they do. .marco (@ElmarDott) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-assembly-plugin after plexus-archiver 4.2.0 is released; implement user/group override for archives
Hi, On 28.09.19 19:49, Václav Haisman wrote: Hi. I have noticed that Plexus Archiver 4.2.0 in SNAPSHOT version has grown methods like `org.codehaus.plexus.archiver.Archiver#setOverrideUid`. It seems that after it is released it should be possible implement Maven Assembly Plugin extension that would allow to use these methods to set, e.g., TAR archive owner/group entries to some reasonable value even on Windows. Is anyone already working on this? Does exist an JIRA issue for that? If not why not creating one? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven OSGi
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 23.08.19 15:17, Robert Scholte wrote: Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-osgi/ describes the main purpose in one line: Library for Maven-OSGi integration. There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. It is unclear to me if this library is still used. The library is based on just 3 files: interface, default implementation and dedicated exception. Either the library is complete or never used anymore. In both cases I see no real reason to maintain it. I therefore propose that we retire the maven-osgi library. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Repository Builder
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 07.08.19 21:13, Robert Scholte wrote: Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-repository-builder/ describes the main purpose in one line: Maven shared components. Okay, that's actually quite bad. Based on https://mvnrepository.com/artifact/org.apache.maven.shared/maven-repository-builder the library isn't used a lot. Both maven-assembly-plugin and maven-plugin-testing-tools don't use this library anymore. The sourcecode looks a bit like it has the same purpose as dependency:copy-dependencies. I therefore propose that we retire the maven-repository-builder. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Downloader
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 07.06.19 15:32, Robert Scholte wrote: Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-downloader/ [https://maven.apache.org/shared/maven-downloader/] describes the main purpose in one line: Provide a super simple interface for downloading a single artifact. Well, right now the preferred library to do so is either maven-resolver or maven-artifact-transfer. There have been only 2 releases, the last one was in December 2006. I therefore propose that we retire the maven-downloader. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Ant Plugin
Hi, +100 from me... Kind regard Karl Heinz Marbaise On 28.05.19 20:54, Robert Scholte wrote: Hi, The Apache Maven project consist of about 100 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. The goal of the Apache Maven Ant Plugin it to generate Ant build files based on a pom.xml and was released for the last time in December 2014. Due to the different ways that Ant and Maven work I don't think it makes sense anymore to maintain a plugin to transform Maven files to Ant. See https://maven.apache.org/plugins/maven-ant-plugin/ [https://maven.apache.org/plugins/maven-ant-plugin/] To be clear, this is NOT the plugin you can use to run Ant within Maven; that's the maven-antrun-plugin. I therefore propose that we retire the maven-ant-plugin. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven local repo in a common global directory for multiple parallel execution
Hi, On 26.05.19 15:48, Debraj Manna wrote: I have a machine in which multiple parallel maven execution happen . Each execution executes the below command in a seperate workspace directory Kind of a build server with a CI solution like Jenkins? mvn -f main/pom.xml clean package -DskipTests -T 6 Why using "-f main/pom.xml" ? Can someone let me know should I use a seperate maven local repo path ( -Dmaven.repo.local=$MAVEN_REPO) for each execution or I can use a common .m2 directory for all parallel runs? What is the best practice? I can recommend to use separate caches for each execution.. - Maven Version 3.5 I would suggest to upgrade to most recent Maven version.. Also define all versions of all plugins in your build... Kind regards Karl Heinz Marbaise - Java 8 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Source Plugin 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Source Plugin Version 3.1.0. https://maven.apache.org/plugins/maven-source-plugin/ Important Note: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-source-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-source-plugin/download.cgi Release Notes Maven Source Plugin 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12336941 Bugs: * [MSOURCES-105] - Remove link to non-existing Codehaus wiki * [MSOURCES-108] - Remove the readonly=true from finalName * [MSOURCES-119] - Archiving to jar is very slow Improvement: * [MSOURCES-110] - Add IT to prevent readonly=true problem with parameter Dependency upgrades: * [MSOURCES-109] - Upgrade parent to 31 * [MSOURCES-111] - Upgrade maven-archiver / plexus-archiver * [MSOURCES-112] - Upgrade plexus-utils 3.1.0 * [MSOURCES-114] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MSOURCES-116] - Upgrade plexus-archiver to 3.6.0 * [MSOURCES-117] - Upgrade maven-plugins parent to version 32 * [MSOURCES-118] - Upgrade JUnit to 4.12 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn -T unreliable in maven 3.6.1
Hi, On 17.05.19 07:47, Marlow, Andrew wrote: Hello everyone, I have found the -T option for parallel building to be unreliable. Has anyone else? It doesn’t seem to have had wide exposure yet and several commonly used packages are not yet marked as thread safe, but I was hoping for better results than I am seeing. What we need are logging output fully...furthermore your pom's and what exactly the problem is? Which version of Maven, JDK and the plugins you are using... I'm using -T for a long time with small and very large projects (800+ modules)... Kind regards Karl Heinz Marbaise The problem I am getting is that when it fails a random module fails to find some external jar that I know is there. For my project the most common occurrence is failure to find javax.servlet but it really is there and a serial build finds it. I am at a loss to understand how this can be happening. I am very keen indeed to get the -T option working because I have recently added use of the maven-jarsigner to the mix and the network I am using is slow and unreliable. A serial build with jar signing doubles the build time. When the parallel build works (which it does occasionally) the build time is reduced by an order of magnitude. *Andrew Marlow* Consultant developer, Apex 38^th Floor, 25 Canada Square, Canary Wharf, London E14 5LQ *T*: 020-8081-2367 / 07966-451-521 *E*: andrew.mar...@fisglobal.com <mailto:andrew.mar...@fisglobal.com> *FIS | Empowering the Financial World***cid:image001.png@01D112FA.C4A77D90 <https://www.facebook.com/FIStoday>cid:image002.png@01D112FA.C4A77D90 <https://twitter.com/FISGlobal>cid:image003.png@01D112FA.C4A77D90 <https://www.linkedin.com/company/fis> FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 * Registered Office: 38^th floor, 25 Canada Square, London, E14 5LQ, United Kingdom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Runtime library
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 15.05.19 22:33, Robert Scholte wrote: Hi, The Apache Maven project consist of about 100 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. The Maven Runtime library has been released 3 times, the last time was May 2012 for version 1.0-alpha-3. According to https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime [https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this library is only used in 4 projects. The main purpose of the library is reading the pom.properties or pom.xml from an artifact to get the version. This functionality works so the library can be considered finished. See https://maven.apache.org/shared/maven-runtime/ [https://maven.apache.org/shared/maven-runtime/] I therefore propose that we retire the maven-runtime. I don't think it makes sense to do a final release. Instead we should update the documentation and the freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven JAR Plugin 3.1.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JAR Plugin Version 3.1.2. https://maven.apache.org/plugins/maven-jar-plugin/ Important Note: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jar-plugin 3.1.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jar-plugin/download.cgi Release Notes Maven JAR Plugin 3.1.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12344629 Bug * [MJAR-259] - Archiving to jar is very slow Improvement: * [MJAR-238] - Allow setting of module main class Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Concurrency issue while running Maven on Jenkins host
Hi, On 09.05.19 16:09, Frizz wrote: I regularly suffer from corrupted maven-metadata-local.xml files on my Jenkins host in directory /home/jenkins/.m2/.../some-project/ I suppose you are using the local cache for all your jobs? If so this is the problem. The cache is and was intended for running a single build on it...If you run on a CI solution like Jenkins you should use the cache per job ... Kind regards Karl Heinz Marbaise E.g. extra lines added to the end of the maven-metadata-local.xml file like this: ... astUpdated> Do I suffer from concurrency issues? Like the one described here (created 2007, but still unresolved): https://issues.apache.org/jira/browse/MNG-2802 What could I do to mitigate the issue? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 08.05.19 20:25, Robert Scholte wrote: Hi, The Apache Maven project consist of about 100 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. The Maven Artifact Resolution API (maven-artifact-resolver) is a shared component that could be used to easily resolve Maven project dependencies. The last (and only) released version is 1.0 in September 2009.( https://maven.apache.org/shared/maven-artifact-resolver/ [https://maven.apache.org/shared/maven-artifact-resolver/] ). This library should not be confused with Artifact Resolver (maven-resolver), previously known as Aether. As you can see the naming will cause confusion. The library that aims the same goal for Artifact Resolver is another shared component called maven-artifact-transfer (which by now is not just the transfer part or Artifact Resolver, but a bridge for both Sonatype Aether as used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+. This way Maven plugins and extensions can be compatible with any Maven 3 release) I therefore propose that we retire the maven-artifact-resolver. I don't think it makes sense to do a final release. Instead we should update the documentation and the freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Compiler Plugin Version 3.8.1
The Apache Maven team is pleased to announce the release of the Apache Maven Compiler Plugin Version 3.8.1 https://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your project's plugin configuration: Important Notes since Version 3.8.0 * The default value for source/target has been lifted from 1.5 to 1.6 see MCOMPILER-335. org.apache.maven.plugins maven-compiler-plugin 3.8.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-compiler-plugin/download.cgi Release Notes Maven Compiler Plugin 3.8.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225=12343484 Bugs: * [MCOMPILER-306] - Incorrect `compilerArgs` example usage * [MCOMPILER-349] - maven-compiler-plugin does not recompile a module if a dependency module has been updated & recompiled * [MCOMPILER-360] - NPE when calculating modulepath with invalid entries * [MCOMPILER-379] - Fatal error compiling: basedir ... arget/generated-sources/annotations does not exist Improvements: * [MCOMPILER-322] - Set the JPMS module version * [MCOMPILER-366] - Warning about automodules should provide the list of offending libraries Enjoy, - The Apache Maven team Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Repository Plugin
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 23.04.19 21:43, Robert Scholte wrote: Hi, The Apache Maven project consist of about 100 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. One of those subprojects is the maven-repository-plugin, last released on February 22, 2015. It's main purpose: a plugin that can be used to create bundles of artifacts that can be uploaded to the central repository. Based on that it seems that the maven-assembly-plugin is a better fit for that. I therefore propose that we retire the maven-repository-plugin. I don't think it makes sense to do a final release. Instead we should update the documentation and the freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Version 3.6.1 Released
The Apache Maven team is pleased to announce the release of the Apache
Maven 3.6.1.
Apache Maven is a software project management and comprehension tool.
Based on the concept of a project object model (POM), Maven can manage a
project's build, reporting and documentation from a central piece of
information.
You can find out more about Apache Maven at https://maven.apache.org
You can download the appropriate sources etc. from the download page:
https://maven.apache.org/download.cgi
Release Notes - Apache Maven Version 3.6.1
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344378=12316922
Code Contributors of this release:
* Gabriel Belingueres (indirectly via plexus-utils PR)
* Michael Istria
* Michael Istria
* Guy Brand
* Fabiano C. de Oliveira
* Michael Istria
Issue Reporters of this release:
* Ondra Žižka
* Matthias Scmalz
* Andreas Sewe
* Christian Aistleitner
* Jin Kwon
* Christoph Etzel
* Dawid Weiss
* Gene Smith
* Patrik Jetzer
* Rohan Padhye
* Elliotte Rusty Harold
* Andreas Veithen
* Olaf Otto
* Michael Istria
* Michael Istria
* Michael Istria
* Romain Manni-Bucau
* Guy Brand
* Rohan Padhye
* Olaf Otto
* Gunnar Wagenknecht
* Viacheslav Yakunin
Many thanks to contributors and reporters for the support and time.
Participants to the VOTE of the Maven 3.6.1 Release:
* Gabriel Belingueres
* Francois Papon
* Eric Lilja
Many thanks to those who tested the Maven releases
and thanks for their support as well.
(Please send an email to the dev list if we missed one to mention).
Release Notes for Apache Maven 3.6.1
https://maven.apache.org/docs/3.6.1/release-notes.html
Bugs:
* [MNG-5705] - NPE on parallel build in
BuilderCommon.handleBuildError(BuilderCommon.java:147)
* [MNG-5965] - Parallel build multiplies work if multiple goals are given
* [MNG-5995] - Maven itself cannot run without maven-compat
* [MNG-6256] - Maven script can break if “-f” path contains special
characters
* [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with
complex multimodule builds
* [MNG-6262] - getCanonicalFile() is not used consistently during
project resolution
* [MNG-6346] - … was unexpected at this time when using -f option and
path contains brackets
* [MNG-6374] - ModelBuilder hangs with malformed pom.xml
* [MNG-6429] - Integration Test site publishing requires Java 7 (or
javadoc errors ignored)
* [MNG-6495] - ModelResolver cannot be null
* [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
* [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
* [MNG-6529] - ProjectBuilder.build(List projects, boolean,
ProjectBuildingRequest) doesn’t honor
ProjectBuildingRequest.isResolveDependencies()
* [MNG-6530] - Regression in ProjectBuilder when file change between
invocations (introduced by MNG-6311)
* [MNG-6533] - ProjectBuilder.build(list_of_projects,...) does not
contain MavenProject in exception report
* [MNG-6543] - Upgrade plexus classworld to support java 9+
ClassLoader.findClass(String moduleName, String name) in Mojos
* [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
* [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing
unicode entity ref
* [MNG-6590] - DefaultProjectArtifactsCache
java.lang.IllegalStateException: Duplicate artifact resolution result
* [MNG-6599] - unknown version in model id when version is defined
from parent
Improvements:
* [MNG-6059] - Important use cases not covered, as
child.inherit.append.path affects all children
* [MNG-6159] - Child path adjustments break git scm urls
* [MNG-6213] - Maven doesn’t check the validity of scope value
* [MNG-6481] - Allow to compile and test Maven with Java 11
* [MNG-6513] - Replace depreated Plexus javadoc tags with annotations
in ITs
* [MNG-6515] - Fix javadoc build errors under Java 8 and 11
* [MNG-6520] - Update assembly descriptors to 2.0.0
* [MNG-6522] - Prepare Maven’s Core Integration Test Suite to test
with Java 12 and 13-ea
* [MNG-6572] - use int or long instead of BigIntegers for little
numbers in ComparableVersion
* [MNG-6593] - track input location for super-pom
* [MNG-6597] - add input location tracking for plugins configuration
* [MNG-6600] - add input location tracking for default lifecycle
bindings executions
* [MNG-6601] - add input location tracking for site’s reportPlugins
injected by reports conversion
* [MNG-6605] - Allow to suppress download messages in interactive mode
* [MNG-6611] - Update animal-sniffer-maven-plugin to 1.17
Wish
* [MNG-6571] - Maven memory consumption issue
Tasks:
* [MNG-6538] - Upgrade Maven Artifact Resolver to 1.3.3 to restore API
* [MNG-6544] - Replace CacheUtils#{eq,hash} with Objects
* [MNG-6573] - Use latest Maven 3.6.0 to build Maven Core and plugins
with ASF CI
* [MNG-6618] - Maven doesn’t export org.slf4j.event.Level
Dependency upgrades:
* [MNG-6526] - Upgrade to Wagon 3.3.1 (from
Re: Need help.. How to configure POM for multi-module checkout
Hi Gary, On 24.03.19 17:55, ga...@oedata.com wrote: Hi Nick, Thanks for the questions, I'll try to explain. The parent pom aggregates a library (jar) from different and sometimes interdependent modules. The parent pom checks out the module sources with the poms and compiles them into a single jar. Maybe I misunderstand a thing here. But it sounds as if you have a resulting library which results in a single jar? Let us ignore at the first place the checkout things etc. Basicly I would say if your result is a single jar you usually have a single maven project? If your result is a single jar which is combined from different modules I would reconsider the architecture cause usually it's better having separated modules like *-api, *-core etc. and may be a supplemental thing could be a shaded-jar which combines several of them... Having seperated modules make testing easier which means you can put your unit tests into the appropriate module etc. Do you use maven-shade/maven-assembly-plugin? If you like to produce a BOM file. The usualy way is to make a separate module which contains simply the dependencyManagement with mentioning the modules it should contain. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need help.. How to configure POM for multi-module checkout
Hi,
I will give you the same answer as on StackOverflow.
The way you are going sounds wrong...
As I already suggested is the way to go creating a multi module build
which comprises of several modules which is located within a single Git
repository. this can be build by using a single command.
mvn clean package
from the root location..
https://github.com/khmarbaise/javaee
https://github.com/khmarbaise/supose
Kind regards
Karl Heinz Marbaise
On 24.03.19 00:35, Gary M wrote:
Hi,
I need some help with scm checking out multiple modules and building them.
I have several projects I'm consolidating into a single jar. Reactor
checks for module poms before generate-sources executes.
How do I fix this issue ?
thanks..
g
POM sample to give you an idea of what I've done.
org.apache.maven.plugins
maven-scm-plugin
1.9.4
mod-1
generate-sources
${mod-1.url}
${mod-1.versionType}
${mod-1.version}
${mod-1.directory}
checkout
mod-2
generate-sources
${mod-2.url}
${mod-2.versionType}
${mod-2.version}
${mod-2.directory}
checkout
.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 fails to follow 301 redirects
On 08.03.19 07:42, Debraj Manna wrote: Hi I can see an issue filed for "Maven 3 fails to follow 301 redirects" https://issues.apache.org/jira/browse/MNG-4816. Can someone let me know in which version of maven 3.x this is fixed as I am observing the issue with Maven 3.5 also? Can you tell why you are using Maven Wagon? Furthermore for what purpose? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Resolver Version 1.3.3 Released
The Apache Maven team is pleased to announce the release of the Maven Resolver version 1.3.3. https://maven.apache.org/resolver/ Apache Maven Artifact Resolver is a library for working with artifact repositories and dependency resolution. Maven Artifact Resolver deals with the specification of local repository, remote repository, developer workspaces, artifact transports, and artifact resolution. You can download the appropriate sources etc. from the download page: https://maven.apache.org/resolver/download.cgi Release Notes - Maven Resolver - Version 1.3.3 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12345144 Bug: * [MRESOLVER-67] - The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11 Wish: * [MRESOLVER-53] - Document runtime exceptions Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven resolves wrong dynamic (transitive) dependency version
Hi Florian, On 24.02.19 21:04, Florian Schmaus wrote: Assume a project which declares a dependency on libFoo version 1.0.0, now libFoo also declares a dependency on libBar using a dynamic version specifier [1.0, 2.0). Now what I expect to happen is that Maven pulls in any, ideally the latest available release, libBar 1.0 version artifact. What actually happens is that Maven pulls in libBar 2.0-alpha5, which causes dynamic linking issues. Gradle, OTOH, pulls in libBar 1.3 when it is used to build the project. I have created an example project, using the actual artifacts I experience this issue with, to demonstrate the different behavior between Maven and Gradle: https://github.com/Flowdalic/maven-transitive-dynamic-dependency The example project is configured to depend on Smack, an FOSS XMPP client library, version 4.3.2. This Smack version declares jxmpp [0.6, 0.7) as a dependency. $ mvn exec:java … Smack version: 4.3.2 (4.3.2-4.3 2019-02-22) jxmpp version: 0.7.0-alpha5 ERROR: jxmpp version does not start with '0.6' as expected. :( If I take a look via mvn dependency:tree which looks like this: [INFO] Scanning for projects... [INFO] [INFO] --< com.mycompany.app:my-app >-- [INFO] Building my-app 1.0-SNAPSHOT [INFO] [ jar ]- [INFO] [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ my-app --- [INFO] com.mycompany.app:my-app:jar:1.0-SNAPSHOT [INFO] +- org.igniterealtime.smack:smack-tcp:jar:4.3.2:compile [INFO] | \- org.igniterealtime.smack:smack-core:jar:4.3.2:compile [INFO] | +- xpp3:xpp3:jar:1.1.4c:compile [INFO] | +- org.jxmpp:jxmpp-core:jar:0.7.0-alpha5:compile (version selected from constraint [0.6,0.7)) [INFO] | | \- org.jxmpp:jxmpp-util-cache:jar:0.7.0-alpha5:compile [INFO] | +- org.jxmpp:jxmpp-jid:jar:0.7.0-alpha5:compile (version selected from constraint [0.6,0.7)) [INFO] | \- org.minidns:minidns-core:jar:0.4.0-alpha3:compile (version selected from constraint [0.3,0.4)) [INFO] \- junit:junit:jar:4.11:test [INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 1.211 s [INFO] Finished at: 2019-02-24T21:15:40+01:00 [INFO] which shows that org.igniterealtime.smack:smack-core:jar:4.3.2:compile (see https://search.maven.org/artifact/org.igniterealtime.smack/smack-core/4.3.2/jar) has dependency to org.jxmpp jxmpp-jid [0.6, 0.7) compile this is a version range which means starting with release 0.6 including the release 0.6 itself. The part 0.7) means not include the final release 0.7 which is not the case. maven-transitive-dynamic-dependency (master)$ ~/tools/jdk8u202-b08/Contents/Home/bin/java -jar ~/tools/apache-maven-3.6.0/lib/maven-artifact-3.6.0.jar 0.7 0.7.0-alpha7 Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 0.7 == 0.7 0.7 > 0.7.0-alpha7 2. 0.7.0-alpha7 == 0.7-alpha-7 That is based on the behaviour in ComparableVersion which handles non GA as before the final release which is exactly here the case. But as Michael already stated out this would require a change in behaviour of Maven 3.X which will likely *not* happend. Kind regards Karl Heinz Marbaise $ gradle run … Smack version: 4.3.2 (4.3.2-4.3 2019-02-22) jxmpp version: 0.6.3 Is that by design or a (known) Maven issue? Thanks - Florian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: antrun versus wsl
Hi, can you give some reasons etc. why you need to execute scripts during a Maven build? What is the purpose ? What kind of problem are you trying to solve? Kind regards Karl Heinz Marbaise On 17.02.19 12:09, Franz Fehringer wrote: Hi all, I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only the Windows component, no real Linux distribution yet). This scenario gives me a strange problem with antrun: With i always get the WSL bash instead of the Cygwin one, although Cygwin is first in PATH (both Cygwin PATH and Windows PATH), even so if C:/Windows/System32 (location of WSL bash) is not in the (Cygwin) PATH at all. I made some tries with extra parameters like seachpath to no avail. It (naturally) works if i give the full absolute path to the Cyhwin bash, but this is awkward. Any hints about reason and solution? Thanks Franz - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
