Re: Want to understand the .dumpstream file contents
I forgot to mention: In 3.0.0-M5 it can even make the whole JVM hang when using SurefireForkNodeFactory, see Jira. So if you want to use SurefireForkNodeFactory in setups where the JVM or an agent writes to the system console, you want to be sure to sue a current M6 snapshot or build your own temporary release locally. Without the SurefireForkNodeFactory, Surefire 3 behaves like 2.22.2, creating those ugly dump files. -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 12.03.2022 12:49 (GMT +07:00): > Oh yes, it is Maven-specific. Surefire-specific, to be more precise. If > in Surefire/Failsafe tests there is any JVM logging before Surefire has > wired up its own setup for how to handle system console logs on stdOut > and stdErr, or even if that happens afterwards, the JVM logging to the > original system console instead of the print stream assigned to it by > Surefire, this stuff ends up in dump files, AFAIR decorated with stuff > like warnings and timestamps. In 2.22.2, this cannot be avoided. For > 3.0.0-M6 (try the latest master snapshots), I have been pestering Tibor > with fixing this, at least when using > > implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/> > > See also: > https://issues.apache.org/jira/browse/SUREFIRE-1788 > https://issues.apache.org/jira/browse/SUREFIRE-1881 > > BTW, when I say "JVM logging", I really mean that. It could be the JRE > itself logging something, e.g. if you activate certain logs in the JVM, > e.g. or SSL connections or for class-loading via JVM parameter > > -verbose:class > > Of course, a Java agent is also a special case in which the JVM logs > something, which Surefire does not expect. But this problem is not > limited to Java agents, see above and see the Jira issues. There is too > much information in Jira to quote here, but please read it if you are > affected. > > > Bernd Eckenfels schrieb am 12.03.2022 08:06 (GMT +07:00): > >> Hello, >> >> Sounds like the default console logger for the JUL root gets the events and >> writes them to stdout. >> >> Did you try to use an anonymous logger or specify setUseParentHandler(false) >> on >> your trace logger? >> >> Doesn’t sound very surefire or maven specific, that would also happen in a >> stand alone execution. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> Von: Laurian Angelescu >> Gesendet: Friday, March 11, 2022 3:56:16 PM >> An: users@maven.apache.org >> Betreff: Want to understand the .dumpstream file contents >> >> >> I've built a trivial Java agent that uses java.util.logging.Logger and a >> FileHandler to trace out the program into a log file. I've attached a log >> file >> produced as a sample: agent_03112022_064424.log. >> >> The point is to run some tests under instrumentation. To do so I run: >> >> mvn test -DargLine="-javaagent:C:\JARS\agent.jar" on a target project, also >> built with Maven, to run a test suite under instrumentation. After >> completion, >> the folder /target/surefire-reports contains file >> 2022-03-11T07-01-03_983.dumpstream which contains similar information to the >> agent_03 log file. >> >> I want to understand why the surefire dumpstream contains the traces I am >> outputting using the logger in my agent code (to the agent_03 file)? The >> agent >> is a self-contained JAR and is outputting to its own file. The surefire >> plugin >> is running tests on a completely different package. >> >> The second question is how do I turn it off? >> > > - > 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: Want to understand the .dumpstream file contents
Oh yes, it is Maven-specific. Surefire-specific, to be more precise. If in Surefire/Failsafe tests there is any JVM logging before Surefire has wired up its own setup for how to handle system console logs on stdOut and stdErr, or even if that happens afterwards, the JVM logging to the original system console instead of the print stream assigned to it by Surefire, this stuff ends up in dump files, AFAIR decorated with stuff like warnings and timestamps. In 2.22.2, this cannot be avoided. For 3.0.0-M6 (try the latest master snapshots), I have been pestering Tibor with fixing this, at least when using See also: https://issues.apache.org/jira/browse/SUREFIRE-1788 https://issues.apache.org/jira/browse/SUREFIRE-1881 BTW, when I say "JVM logging", I really mean that. It could be the JRE itself logging something, e.g. if you activate certain logs in the JVM, e.g. or SSL connections or for class-loading via JVM parameter -verbose:class Of course, a Java agent is also a special case in which the JVM logs something, which Surefire does not expect. But this problem is not limited to Java agents, see above and see the Jira issues. There is too much information in Jira to quote here, but please read it if you are affected. -- Alexander Kriegisch https://scrum-master.de Bernd Eckenfels schrieb am 12.03.2022 08:06 (GMT +07:00): > Hello, > > Sounds like the default console logger for the JUL root gets the events and > writes them to stdout. > > Did you try to use an anonymous logger or specify setUseParentHandler(false) > on > your trace logger? > > Doesn’t sound very surefire or maven specific, that would also happen in a > stand alone execution. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Laurian Angelescu > Gesendet: Friday, March 11, 2022 3:56:16 PM > An: users@maven.apache.org > Betreff: Want to understand the .dumpstream file contents > > > I've built a trivial Java agent that uses java.util.logging.Logger and a > FileHandler to trace out the program into a log file. I've attached a log file > produced as a sample: agent_03112022_064424.log. > > The point is to run some tests under instrumentation. To do so I run: > > mvn test -DargLine="-javaagent:C:\JARS\agent.jar" on a target project, also > built with Maven, to run a test suite under instrumentation. After completion, > the folder /target/surefire-reports contains file > 2022-03-11T07-01-03_983.dumpstream which contains similar information to the > agent_03 log file. > > I want to understand why the surefire dumpstream contains the traces I am > outputting using the logger in my agent code (to the agent_03 file)? The agent > is a self-contained JAR and is outputting to its own file. The surefire plugin > is running tests on a completely different package. > > The second question is how do I turn it off? > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Want to understand the .dumpstream file contents
Hello, Sounds like the default console logger for the JUL root gets the events and writes them to stdout. Did you try to use an anonymous logger or specify setUseParentHandler(false) on your trace logger? Doesn’t sound very surefire or maven specific, that would also happen in a stand alone execution. Gruss Bernd -- http://bernd.eckenfels.net Von: Laurian Angelescu Gesendet: Friday, March 11, 2022 3:56:16 PM An: users@maven.apache.org Betreff: Want to understand the .dumpstream file contents I've built a trivial Java agent that uses java.util.logging.Logger and a FileHandler to trace out the program into a log file. I've attached a log file produced as a sample: agent_03112022_064424.log. The point is to run some tests under instrumentation. To do so I run: mvn test -DargLine="-javaagent:C:\JARS\agent.jar" on a target project, also built with Maven, to run a test suite under instrumentation. After completion, the folder /target/surefire-reports contains file 2022-03-11T07-01-03_983.dumpstream which contains similar information to the agent_03 log file. I want to understand why the surefire dumpstream contains the traces I am outputting using the logger in my agent code (to the agent_03 file)? The agent is a self-contained JAR and is outputting to its own file. The surefire plugin is running tests on a completely different package. The second question is how do I turn it off?
Re: Dependency version change on dependency import
Rimvydas Vaidelis wrote: > I have a multi-module project and I want to create a bill of materials > (BOM) module. BOM module contains dependencyManagement. My parent module > imports BOM module. BOM module will be used in another project that is > going to use my library. In development environment I would like to change > version of one dependency. I tried to do that using a profile but it seems > that maven does not activate the profile while performing import. Is it a > normal behavior? Maybe you could recommend any other way to implement > dependency version change in development environment. I believe you can add a regular dependency entry for the artifact for which you want to override the version, like this: com.example example-bom 1.0.0 pom import com.example example-artifact-from-bom-i-want-to-override 1.1.0-SNAPSHOT com.example example-artifact-managed-by-bom com.example example-artifact-from-bom-i-want-to-override Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Want to understand the .dumpstream file contents
I've built a trivial Java agent that uses java.util.logging.Logger and a FileHandler to trace out the program into a log file. I've attached a log file produced as a sample: agent_03112022_064424.log. The point is to run some tests under instrumentation. To do so I run: *mvn test -DargLine="-javaagent:C:\JARS\agent.jar" *on a target project, also built with Maven, to run a test suite under instrumentation. After completion, the folder /target/surefire-reports contains file 2022-03-11T07-01-03_983.dumpstream which contains similar information to the agent_03 log file. I want to understand why the surefire dumpstream contains the traces I am outputting using the logger in my agent code (to the agent_03 file)? The agent is a self-contained JAR and is outputting to its own file. The surefire plugin is running tests on a completely different package. The second question is how do I turn it off? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Trying out new verbose dependency tree: very slow result
Very happy to report that this was resolved in the just-released 3.3.0. See https://issues.apache.org/jira/browse/MDEP-761. Verbose dependency tree works great now! Thanks to everyone who worked on it, including Ian Lavallee for reimplementing it for Maven 3 and Filipe Roque for the fix so that it doesn't hang. On Wed, Jun 2, 2021 at 1:36 PM Ken Warkentyne wrote: > I built the plugin from HEAD and ran some tests. > > Getting the dependency tree for a simple project (e.g. single module, no > parent, no extra repositories) was fast. Here is the pom: > > 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 > test > testa > 1.0 > jar > > > commons-collections > commons-collections > 3.2.1 > > > commons-beanutils > commons-beanutils > 1.9.1 > > > > > Running the plugin with this pom.xml and verbose enabled took just over a > second. > > I added the dependency: > > > ch.qos.logback > logback-classic > 1.2.3 > > > After this change, processing took 14 seconds in verbose mode. Non-verbose > mode took < 1 second. > > I also tried the plugin with a simple Spring Boot starter pom: > 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 > test > hello-world-spring-boot > 0.0.1-SNAPSHOT > > org.springframework.boot > spring-boot-starter-parent > 2.1.6.RELEASE > > > > org.springframework.boot > spring-boot-starter-web > > > > > I waited for about 5 minutes before killing the job. > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
[ANN] Apache Maven Dependency Plugin 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin, version 3.3.0 This plugin provides utility goals to work with dependencies like copying, unpacking, analyzing, resolving and many more. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.3.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes - Maven Dependency Plugin - Version 3.3.0 ** Bug * [MDEP-679] - mvn dependency:analyze detected wrong transitive dependency * [MDEP-742] - dependency plugin does not work with JDK 16 * [MDEP-752] - skip dependency analyze in ear packaging * [MDEP-753] - Non-test dependency reported as Non-test scoped test only dependency * [MDEP-759] - 'Dependency not found' with 3.2.0 and Java-17 while analyzing * [MDEP-761] - Tree plugin does not terminate with 3.2.0 * [MDEP-769] - Minor improvement - continue * [MDEP-774] - analyze-only failed: PermittedSubclasses requires ASM9 * [MDEP-781] - Broken Link to "Introduction to Dependency Mechanism Page" * [MDEP-783] - TreeMojo docs say scope doesn't work due to MSHARED-4 * [MDEP-786] - Sealed classes not supported ** New Feature * [MDEP-787] - Allow ignoring non-test-scoped dependencies ** Improvement * [MDEP-763] - Minor improvements * [MDEP-768] - GitHub Action build improvement * [MDEP-779] - dependency:analyze should list the classes that cause a used undeclared dependency * [MDEP-789] - Improve documentation of analyze - Non-test scoped ** Task * [MDEP-760] - Java 1.8 as minimum ** Dependency upgrade * [MDEP-766] - Upgrade maven-invoker-plugin to version 3.2.2 * [MDEP-784] - Upgrade maven-dependency-analyzer to 1.12.0 * [MDEP-788] - Upgrade maven-reporting-impl to version 3.1.0 * [MDEP-795] - Update Jetty to 9.4.45.v20220203 * [MDEP-796] - Upgrade Maven Parent to 35 * [MDEP-797] - Update transitive dependency commons-beanutils to 1.9.4 * [MDEP-798] - Upgrade maven-dependency-tree from 3.0.1 to 3.1.0 Enjoy, -The Apache Maven team
