Maven Resolver Ant task - debug option

Hi, I have managed to get maven resolver ant tasks to work. I have some problems on some build servers and would like to run effectively mvn -X. Is it possible to enable debug mode when using resolver ant tasks? Alternatively is it some way of reading which settings.xml it is using? E.g. in a

Re: missing dependency version

Thanks for your reply, Mark. Seeing that path to that jaxb jar made me check my maven config again. Turns out I had the repository duplicated. I thought I was using one in [my user]/.m2, but as the path shows it is actually in [my user]/m The pm file it was using in the 'm' repository had some

Re: Getting started with Resolver Ant Tasks

I found an article on codesaying to help build a fat jar with all its dependencies. Might be an idea to include something like that on the resolver ant task page on apache.org regards, Rune -- Sent from:

Re: Best Practice for distributing test utilities?

Put the testutils and the tests in the same project as foo in src/test/java and make the tests package private (JUnit Jupiter). Other projects can depend on the test artifact of foo and only use the test-utils. Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it

Re: Best Practice for distributing test utilities?

On 12/03/2020 13:55, Andreas Sewe wrote: If the test utilities are simple enough and are somehow specific to foo, I would put them into foo, under src/main/java, in a package like com.foo.testing. If they are more general, so that they could be used to write tests for some other package not

Re: Best Practice for distributing test utilities?

Mark Prins wrote: > refactor foo to a multimodule one with the test utilities as an artifact > and one with the code + tests for original foo, you can then depend on > the test module with scope test in the main module and keep everything > in source repo making it easy to stay in sync Grouping

Re: Best Practice for distributing test utilities?

You need to remove the compile time dependency from foo-test-utils to foo. Obviously you will have a runtime dependency, but that's ok. One simple way is to use reflection in foo-test-utils when instantiating the Foo object. Not pretty, but a simple solution. There are more elegant solutions but

Re: Best Practice for distributing test utilities?

Anders Hammar wrote: > I'd say option 4 is the way to go. But you need to solve the circular > dependency problem. One way is to have a third api project/module, which > foo-test-utils have a compile time dependency on. Here you could use the > Service Provider Interface pattern. >> 4. Option 4

RE: Problem with the maven-compiler-plugin

Thank you for the feedback. I should have been using –verbose not –version. When using –verbose the plugin is working as expected. Thank you for your time. From: Thomas Broyer Sent: Friday, March 13, 2020 3:02 AM To: Maven Users List Subject: Re: Problem with the maven-compiler-plugin

Re: Problem with the maven-compiler-plugin

What is it that you think is not working? (fwiw, javaP -version prints the version of javaP, not the version the class was compiled with/to; that would be a 51.0 or similar anyway, not a 1.7) Le ven. 13 mars 2020 à 08:26, Nelligan, Steven M a écrit : > *It appears that the

Problem with the maven-compiler-plugin

It appears that the maven-compiler-plugin is not working or I am doing something wrong. I have the following in the POM file. org.apache.maven.plugins maven-compiler-plugin 3.8.1