Re: maven-surefire-plugin add artifact as additionalClasspathElement
I agree that the current syntax for adding to stuff to test runtime is
clunky and I wouldn't personally use it unless I needed to.
On Thu, Feb 16, 2023 at 1:07 PM Alexander Kriegisch
wrote:
>
> Which is exactly why I was asking. I want to learn about real-world use
> cases which would require such a thing, not be just nice to have.
> Over-engineering POMs does not make them more readable or maintainable.
>
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Mikael Åsberg schrieb am 16.02.2023 um 13:03:
> > I use runtime scope a lot, but personally can't recall having needed
> > the equivalent of a test-runtime scope myself (or, more likely, I
> > could get away with test compile scope even though the dependency was
> > only needed at test runtime). But just because I haven't needed it
> > doesn't mean there are no legit circumstances.
> >
> > On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
> > wrote:
> >>
> >> For a test, does it really matter to make the dependency test-scoped?
> >>
> >> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
> >>> Because there exists runtime, but no test only runtime
> >>> scope
> >>>
> >>> On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
> >>> wrote:
> >>>>
> >>>> I would be more interested first in why this should be necessary at all.
> >>>> What is the use case that would not be covered by declaring a regular
> >>>> test-scoped dependency in the module?
> >>>> --
> >>>> Alexander Kriegisch
> >>>> https://scrum-master.de
> >>>>
> >>>>
> >>>> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> >>>>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >>>>>>
> >>>>>> On Thu, 16 Feb 2023 at 20:07, Delany
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Stephane,
> >>>>>>>
> >>>>>>> You can do like this
> >>>>>>>
> >>>>>>>
> >>>>>>> maven-surefire-plugin
> >>>>>>> 3.0.0-M9
> >>>>>>>
> >>>>>>>
> >>>>>>> org.apache.commons
> >>>>>>> commons-email
> >>>>>>> 1.5
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> this will add dependencies to the surefire plugin itself.
> >>>>>> I guess Stephane wants to add to the jvm running the tests?
> >>>>>>
> >>>>>> additionalClasspathElement expect a full path to a directory or a file
> >>>>>> to be added to the classpath
> >>>>>>
> >>>>>> should work with something such but you need to assume commons-email
> >>>>>> has been resolved locally as a dependency.
> >>>>>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>>>>>
> >>>>>> another solution is to use dependency:copy to copy the commons-email
> >>>>>> dependency somewhere in ./target and use this path (see
> >>>>>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
> >>>>>>
> >>>>>
> >>>>> a real example here :)
> >>>>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >>>>>
> >>>>>> hth
> >>>>>> Olivier
> >>>>>>
> >>>>>>>
> >>>>>>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> Is it possible to add a maven artifact as an
> >>>>>>>> additionalClasspathElement ?
> >>>>>>>>
> >>>>>>>> I tried this syntax, inspired by the exclusion mechanism, but it's
> >>>>>>>> not
>
Re: maven-surefire-plugin add artifact as additionalClasspathElement
I use runtime scope a lot, but personally can't recall having needed
the equivalent of a test-runtime scope myself (or, more likely, I
could get away with test compile scope even though the dependency was
only needed at test runtime). But just because I haven't needed it
doesn't mean there are no legit circumstances.
On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
wrote:
>
> For a test, does it really matter to make the dependency test-scoped?
>
> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
> > Because there exists runtime, but no test only runtime scope
> >
> > On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
> > wrote:
> >>
> >> I would be more interested first in why this should be necessary at all.
> >> What is the use case that would not be covered by declaring a regular
> >> test-scoped dependency in the module?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >>
> >> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> >>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >>>>
> >>>> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >>>>>
> >>>>> Hi Stephane,
> >>>>>
> >>>>> You can do like this
> >>>>>
> >>>>>
> >>>>> maven-surefire-plugin
> >>>>> 3.0.0-M9
> >>>>>
> >>>>>
> >>>>> org.apache.commons
> >>>>> commons-email
> >>>>> 1.5
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> this will add dependencies to the surefire plugin itself.
> >>>> I guess Stephane wants to add to the jvm running the tests?
> >>>>
> >>>> additionalClasspathElement expect a full path to a directory or a file
> >>>> to be added to the classpath
> >>>>
> >>>> should work with something such but you need to assume commons-email
> >>>> has been resolved locally as a dependency.
> >>>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>>>
> >>>> another solution is to use dependency:copy to copy the commons-email
> >>>> dependency somewhere in ./target and use this path (see
> >>>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
> >>>>
> >>>
> >>> a real example here :)
> >>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >>>
> >>>> hth
> >>>> Olivier
> >>>>
> >>>>>
> >>>>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> >>>>> wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Is it possible to add a maven artifact as an
> >>>>>> additionalClasspathElement ?
> >>>>>>
> >>>>>> I tried this syntax, inspired by the exclusion mechanism, but it's not
> >>>>>> working.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> org.apache.maven.plugins
> >>>>>> maven-surefire-plugin
> >>>>>> 3.0.0-M9
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> org.apache.commons:commons-email:1.5
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> thank you
> >>>>>>
> >>>>>> Stéphane
> >>>>>>
> >>>
> >>> -
> >>> 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
> >>
> >
> > -
> > 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
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Because there exists runtime, but no test only runtime scope
On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
wrote:
>
> I would be more interested first in why this should be necessary at all.
> What is the use case that would not be covered by declaring a regular
> test-scoped dependency in the module?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> > On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >>
> >> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >>>
> >>> Hi Stephane,
> >>>
> >>> You can do like this
> >>>
> >>>
> >>> maven-surefire-plugin
> >>> 3.0.0-M9
> >>>
> >>>
> >>> org.apache.commons
> >>> commons-email
> >>> 1.5
> >>>
> >>>
> >>>
> >>
> >> this will add dependencies to the surefire plugin itself.
> >> I guess Stephane wants to add to the jvm running the tests?
> >>
> >> additionalClasspathElement expect a full path to a directory or a file
> >> to be added to the classpath
> >>
> >> should work with something such but you need to assume commons-email
> >> has been resolved locally as a dependency.
> >> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>
> >> another solution is to use dependency:copy to copy the commons-email
> >> dependency somewhere in ./target and use this path (see
> >> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
> >>
> >
> > a real example here :)
> > https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >
> >> hth
> >> Olivier
> >>
> >>>
> >>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> >>> wrote:
> >>>
> Hello,
>
> Is it possible to add a maven artifact as an additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M9
>
>
>
> org.apache.commons:commons-email:1.5
>
>
>
>
>
>
>
> thank you
>
> Stéphane
>
> >
> > -
> > 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
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Failsafe: Killing self fork JVM. PING timeout elapsed.
These issues regarding communication with forked JVMs, won't they be resolved once surefire moves to interprocess communication using tcp/ip sockets? This happens to be the target feature to be included in the next surefire 3.0.0 milestone: https://issues.apache.org/jira/projects/SUREFIRE/versions/12344668 There are s many issues relating to surefire reading stdout of forked processes (which is my understanding that it is currently doing). Many of us are really looking forward to the next milestone. On Tue, Mar 19, 2019 at 8:59 PM Jason Young wrote: > > Getting back to my original questions, I know that "ping" means to see if a > process is there, and "NOOP" implies it's not a command to do anything. But > what do the terms "ping" and "NOOP" mean in this context, i.e. how do the > processes communicate? I assume they don't sonar. Do other processes also > ping NOOPs? Can I PING Chrome with a NOOP from bash? Is it with TCP? > > I'm confused about what I should do regarding GC pauses. Previously I had > code that would write the amount of remaining heap space (or something like > that) to stdout after every test to troubleshoot OOMEs. Can writing to > stdout cause the communication failure somehow? > > On Wed, Mar 13, 2019 at 5:57 PM Jason Young > wrote: > > > I upgraded failsafe and surefire to 3.0.0-M3 as advised; we encountered > > the same exception. (Still using -Xmx5g, will switch to OpenJ9 soon in case > > that helps.) > > > > BTW I also asked on StackOverflow previously, for anyone interested: > > https://stackoverflow.com/questions/54755846/killing-self-fork-jvm-ping-timeout-elapsed > > > > On Tue, Feb 26, 2019 at 6:40 PM Jason Young > > wrote: > > > >> Thanks again for the information. > >> > >> We had increased the RAM to 3g some time ago to prevent OOMEs. More > >> recently, I increased the RAM again to 5g for extra headroom since we had > >> more headroom available; the problem hasn't happened since, but it hasn't > >> been very long. > >> > >> We use a more customized image based on Alpine 3.8.2. The JDK and Maven > >> are obtained via apk. > >> > >> I will try upgrading failsafe (and surefire while I'm at it) sooner, and > >> probably do some experimentation with JVMs another time (not pressing for > >> me ATM). > >> > >> On Tue, Feb 26, 2019 at 12:20 PM Tibor Digana > >> wrote: > >> > >>> >> I'll try to enable some logging about GC pauses to see what's up > >>> > >>> Pls do not keep such setting after tuning the GC because this may > >>> sometime > >>> break the interprocess communication between Maven process and surefire > >>> process. > >>> It's worth to list GC information in a file and not in the console logs. > >>> This can be configured, I guess. > >>> > >>> >> Do you think the value is simply too low? > >>> > >>> GCing many objects may take some time and I remember we had a user who > >>> had > >>> this problem a year or two ago. > >>> We check every third NOOP (which is 3 x 10 sec) as a fix instead of every > >>> NOP. So 30 seconds looked satisfactory. > >>> I think you use old version 2.20 or something like that. The fixes for > >>> docker have been done so far, so please use the latest version 3.0.0-M3. > >>> See this page > >>> https://maven.apache.org/surefire/maven-surefire-plugin/docker.html, we > >>> used maven:3.5.3-jdk-8-alpine in this test. Which base image did you use? > >>> > >>> Cheers > >>> Tibor > >>> > >>> On Tue, Feb 26, 2019 at 5:24 PM Jason Young > >>> wrote: > >>> > >>> > Thanks for the information. It's good to see someone understands a > >>> little > >>> > about this. > >>> > > >>> > Incidentally, we have been looking at other GCs and VMs for the > >>> application > >>> > in production environments, so I'll look into how these affect tests as > >>> > well. I'll try to enable some logging about GC pauses to see what's up. > >>> > > >>> > How would `-Xmx3g` cause long GC cycles? Do you think the value is > >>> simply > >>> > too low? > >>> > > >>> > FWIW we're running the Maven build in an Alpine-based Docker container. > >>> > > >>> > On Sat, Feb 23, 2019 at 6:36 AM Tibor Digana > >>> > wrote: > >>> > > >>> > > Hi Jason, > >>> > > > >>> > > We spoke about this issue on our chat in ASF Slack: > >>> > > "I think his tests have been paused for a long GC periods and timed > >>> out > >>> > 3x > >>> > > PING period = 30 seconds. After this period forked JVM supposed the > >>> Maven > >>> > > process was killed by JenkinsCI and therefore all surefire processes > >>> are > >>> > > killed as well and all the file handlers and memory consumptions are > >>> > > freed." > >>> > > > >>> > > "But I have to say that `-Xmx3g` may cause long GC cycles, see > >>> > > > >>> > > > >>> > > >>> https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html > >>> > > " > >>> > > > >>> > > You are using java-1.8-openjdk. I guess you should use Shenandoah GC > >>> > which > >>> > > is an experimental algorithm in JVM 1.8. This would significantly > >>> short
Re: Confusion with Dependency Paths
Hi Dennis, maybe you should start with something from scratch then so you learn step by step. Create a pom manually, don't rely on Eclipse to generate things. You need to specify a groupId, an artifactId, and a version. It could be called mavenexample:mavenexample:1.0 (groupId:artifactId:version). You should also set properties maven.compiler.source and maven.compiler.target. Set to 1.8 if you are using Java 8. Finally, set packaging to jar. Now you have the basics of a pom file. Main sources go in src/main/java. You could create a folder there called mavenexample and place a class MavenExample.java inside it. Package name would be mavenexample. Create a very simple public class. Doesn't have to have a main method. Maybe with a single method sayHello() which returns "Hello". It should not need any 3rd party jars to compile. When you have that you can test to build it using "mvn clean install". Maven uses the environment variable JAVA_HOME to find the JDK so make sure that is set. When it builds successfully it's time to add a dependency. Add com.google.guava:guava:20.0 as dependency and try to use it in your MavenExample.java class. When that works you know a lot of the basics. Or any other dependency you are familiar with. Finally, write a Junit test. Then you need to depend on the junit-library. Test sources go into src/test/java. A junit test class for mavenexample/MavenExample would be mavenexample/MavenExampleTest.java (but under src/test/java instead of src/main/java). Test classes typically go into the same package as the class under test, so package-private things become visible to it. If you can do the points above, you have understood the basics and have tools to help you migrate a bigger project. Good luck! On Tue, Feb 5, 2019 at 5:08 PM Dennis Putnam wrote: > > Hi Mikael, > > I am using Ant. Others have tried to get me to switch to Maven but as I > said I could never get it to work. The problem is that the project was > not Maven to begin with but I had to change it in Eclipse because the > app needs iTextPDF and Maven was the only way to get it. > > On 2/5/2019 9:33 AM, Mikael Åsberg wrote: > > Well, you need to make up your mind what you want to use...ant or > > maven. If you want to use maven you need to structure your project > > according to the rules of Maven. I suggest Maven (over ant), which is > > supported by all major IDEs. So you specify your dependencies in the > > pom file once and for all, and you can build the project in the IDE or > > from the command line without additional tinkering. > > > > On Tue, Feb 5, 2019 at 3:14 PM Dennis Putnam wrote: > >> Hi Mikael, > >> > >> I've been down this road before. This is ultimately compiled using Ant. > >> I have never been able to get it to work using Maven. It has been > >> working in the past but I ran into a problem with a git update and since > >> then I've had this problem. There has to be something that is messed up > >> with wherever javac gets the path information from for the Maven > >> dependencies. > >> > >> On 2/5/2019 8:27 AM, Mikael Åsberg wrote: > >>> If you have a maven project you compile using maven, you don't use javac > >>> > >>> On Tue, Feb 5, 2019, 14:25 Dennis Putnam >>> > >>>> Hi Bernd and Marco, > >>>> > >>>> After further thought I'm not sure how these changes will help with the > >>>> path problem when compiling. It seems to me that the more likely culprit > >>>> is .classpath. I know even less about that than pom.xml. Just in case, > >>>> here is my .classpath (again generated by Eclipse. > >>>> > >>>> > >>>> > >>>> >>>> output="target/classes" path="src"> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> > >>>> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8"> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >
Re: Confusion with Dependency Paths
Well, you need to make up your mind what you want to use...ant or maven. If you want to use maven you need to structure your project according to the rules of Maven. I suggest Maven (over ant), which is supported by all major IDEs. So you specify your dependencies in the pom file once and for all, and you can build the project in the IDE or from the command line without additional tinkering. On Tue, Feb 5, 2019 at 3:14 PM Dennis Putnam wrote: > > Hi Mikael, > > I've been down this road before. This is ultimately compiled using Ant. > I have never been able to get it to work using Maven. It has been > working in the past but I ran into a problem with a git update and since > then I've had this problem. There has to be something that is messed up > with wherever javac gets the path information from for the Maven > dependencies. > > On 2/5/2019 8:27 AM, Mikael Åsberg wrote: > > If you have a maven project you compile using maven, you don't use javac > > > > On Tue, Feb 5, 2019, 14:25 Dennis Putnam > > >> Hi Bernd and Marco, > >> > >> After further thought I'm not sure how these changes will help with the > >> path problem when compiling. It seems to me that the more likely culprit > >> is .classpath. I know even less about that than pom.xml. Just in case, > >> here is my .classpath (again generated by Eclipse. > >> > >> > >> > >> >> output="target/classes" path="src"> > >> > >> > >> > >> > >> > >> >> > >> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8"> > >> > >> > >> > >> > >> >> path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"> > >> > >> > >> > >> > >> > >> > >> > >> I don't understand how Eclipse is able to compile this successfully and > >> javac cannot. Shouldn't the files be the same for both? There must be > >> some difference between what Eclipse is using and what is winding up in > >> my git working tree that is used for javac. However, pom.xml and > >> .classpath in both working trees are the same. What I don't see in > >> either file is the path to the Maven dependencies that show up in the > >> Eclipse dependencies window (see attached). I think that is the crux of > >> the problem but I don't know how that get factored into the compile step > >> with javac. > >> > >> Thanks again for your patience and help. > >> > >> On 2/4/2019 3:44 PM, Bernd Eckenfels wrote: > >>> Hello, > >>> > >>> to add to this, after moving the source to src/main/java/* and Fixing > >> the POM (removing the source path and potentialla the resource plugin) you > >> can use eclipse alt+f5 t refresh from the pom, this will configure the > >> ecplise Project layout (.classpath) to detect the same source Folders so it > >> can work in combination with Maven. > >>> Gruss > >>> Bernd > >> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Confusion with Dependency Paths
If you have a maven project you compile using maven, you don't use javac On Tue, Feb 5, 2019, 14:25 Dennis Putnam Hi Bernd and Marco, > > After further thought I'm not sure how these changes will help with the > path problem when compiling. It seems to me that the more likely culprit > is .classpath. I know even less about that than pom.xml. Just in case, > here is my .classpath (again generated by Eclipse. > > > > output="target/classes" path="src"> > > > > > > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8"> > > > > > path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"> > > > > > > > > I don't understand how Eclipse is able to compile this successfully and > javac cannot. Shouldn't the files be the same for both? There must be > some difference between what Eclipse is using and what is winding up in > my git working tree that is used for javac. However, pom.xml and > .classpath in both working trees are the same. What I don't see in > either file is the path to the Maven dependencies that show up in the > Eclipse dependencies window (see attached). I think that is the crux of > the problem but I don't know how that get factored into the compile step > with javac. > > Thanks again for your patience and help. > > On 2/4/2019 3:44 PM, Bernd Eckenfels wrote: > > Hello, > > > > to add to this, after moving the source to src/main/java/* and Fixing > the POM (removing the source path and potentialla the resource plugin) you > can use eclipse alt+f5 t refresh from the pom, this will configure the > ecplise Project layout (.classpath) to detect the same source Folders so it > can work in combination with Maven. > > > > Gruss > > Bernd > >
Re: Enforce no local versions
He wants to ensure that no managed versions I are overridden. On Jan 29, 2019 11:40, "Tamás Cservenák" wrote: So, if I understand correctly: to enforce there is no reactor project in depMgt section of child modules? On Tue, Jan 29, 2019 at 12:48 AM Jörg Schaible wrote: > On Mon, 28 Jan 2019 22:34:56 +0100 Harald Wellmann wrote: > > > Do you mean a rule to enforce no snapshot dependencies? In that case, > > there is a rule called "requireReleaseDeps". > > No. > > > "No local versions" does not really make sense to me, because any remote > > dependency will first be downloaded to your local repository. > > It has nothing to do with repositories. We manage versions in a depMgmt > section the parent of a multi- > project and no-one should declare own versions for his dependencies in the > sub projects. > > Regards, > Jörg > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Problem with running Spring Integration Tests with mvn verify
Is your surefire set up to a fork a new VM for each testclass whereas
intellij reuses?
On Tue, Jan 15, 2019, 07:56 a.tokare...@gmail.com
>
> On 2019/01/13 12:17:14, Robert Kleinschmager
> wrote:
> > Your configuration looks fine for your task, but I’m sorry - I have no
> hint, why IntelliJ is faster.
> >
> > At first: it depends on, how your 500 Tests are organised. How many
> test-classes, how many methods do they have?
> > Are you running JUnit4 or already Junit5? Are you using Parallel-Mode in
> IntelliJ?
> > Can you see in the logs, how many times the spring-context is created &
> destroyed?
> >
> > Looking at the code of the Unit-Execution on Intellij [1] and surefire
> [2] may bring some more insights, but I’m not familiar with both of them -
> it would really help to debug them.
> >
> > [1]
> https://github.com/JetBrains/intellij-community/tree/master/plugins/junit_rt
> <
> https://github.com/JetBrains/intellij-community/tree/master/plugins/junit_rt
> >
> > [2] https://github.com/apache/maven-surefire <
> https://github.com/apache/maven-surefire>
> >
> > > Am 08.01.2019 um 14:12 schrieb a.tokare...@gmail.com:
> > >
> > >
> > >
> > > On 2019/01/07 16:40:45, Robert Kleinschmager
> wrote:
> > >> Hi Aleksandar,
> > >>
> > >> Can you please show (attach|) your POM. Maybe your failsafe config is
> non-optimal.
> > >> In general: Intellij uses a different kind of junit execution, than
> failsafe/surefire
> > >>
> > >> Kind regards
> > >> Robert
> > >>
> > >>> Am 05.01.2019 um 12:20 schrieb Aleksandar Tokarev <
> a.tokare...@gmail.com>:
> > >>>
> > >>> I am having a Spring Boot application with around ~500 Tests (Unit
> and
> > >>> mostly Integration).
> > >>>
> > >>> When i start running the tests in IntelliJ with second click -> Run
> all
> > >>> Tests - tests run in around 10-15mins.
> > >>>
> > >>> When i try to run the tests with "mvn verify -P itest" in IntelliJ
> > >>> terminal, the execution time is around an hour. This is because this
> > >>> command starts and stops the Spring Test Runner Server on every class
> > >>> (which is not my desired result).
> > >>>
> > >>> The IntelliJ second click -> Run all Tests starts it only once. Our
> Jenkins
> > >>> Job is running the tests with "mvn verify -P itest", so my question
> is how
> > >>> can i change this behavior, to start and stop the Test Runner only
> once
> > >>> (with this "mvn verify -P itest" command).
> > >>>
> > >>> itest is the profile that we have in our pom.xml which includes the
> classes
> > >>> that contain integration tests (using maven failsafe plugin)
> > >>>
> > >>> Here are the annotations of our base abstract Integration Test class
> > >>>
> > >>> @RunWith(SpringJUnit4ClassRunner.class)
> > >>> @SpringBootTest(classes = MainApplication.class, webEnvironment =
> > >>> WebEnvironment.RANDOM_PORT)
> > >>>
> > >>> I found this article which could by similar to my problem, but this
> does
> > >>> not explain the behavior that IntelliJ gives me.
> > >>>
> > >>> Reset Spring-Boot During Integration Tests
> > >>> <
> https://stackoverflow.com/questions/44241936/reset-spring-boot-during-integration-tests
> >
> > >>>
> > >>> Thanks a lot in advance
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: users-h...@maven.apache.org
> > >>
> > >>
> > >
> > >itest
> > >
> > >false
> > >
> > >
> > >
> > >
> > >maven-failsafe-plugin
> > >
> > >1
> > >false
> > >${args}
> > >
> none:none
> > >
> > >**/*ITests.java
> > >
> **/*IntegrationTests.java
> > >
> true
> > >
> > >
> > >
> ${basedir}/target/test-classes
> > >
> localhost
> > >
> > >
> > >
> > >
> > >
> > >integration-test
> > >verify
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Here is the config for my Failsafe plugin.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> I am having like like ~40 Classes with ~10-15 methods in each.
> I am running JUnit 4, and no i am not using Parallel Mode in Intellij.
> In the logs i see the spring context being created & destro
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi Hervé, and thanks for your reply! So it sounds like since
maven-shade-plugin still has not been updated to use the new API, the
problem should still be there. But did you check my test project? I thought
it would capture the problem, if it was still there and I understood it
correctly, but I guess the project is bogus somehow since it doesn't
capture the issue. I would like to understand how my test project is faulty
so I understand the issue properly. Is there a Jira for maven-shade-plugin
which tracks the issue (an issue which could be solved by using the new API
you mentioned)?
Regards, Mikael
On Sun, Jan 13, 2019, 10:43 Hervé BOUTEMY Hi
>
> Good question: I did not yet find the official answer, but I can share
> what I
> know on this.
>
> flatten-maven-plugin has the exact same issue, and this was fixed in the
> past
> by adding a new API in Maven core (in 3.2.5) to be called by the plugin:
> see https://github.com/mojohaus/flatten-maven-plugin/pull/30
>
> I just had a look at maven-shade-plugin source and found "project.setFile(
> dependencyReducedPomLocation );": this call has not been replaced by
> setPomFile() API.
> That means that the limitation on the chosen directory should still be here
>
> Hope this helps...
>
> Regards,
>
> Hervé
>
> Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit :
> > Hi, the documentation for dependencyReducedPomLocation says:
> > "Where to put the dependency reduced pom. Note: setting a value for
> > this parameter with a directory other than ${basedir} will change the
> > value of ${basedir} for all executions that come after the shade
> > execution. This is often not what you want. This is considered an open
> > issue with this plugin."
> >
> >
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen
> > cyReducedPomLocation
> >
> > I created a small test project which performs a shade in the package
> > phase (with the dependencyReducedPomLocation set to the
> > ${project.build.directory} and then I print the value (using
> > gmavenplus-plugin) of ${project.basedir} in the verify phase (which
> > comes after package as you know). I don't see that the value of
> > basedir has changed (which is good), is this part of the documentation
> > incorrect or is my test project wrong (i.e., did I misunderstood the
> > possibly undesirable side-effect to ${basedir} by setting
> > dependencyReducedPomLocation)?
> >
> > You can find my test project here:
> https://github.com/masberg/mshadeissue
> >
> > - Mikael
> >
> > -
> > 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
>
>
Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi, the documentation for dependencyReducedPomLocation says:
"Where to put the dependency reduced pom. Note: setting a value for
this parameter with a directory other than ${basedir} will change the
value of ${basedir} for all executions that come after the shade
execution. This is often not what you want. This is considered an open
issue with this plugin."
https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
I created a small test project which performs a shade in the package
phase (with the dependencyReducedPomLocation set to the
${project.build.directory} and then I print the value (using
gmavenplus-plugin) of ${project.basedir} in the verify phase (which
comes after package as you know). I don't see that the value of
basedir has changed (which is good), is this part of the documentation
incorrect or is my test project wrong (i.e., did I misunderstood the
possibly undesirable side-effect to ${basedir} by setting
dependencyReducedPomLocation)?
You can find my test project here: https://github.com/masberg/mshadeissue
- Mikael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
