apache / maven-mvnd Goto Github PK

View Code? Open in Web Editor NEW

2.7K 2.7K 197.0 3.13 MB

Apache Maven Daemon

Home Page: https://maven.apache.org/

License: Apache License 2.0

Shell 3.70% Java 94.19% Groovy 0.08% Makefile 0.84% C 1.18%

apache-maven build-management java maven

maven-mvnd's People

Contributors

Stargazers

Watchers

Forkers

ppalaga maxandersen vietk gnodet helpermethod johnpoth oscerd ybroeker zulkar famod fg78nc michael-simons cybernetics isaacyan tchigher diegopacheco devenlu dsyer desmax74 karthickramk kosmoflyko lucamolteni php-coder rmannibucau valdar jjlharrison lanmaoxinqing findepi hapag-lloyd jeffjensen charygao nicoloboschi nikolalefterov joel113 apanatshka shisheng-1 mateusz-bajorek michaelriedel vorburger cheeghi sola96 qilluo5741 mxuexxmy fangxianhlhh zjuzengkun canyouspeakenglish sealte guoamocker lcy19930619 mu-l misselvexu ceruto yxxcrtd ai2hub slcnx itboots eduardoquelhas deniszomarev skrstop huyiming-0115 changsongyang xs-fork pptom kezhenxu94 lujiefsi iuriimattos2 tummuriphanindra jesley-sun kukunuriakhila josways abcijkxyz astra-zhao shaunstanislauslau kornelrabczak robertk3s davidchan1201 leo-shenliang jhbsz tianjx98 q736145814 lkwg82 waerly felix-ma aalmiray dongjiajun6 aeroyu dreamonly-kell giiiiiithub qf8505 andyglick itasks s947267355 meizuamy sweetcard lishiyucn binyangchen vmikhnevych xiangjin2020 hj3938 yubobo

maven-mvnd's Issues

Re-layout the distro so that mvn is not in bin

The idea was proposed by @rmannibucau on [email protected]

relayout the distribution: mvnd/bin does not contain mvn but set maven.home to a folder not in path with mvn script.

Options / system properties are not reset in the daemon after a build

For example if you build with -DskipTests, and then build without the option, the daemon will set the system property in its jvm without resetting it after the build. The behavior is that the second build is also built without tests.

Provide an option to kill/stop the daemon

Gradle has the option gradle --stop. It would be better if mvnd has an option --stop to kill the daemon as well.

Add a correct NOTICE file

Explain that the code has been freely adapted from various ASL license projects:

org.jboss.fuse.mvnd.builder from https://github.com/takari/takari-smart-builder
org.jboss.fuse.mvnd.daemon from https://github.com/gradle/gradle/tree/master/subprojects/launcher
org.jboss.fuse.mvnd.logging from https://github.com/takari/concurrent-build-logger
org.jboss.fuse.mvnd.timing from https://github.com/timgifford/maven-buildtime-extension
org.jboss.fuse.mvnd.jpm from https://github.com/takari/concurrent-build-logger

Do not display exceptions stack trace when trying to stop already stopped daemons

Keep a changelog file

It would be very cool if you can keep a Changelog file to keep track of all the changes that are done through the different releases.

Chaotic output if the console's height is less then the number of threads

I got a new machine with 24 threads which leads to a funny consequence:

When mvnd is run in a console window with less rows than the number of threads, then the output is very chaotic. The updates appear on random places of the terminal. It is surely reproducible also on machines withe less threads, if the console window is made small enough.

This is just a UI issue. The build works correctly otherwise.

differences between `mvn clean install` and `mvnd clean install`

I used mvnd clean install -DskipTests -DskipITs -Dquarkus.build.skip -DskipDocs -Denforcer.skip twice in quarkus root now and both times I don't seem to end up with jars/classes in the ~/.m2 repo that corresponds to what mvn clean install brings.

The way I realize there is an issue is that breakpoints were not being hit and main diff was that newly updated code from a pull request did not seem to be included in the build.

My best guess is that mvnd might do some time comparison and the PR's files are from before last build thus they are not included in the build or something similar ?

I wish I could be more precise :)

Provide a `mvnd.noDaemon` option to disable daemon for easier debugging

It would be useful if we could skip the client/server stuff to more easily debug the daemon.

Using MAVEN_HOME may clash with other tools

As part of the installation process [1], the last command is to run mvnd --install.
This is returning the following error:

Exception in thread "main" java.lang.IllegalStateException: Cannot install if mvnd.home /opt/sdkman/candidates/maven/current exists. Delete it if you want to reinstall.
at org.jboss.fuse.mvnd.client.Installer.installServer(Installer.java:55)
at org.jboss.fuse.mvnd.client.DefaultClient.install(DefaultClient.java:98)
at org.jboss.fuse.mvnd.client.DefaultClient.execute(DefaultClient.java:152)
at org.jboss.fuse.mvnd.client.DefaultClient.main(DefaultClient.java:68)

The reported directory is my current installation. It seems that this happens because the variable MAVEN_HOME is set in my environment.

I see that mvnd --install created a bin directory under .m2/mvnd/<version>. But I don't understand why the failure, particularly as MAVEN_HOME is a variable for maven1, and mvnd claims to be a maven 3+.

Can you explain the reason for such a design? As I plan to call mvnd explicitly instead of mvn, I don't want to enforce a path to the provided maven script.

[1] https://github.com/mvndaemon/mvnd#install-mvnd

Class loader clash during Quarkus augmentation

Steps to reproduce

git clone https://github.com/apache/camel-quarkus.git
cd camel-quarkus
mvnd clean install -DskipTests -e

Sometimes the following error occurs in one or more modules:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:1.3.0.Alpha2:build (default) on project camel-quarkus-integration-test-snakeyaml: Failed to build quarkus application: java.lang.IllegalStateException: Configuration already registered for the given class loader -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal io.quarkus:quarkus-maven-plugin:1.3.0.Alpha2:build (default) on project camel-quarkus-integration-test-snakeyaml: Failed to build quarkus application
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
        at org.jboss.fuse.mvnd.builder.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:176)
        at org.jboss.fuse.mvnd.builder.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:196)
        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: Failed to build quarkus application
        at io.quarkus.maven.BuildMojo.execute(BuildMojo.java:185)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
        ... 10 common frames omitted
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Configuration already registered for the given class loader
        at io.quarkus.runner.bootstrap.AugmentActionImpl.runAugment(AugmentActionImpl.java:206)
        at io.quarkus.runner.bootstrap.AugmentActionImpl.createProductionApplication(AugmentActionImpl.java:77)
        at io.quarkus.maven.BuildMojo.execute(BuildMojo.java:172)
        ... 12 common frames omitted
Caused by: java.lang.IllegalStateException: Configuration already registered for the given class loader
        at io.smallrye.config.SmallRyeConfigProviderResolver.registerConfig(SmallRyeConfigProviderResolver.java:128)
        at io.quarkus.runtime.configuration.QuarkusConfigFactory.setConfig(QuarkusConfigFactory.java:48)
        at io.quarkus.deployment.ExtensionLoader.loadStepsFrom(ExtensionLoader.java:195)
        at io.quarkus.deployment.QuarkusAugmentor.run(QuarkusAugmentor.java:89)
        at io.quarkus.runner.bootstrap.AugmentActionImpl.runAugment(AugmentActionImpl.java:204)
        ... 14 common frames omitted

It might be a fault of the quarkus-maven-plugin but I wanted to consult here before reporting in Quarkus. WDYT @gnodet ?

mvnd -version does not work

I'd expect mvnd -version to return the same output as mvn -version, but it just hangs.

Require Java 8+ instead of Java 11+ at runtime

We require Java 11 at runtime since #55 where we started using ProcessHandle.current().info().command(). Because it is just the client code, we could do some module splitting and require Java 11 only for the compilation of that code. The resulting native executable is java-version agnostic and the rest of the jars could then be runnable on Java 8.

The output of modules being built in parallel is interleaved

mvnd should fail cleanly with unknown CLI options

Thanks for fixing #2 . I just learned that -v and --version are documented on https://maven.apache.org/ref/3.1.0/maven-embedder/cli.html while -version is not.

However with the stock Maven -version works too. I am not saying mvnd should support -version, decide yourself.

The problem is that -version still hangs, same as with --foo So mvnd should fail cleanly with unknown options, preferably showing the cli options like the stock mvn does.

Allow to plug a custom rule resolver

As today to provide rules one has to create a property like:

<mvnd.builder.rule>
    camel-quarkus-core-xml-deployment,camel-quarkus-file-deployment,camel-quarkus-log-deployment,camel-quarkus-support-policy-deployment,camel-quarkus-timer-deployment
</mvnd.builder.rule>

Would be nice if mvnd would allow to plug a custom rule resolver so that there won't be the need to pollute poms.

As the example above is taken from camel-quarkus, one could develop a custom resolver that could compute the rules from the dependencies.

The test output is missing in the console

The output of a Camel Quarkus integration test is missing in the console.

Steps to reproduce:

git clone https://github.com/apache/camel-quarkus.git
cd camel-quarkus
mvnd clean install -DskipTests
cd integration-tests/base64
mvnd clean test

The actual output is

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]

Note that there is no output of the booting app and no output of the test. I'd expect the output to be much like with plain mvn:

mvn clean test
...
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.camel.quarkus.component.base64.it.Base64Test
2020-02-25 08:35:05,077 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Apache Camel 3.0.1 (CamelContext: camel-1) is starting
2020-02-25 08:35:05,078 INFO  [org.apa.cam.imp.eng.DefaultManagementStrategy] (main) JMX is disabled
2020-02-25 08:35:05,118 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2020-02-25 08:35:05,121 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Route: route1 started and consuming from: direct://start
2020-02-25 08:35:05,124 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Total 1 routes, of which 1 are started
2020-02-25 08:35:05,125 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Apache Camel 3.0.1 (CamelContext: camel-1) started in 0.048 seconds
2020-02-25 08:35:05,127 INFO  [io.quarkus] (main) Quarkus 1.3.0.Alpha2 started in 1.466s. Listening on: http://0.0.0.0:35711
2020-02-25 08:35:05,128 INFO  [io.quarkus] (main) Profile test activated. 
2020-02-25 08:35:05,128 INFO  [io.quarkus] (main) Installed features: [camel-base64, camel-core, camel-direct, camel-policy, camel-support-common, cdi, resteasy]
2020-02-25 08:35:06,019 INFO  [org.apa.cam.qua.com.bas.it.Base64Resource] (executor-thread-1) Sending to base64: Hello World
2020-02-25 08:35:06,036 INFO  [org.apa.cam.qua.com.bas.it.Base64Resource] (executor-thread-1) Got response from base64: SGVsbG8gV29ybGQ

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.734 s - in org.apache.camel.quarkus.component.base64.it.Base64Test
2020-02-25 08:35:06,122 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Apache Camel 3.0.1 (CamelContext: camel-1) is shutting down
2020-02-25 08:35:06,126 INFO  [org.apa.cam.mai.MainLifecycleStrategy] (main) CamelContext: camel-1 has been shutdown, triggering shutdown of the JVM.
2020-02-25 08:35:06,129 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Apache Camel 3.0.1 (CamelContext: camel-1) uptime 1.052 seconds
2020-02-25 08:35:06,129 INFO  [org.apa.cam.qua.cor.FastCamelContext] (main) Apache Camel 3.0.1 (CamelContext: camel-1) is shutdown in 0.007 seconds
2020-02-25 08:35:06,166 INFO  [io.quarkus] (main) Quarkus stopped in 0.044s
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]

Checking target/surefire-reports seems to suggest that the test was run, so this is probably just the matter of the missing output.

Do not require the mvn in PATH to come from mvnd dist

To avoid some bugs in mvnd I'd like to use the stock Maven via mvn in my PATH.

ACTUAL:
Currently both mvnd and mvn in the PATH must point to the scripts from the mvnd distro for mvnd to work. If the mvn in my PATH points to the stock Maven then mvnd stops working.

If I use mvn from the mvnd distro it seems to behave like mvnd - which I assume does not help me to avoid the mvnd bugs.

EXPECTED:
It should be enough to have mvnd in the path for mvnd to work. mvn should stay pointing at the stock Maven.

Concurrency issues while handling log events in the daemon

Support for failsafe?

I noticed that our integration tests do not run when using mvnd.

Not knowing anything Maven internals and the challenges of running these in parallel, I am not sure if:

it's a bug,
working as designed
a problem on our own build configuration.

Could you, please, share some insights? Should the integration test execution, managed by the failsafe plugin, be supported?

Add a LICENSE file

... because it is not clear at all what the license is.

Goals of mvnd

Do you have some goals in mind for mvnd? The introduction in the Readme states that this project borrows some techniques from Gradle and Takari.
Reading about the two projects, I see that Takari helps for parallel jobs, and Gradle has many features.

For example, do you plan to record the state of a maven project to automatically build changed modules?
Do you limit the scope to a daemon skipping the initialization of the VM and the parsing of the project?

Maven mojo change ignored

An itest reproducing the issue: #34

mvnd fails if there is no .mvn/ dir in the user home

Right after mvnd --install, mvnd fails with the following error:

$ mvnd --version
Maven Daemon 0.0.0 (native)
Exception in thread "main" java.lang.IllegalStateException: Could not detect maven.multiModuleProjectDirectory by climbing up from [/home/tasato] seeking a .mvn directory. You may want to create a .mvn directory in the root directory of your source tree.
	at org.jboss.fuse.mvnd.client.Environment.lambda$findMultiModuleProjectDirectory$4(Environment.java:127)
	at org.jboss.fuse.mvnd.client.Environment$EnvValue.get(Environment.java:246)
	at org.jboss.fuse.mvnd.client.Environment$EnvValue.asPath(Environment.java:258)
	at org.jboss.fuse.mvnd.client.Environment.findMultiModuleProjectDirectory(Environment.java:131)
	at org.jboss.fuse.mvnd.client.ClientLayout.getEnvInstance(ClientLayout.java:45)
	at org.jboss.fuse.mvnd.client.DefaultClient.lambda$main$0(DefaultClient.java:69)
	at org.jboss.fuse.mvnd.client.DefaultClient.execute(DefaultClient.java:170)
	at org.jboss.fuse.mvnd.client.DefaultClient.main(DefaultClient.java:69)

Manually creating a directory .mvn/ in the user home solves the error, but it's handy if mvnd auto resolves it.

Question: when running mvnd, it looks like regular mvn is still running

Hi!
This looks like a really cool project and I'm excited to try it out. However after following the instructions to installing, I still get this output when running mvnd --version:

 ✘ kesorupert  ~  mvnd --version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 1.8.0_262, vendor: AdoptOpenJDK, runtime: /Users/kesorupert/.sdkman/candidates/java/8.0.262.hs-adpt/jre
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"

I added the mvn daemon bin folder to my PATH variable. I also tried using an alias for mvnd that pointed specifically to the mvnd executable inside the bin folder.
I'm using Oh-my-ZSH, so I thought that there maybe was some correcting going on, but disabling that using "nocorrect" and other options, all resulted in the same output.

Any idea on what I'm missing when setting this up?

Warning "Unable to create a system terminal" when running maven daemon

Releases 0.0.0
Windows 10

Running any command produces a warning, regardlerss the command succeeds or not

For example:

E:\dev\g5rt\runtime>"E:\Program Files\mvnd\mvnd-windows-amd64" --status
Jun 29, 2020 3:10:51 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
UUID PID Port Status Last activity

CachingProjectBuilder ignored

Our CachingProjectBuilder is ignored. The default Maven's cache-all-forever DefaultProjectBuilder is being picked instead. As a consequence of that, e.g. the changes in BoM are ignored (see #9 ).

The cause is that our distro contains many libs in lib/ext that are available also in lib, among others maven-core that brings DefaultProjectBuilder - that's why DefaultProjectBuilder wins. The solution is to remove all duplicates from lib/ext.

A PR follows.

Replace deprecated GitHub actions commands

We should modify our workflows as per:

https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

Cannot build Quarkus after removing ~/.m2/repository/io/quarkus/ or ~/.m2/repository/io/quarkus/gizmo

Steps to reproduce

rm -Rf ~/.m2/repository/io/quarkus/gizmo
git clone https://github.com/quarkusio/quarkus.git
cd quarkus
mvnd clean install -DskipTests -DskipITs -Denforcer.skip -Dquarkus.build.skip -DskipDocs

Expected: build success
Actual: ArC Processor and Qute Generator are complaining about missing gizmo during compilation:

[�[1;31mERROR�[m] Failed to execute goal �[32morg.apache.maven.plugins:maven-compiler-plugin:3.8.0-jboss-2:compile�[m �[1m(default-compile)�[m on project �[36mqute-generator�[m: �[1;31mCompilation failure�[m: Compilation failure: 
[�[1;31mERROR�[m] /home/ppalaga/orgs/quarkus/quarkus/independent-projects/qute/generator/src/main/java/io/quarkus/qute/generator/ValueResolverGenerator.java:[5,24] package io.quarkus.gizmo does not exist
...

[�[1;31mERROR�[m] Failed to execute goal �[32morg.apache.maven.plugins:maven-compiler-plugin:3.8.0-jboss-2:compile�[m �[1m(default-compile)�[m on project �[36marc-processor�[m: �[1;31mCompilation failure�[m: Compilation failure: 
[�[1;31mERROR�[m] /home/ppalaga/orgs/quarkus/quarkus/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/AnnotationLiteralProcessor.java:[4,24] package io.quarkus.gizmo does not exist

It is very strange that there is no trace of gizmo in the local maven repo under ~/.m2/repository/io/quarkus/gizmo I'd expect maven to download it. I do not see any download related error in the log.

List mvnd on sdkman.io

Citing @gastaldi:

it would be nice to have it listed in sdkman.io

Volunteers?

Add some integration tests

I am considering to create a JUnit runner. To do that, I'd need to add a Maven module. So, if you @gnodet have something to push, please push.

Publish new versions via sdkman vendor API

https://sdkman.io/vendors

Show test output while running

Currently test output it showed after all tests are run. If one have lots of tests, its useful to see what is going on while running tests and possibly interrupt the build early if some test fails. This would save lot of time and on failures and provide the status of build while it running.

Right now, one have always wait until the end of mvnd build to see if some tests failed.

Cannot re-use daemon with sdkman java 8.0.265.hs-adpt

I've just started using mvn and noticed from the logs that, there are incompatible daemons due to the javaHome

$ mvnd --version                                                                                            
Sep 15, 2020 10:23:33 AM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Idle daemon 23a8041a-705b-48d6-8fd7-4b01b7f49ddf does not match the desired criteria: Java home is different.
Wanted: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt, options=[]
Actual: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre, options=[], mavenHome=/home/alext/.sdkman/candidates/mvnd/0.4.0, pid=153885, address=36049, idleTimeout=10800000, locale=en-US, state=Idle, lastIdle=1600129199872, lastBusy=1600129170749uid=23a8041a-705b-48d6-8fd7-4b01b7f49ddf

[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Idle daemon fa3a910f-f224-4242-b56e-98b112f851a3 does not match the desired criteria: Java home is different.
Wanted: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt, options=[]
Actual: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre, options=[], mavenHome=/home/alext/.sdkman/candidates/mvnd/0.4.0, pid=150998, address=33263, idleTimeout=10800000, locale=en-US, state=Idle, lastIdle=1600128961673, lastBusy=1600128960395uid=fa3a910f-f224-4242-b56e-98b112f851a3

[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Idle daemon 96a3257f-b375-47eb-bfb8-71273e43f6ac does not match the desired criteria: Java home is different.
Wanted: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt, options=[]
Actual: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre, options=[], mavenHome=/home/alext/.sdkman/candidates/mvnd/0.4.0, pid=151587, address=35369, idleTimeout=10800000, locale=en-US, state=Idle, lastIdle=1600129091986, lastBusy=1600129022672uid=96a3257f-b375-47eb-bfb8-71273e43f6ac

[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Idle daemon 1fb27912-2bca-4f46-93cd-c43da854b9e1 does not match the desired criteria: Java home is different.
Wanted: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt, options=[]
Actual: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre, options=[], mavenHome=/home/alext/.sdkman/candidates/mvnd/0.4.0, pid=154243, address=38191, idleTimeout=10800000, locale=en-US, state=Idle, lastIdle=1600129327995, lastBusy=1600129327949uid=1fb27912-2bca-4f46-93cd-c43da854b9e1

[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Idle daemon 78630163-9886-48a3-bd22-b58e06bd3ab4 does not match the desired criteria: Java home is different.
Wanted: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt, options=[]
Actual: javaHome=/home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre, options=[], mavenHome=/home/alext/.sdkman/candidates/mvnd/0.4.0, pid=154325, address=34881, idleTimeout=10800000, locale=en-US, state=Idle, lastIdle=1600129407112, lastBusy=1600129378438uid=78630163-9886-48a3-bd22-b58e06bd3ab4

[main] INFO org.jboss.fuse.mvnd.common.DaemonRegistry - Removing 0 daemon stop events from registry
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Starting a Maven Daemon, 1 busy and 5 incompatible Daemons could not be reused, use --status for details
Maven Daemon 0.0.4-linux-amd64 (native)
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/alext/.sdkman/candidates/mvnd/0.4.0
Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime: /home/alext/.sdkman/candidates/java/8.0.265.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-47-generic", arch: "amd64", family: "unix"

It sounds like every time I ran mvnd, there is a new daemon created but incompatible to be reused?

${my.property:-default} style defaults defined in logback.xml do not work

I wanted to add something like the following to logback.xml, but it does not work

  <!-- Allow increasing mvnd log level from command line -->
  <logger name="org.jboss.fuse.mvnd" level="${mvnd.log.level:-INFO}" />

With the above setting and -Dmvnd.log.level=DEBUG passed via CLI, the log level is not set to DEBUG.

When I change it to

  <logger name="org.jboss.fuse.mvnd" level="${mvnd.log.level}" />

-Dmvnd.log.level=DEBUG works as expected, but building without -Dmvnd.log.level=DEBUG (as expected per logback docs) leads to org.jboss.fuse.mvnd being set to DEBUG anyway, which is not nice.

Client hangs forever if the daemon crashes

The daemon may crash for whatever reason, even without calling shutdown hooks. There should be a way for the client to find out that the daemon is down (so that client itself can exit).

mvnd does not pick the BoM from the source tree

The $subj is just my theory to explain what just happened to me:

I added a version-less dependency apt into a Maven module camel-quarkus-platform-http-component. I also added apt properly versioned into the dependencyManagement of camel-quarkus-bom in the same source tree. Note that camel-quarkus-platform-http-component imports camel-quarkus-bom. Saved all. I am about to push the code to apache/camel-quarkus#201

mvnd clean install -DskipTests run from the top directory complained about the apt version missing in camel-quarkus-platform-http-component.

Running the same goals with the stock Maven succeeded.

So I assume the smart builder is probably not linking camel-quarkus-platform-http-component as dependent on camel-quarkus-bom.

Support for hidden dependencies

Out of a sudden, mvnd started building in parallel. You perhaps changed the defaults - no matter, I like it. Not sure why exactly this happens, but my spontaneous theory is that this is not a mistake of mnvd, but rather a mistake of how the deps are declared in Camel Quarkus. In particular, the itests do not directly or indirectly depend on the -deployment modules and mnvd is free to assume that the -deployment modules do not need to get built before the itests.

I wonder how this could be fixed in the Camel Quarkus source tree? Adding an explicit -deployment dependency to the itest project would perhaps solve the problem, but I'd find that highly unidiomatic. Do you happen to have a better idea how to fix that?

[INFO] Reactor Summary for Camel Quarkus 0.2.1-SNAPSHOT:
[INFO] 
[INFO] Camel Quarkus ...................................... SUCCESS [  0.016 s]
[INFO] Camel Quarkus :: BOM ............................... SUCCESS [  0.022 s]
[INFO] Camel Quarkus :: Build Parent ...................... SUCCESS [  0.018 s]
[INFO] Camel Quarkus :: Build Parent ...................... SUCCESS [  0.070 s]
[INFO] Camel Quarkus :: Core .............................. SUCCESS [  0.061 s]
[INFO] Camel Quarkus :: Core :: Runtime ................... SUCCESS [  1.091 s]
[INFO] Camel Quarkus :: Core :: Deployment ................ SUCCESS [  2.169 s]
[INFO] Camel Quarkus :: Support :: Jetty .................. SUCCESS [  0.121 s]
[INFO] Camel Quarkus :: Support :: Jetty :: Runtime ....... SUCCESS [  0.720 s]
[INFO] Camel Quarkus :: Support :: Jetty :: Deployment .... SUCCESS [  1.788 s]
[INFO] Camel Quarkus :: Support :: XStream ................ SUCCESS [  0.102 s]
[INFO] Camel Quarkus :: Support :: XStream :: Runtime ..... SUCCESS [  0.713 s]
[INFO] Camel Quarkus :: Support :: XStream :: Deployment .. SUCCESS [  1.865 s]
[INFO] Camel Quarkus :: Extensions ........................ SUCCESS [  0.147 s]
[INFO] Camel Quarkus :: Support ........................... SUCCESS [  0.023 s]
[INFO] Camel Quarkus :: XML :: Common ..................... SUCCESS [  0.118 s]
[INFO] Camel Quarkus :: XML :: Common :: Runtime .......... SUCCESS [  0.718 s]
[INFO] Camel Quarkus :: XML :: Common :: Deployment ....... SUCCESS [  1.135 s]
[INFO] Camel Quarkus :: Core :: Cloud ..................... SUCCESS [  0.109 s]
[INFO] Camel Quarkus :: Core :: Cloud :: Runtime .......... SUCCESS [  1.730 s]
[INFO] Camel Quarkus :: Core :: Cloud :: Deployment ....... SKIPPED
[INFO] Camel Quarkus :: HTTP :: Common .................... SUCCESS [  0.106 s]
[INFO] Camel Quarkus :: HTTP :: Common :: Runtime ......... SUCCESS [  0.709 s]
[INFO] Camel Quarkus :: HTTP :: Common :: Deployment ...... SUCCESS [  0.625 s]
[INFO] Camel Quarkus :: Netty HTTP ........................ SUCCESS [  0.172 s]
[INFO] Camel Quarkus :: Netty HTTP :: Runtime ............. SUCCESS [  1.676 s]
[INFO] Camel Quarkus :: Netty HTTP :: Deployment .......... SUCCESS [  1.560 s]
[INFO] Camel Quarkus :: Infinispan ........................ SUCCESS [  0.091 s]
[INFO] Camel Quarkus :: Infinispan :: Runtime ............. SUCCESS [  2.275 s]
[INFO] Camel Quarkus :: Infinispan :: Deployment .......... SUCCESS [  2.239 s]
[INFO] Camel Quarkus :: AWS ............................... SUCCESS [  0.101 s]
[INFO] Camel Quarkus :: AWS S3 :: Runtime ................. SUCCESS [  0.878 s]
[INFO] Camel Quarkus :: AWS S3 :: Deployment .............. SKIPPED
[INFO] Camel Quarkus :: AWS SNS ........................... SUCCESS [  0.139 s]
[INFO] Camel Quarkus :: AWS SNS :: Runtime ................ SUCCESS [  0.946 s]
[INFO] Camel Quarkus :: AWS SNS :: Deployment ............. SKIPPED
[INFO] Camel Quarkus :: AWS SQS ........................... SUCCESS [  0.137 s]
[INFO] Camel Quarkus :: AWS SQS :: Runtime ................ SUCCESS [  1.350 s]
[INFO] Camel Quarkus :: AWS SQS :: Deployment ............. SKIPPED
[INFO] Camel Quarkus :: AWS ............................... SUCCESS [  0.109 s]
[INFO] Camel Quarkus :: AWS EKS :: Runtime ................ SUCCESS [  0.854 s]
[INFO] Camel Quarkus :: AWS EKS :: Deployment ............. SKIPPED
[INFO] Camel Quarkus :: JDBC .............................. SUCCESS [  0.101 s]
[INFO] Camel Quarkus :: JDBC :: Runtime ................... SUCCESS [  0.647 s]
[INFO] Camel Quarkus :: JDBC :: Deployment ................ SUCCESS [  1.378 s]
[INFO] Camel Quarkus :: Mail .............................. SUCCESS [  0.140 s]
[INFO] Camel Quarkus :: Mail :: Runtime ................... SUCCESS [  0.536 s]
[INFO] Camel Quarkus :: Mail :: Deployment ................ SUCCESS [  1.425 s]
[INFO] Camel Quarkus :: Salesforce ........................ SUCCESS [  0.096 s]
[INFO] Camel Quarkus :: Salesforce :: Runtime ............. SUCCESS [  1.164 s]
[INFO] Camel Quarkus :: Salesforce :: Deployment .......... SUCCESS [  1.991 s]
[INFO] Camel Quarkus :: Servlet ........................... SUCCESS [  0.134 s]
[INFO] Camel Quarkus :: Servlet :: Runtime ................ SUCCESS [  2.093 s]
[INFO] Camel Quarkus :: Servlet :: Deployment ............. SUCCESS [  2.904 s]
[INFO] Camel Quarkus :: Log ............................... SUCCESS [  0.142 s]
[INFO] Camel Quarkus :: Log :: Runtime .................... SUCCESS [  0.593 s]
[INFO] Camel Quarkus :: Log :: Deployment ................. SUCCESS [  1.869 s]
[INFO] Camel Quarkus :: Direct ............................ SUCCESS [  0.089 s]
[INFO] Camel Quarkus :: Direct :: Runtime ................. SUCCESS [  0.467 s]
[INFO] Camel Quarkus :: Direct :: Deployment .............. SKIPPED
[INFO] Camel Quarkus :: Rest .............................. SUCCESS [  0.122 s]
[INFO] Camel Quarkus :: Rest :: Runtime ................... SUCCESS [  0.805 s]
[INFO] Camel Quarkus :: Rest :: Deployment ................ SUCCESS [  1.475 s]
[INFO] Camel Quarkus :: Timer ............................. SUCCESS [  0.114 s]
[INFO] Camel Quarkus :: Timer :: Runtime .................. SUCCESS [  0.473 s]
[INFO] Camel Quarkus :: Timer :: Deployment ............... SUCCESS [  1.428 s]
[INFO] Camel Quarkus :: Twitter ........................... SUCCESS [  0.134 s]
[INFO] Camel Quarkus :: Twitter :: Runtime ................ SUCCESS [  0.588 s]
[INFO] Camel Quarkus :: Twitter :: Deployment ............. SUCCESS [  1.417 s]
[INFO] Camel Quarkus :: Bean .............................. SUCCESS [  0.175 s]
[INFO] Camel Quarkus :: Bean :: Runtime ................... SUCCESS [  1.232 s]
[INFO] Camel Quarkus :: Bean :: Deployment ................ SKIPPED
[INFO] Camel Quarkus :: ZipFile ........................... SUCCESS [  0.150 s]
[INFO] Camel Quarkus :: ZipFile :: Runtime ................ SUCCESS [  0.729 s]
[INFO] Camel Quarkus :: ZipFile :: Deployment ............. SUCCESS [  1.477 s]
[INFO] Camel Quarkus :: CSV ............................... SUCCESS [  0.111 s]
[INFO] Camel Quarkus :: CSV :: Runtime .................... SUCCESS [  1.012 s]
[INFO] Camel Quarkus :: CSV :: Deployment ................. SKIPPED
[INFO] Camel Quarkus :: MicroProfile Metrics .............. SUCCESS [  0.106 s]
[INFO] Camel Quarkus :: MicroProfile Metrics :: Runtime ... SUCCESS [  1.960 s]
[INFO] Camel Quarkus :: MicroProfile Metrics :: Deployment  SUCCESS [  1.797 s]
[INFO] Camel Quarkus :: Paho .............................. SUCCESS [  0.096 s]
[INFO] Camel Quarkus :: Paho :: Runtime ................... SUCCESS [  0.808 s]
[INFO] Camel Quarkus :: Paho :: Deployment ................ SUCCESS [  1.663 s]
[INFO] Camel Quarkus :: Platform HTTP ..................... SUCCESS [  0.142 s]
[INFO] Camel Quarkus :: Platform HTTP :: Component ........ SUCCESS [  0.555 s]
[INFO] Camel Quarkus :: Platform HTTP :: Runtime .......... SUCCESS [  1.969 s]
[INFO] Camel Quarkus :: Platform HTTP :: Deployment ....... SUCCESS [  1.962 s]
[INFO] Camel Quarkus :: Integration Tests ................. SUCCESS [  0.311 s]
[INFO] Camel Quarkus :: Integration Tests :: Core :: Parent SUCCESS [  0.330 s]
[INFO] Camel Quarkus :: Integration Tests :: Core :: Extension :: Runtime SUCCESS [  1.353 s]
[INFO] Camel Quarkus :: Integration Tests :: Core :: Extension :: Deployment SUCCESS [  1.592 s]
[INFO] Camel Quarkus :: Integration Tests :: Core :: Tests  SUCCESS [  5.266 s]
[INFO] Camel Quarkus :: Integration Tests :: Core :: Impl . SUCCESS [  2.080 s]
[INFO] Camel Quarkus :: Integration Tests :: Core CDI ..... SUCCESS [  4.410 s]
[INFO] Camel Quarkus :: Integration Tests :: Netty Http ... SUCCESS [  3.386 s]
[INFO] Camel Quarkus :: Integration Tests :: AWS .......... FAILURE [  1.822 s]
[INFO] Camel Quarkus :: Integration Tests :: Bean ......... SUCCESS [  3.359 s]
[INFO] Camel Quarkus :: Integration Tests :: CSV .......... SUCCESS [  5.334 s]
[INFO] Camel Quarkus :: Integration Tests :: Infinispan ... SUCCESS [  5.739 s]
[INFO] Camel Quarkus :: Integration Tests :: JDBC ......... SUCCESS [  5.748 s]
[INFO] Camel Quarkus :: Integration Tests :: Mail ......... SUCCESS [  4.280 s]
[INFO] Camel Quarkus :: Integration Tests :: Salesforce ... SUCCESS [  5.433 s]
[INFO] Camel Quarkus :: Integration Tests :: Servlet ...... SUCCESS [  3.002 s]
[INFO] Camel Quarkus :: Integration Tests :: Twitter ...... SUCCESS [  4.669 s]
[INFO] Camel Quarkus :: Integration Tests :: zipfile ...... SUCCESS [  4.450 s]
[INFO] Camel Quarkus :: Integration Tests :: microprofile-metrics SUCCESS [  4.625 s]
[INFO] Camel Quarkus :: Integration Tests :: Paho ......... SUCCESS [  4.752 s]
[INFO] Camel Quarkus :: Integration Tests :: platform-http  SUCCESS [  3.292 s]
[INFO] Camel Quarkus :: Documentation ..................... SUCCESS [  0.005 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  18.920 s (Wall Clock)
[INFO] Finished at: 2019-10-01T17:47:14+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:0.23.1:build (default) on project camel-quarkus-integration-test-aws: Failed to build a runnable JAR: Failed to build a runner jar: Failed to augment application classes: JAR entry META-INF/quarkus-build-steps.list not found in /home/ppalaga/.m2/repository/org/apache/camel/quarkus/camel-quarkus-aws-s3-deployment/0.2.1-SNAPSHOT/camel-quarkus-aws-s3-deployment-0.2.1-SNAPSHOT.jar -> [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/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :camel-quarkus-integration-test-aws

Error when using axistools-maven-plugin

Hi i get the following error when using the axistools-maven-plugin

[ERROR] Failed to execute goal org.codehaus.mojo:axistools-maven-plugin:1.4:wsdl2java (generate-sources-axis) on project XXXX: Execution generate-sources-axis of goal org.codehaus.mojo:axistools-maven-plugin:1.4:wsdl2java failed: A required class was missing while executing org.codehaus.mojo:axistools-maven-plugin:1.4:wsdl2java: Could not initialize class org.codehaus.mojo.axistools.wsdl2java.WSDL2JavaWrapper

Properly configure logging in the client

Cannot clean on Windows as long as mvnd keeps a plugin from the tree loaded

Reproducible by adding clean to the second invocation of client.execute() in ModuleAndPluginNativeIT.

This is because the test project uses a plugin which is compiled from sources in the same source tree. Windows does not allow deleting open file, so as long as mvnd keeps the plugin jar open, it cannot be cleaned/deleted.

The daemon is probably leaking memory

Steps to reproduce:

Checkout apache/camel-quarkus#705 that contains updated mvnd rules for Camel Quarkus
Build a couple of times using mvnd clean install -DskipTests
IIRC after the fourth build or so the build became slow, taking 7+ minutes to complete (the first one was ~45 sec)
Repeating the build even more times lead to an OOME in the Quarkus plugin.

Workaround: kill the daemon when it gets slow.

Concurrent access to the local repository

Creating this issue to discuss the strategy, because this will hit us sooner or later. It looks like the stock Maven still does not synchronize the access to the local repo. Due to this, two threads or processes can write into the same file which may result in a corrupted data.

https://issues.apache.org/jira/browse/MNG-2802 https://github.com/takari/takari-local-repository

Question: is there a way to limit the concurrency?

When I run mvnd it consumes all cores on my machine and that's usually great. However, sometimes I wish I could adjust how many cores it could use.

I know maven has the -T<num>C option, but it does not seem to work for mvnd. Is there a way I could do that?

Connection timeout when trying to execute any build

Hello,

I am getting this error every time I am trying to run a build:

"mvnd clean install"

I am running the software on a VPN, don't know if that may be the issue.

WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[main] INFO org.jboss.fuse.mvnd.common.DaemonRegistry - Removing 0 daemon stop events from registry
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Previous Daemon (df642d73-ad18-43a0-9821-0ad3b45610d1) stopped at 1599465245603 by user or operating system
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Starting a Maven Daemon, 1 stopped Daemon could not be reused, use --status for details
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Removing daemon from the registry due to communication failure. Daemon information: DaemonInfo{uid=9e37e4ec-8243-43e3-9a18-8e33fd9a6de1javaHome=C:\Program Files\Java\jdk1.8.0_251\jre, options=[], mavenHome=C:\apps\mvnd-0.0.4-windows-amd64, pid=35024, address=50141, idleTimeout=10800000, locale=en-US, state=Busy, lastIdle=1599465354751, lastBusy=1599465354751}
Exception in thread "main" org.jboss.fuse.mvnd.common.DaemonException$ConnectException: Could not connect to the Maven daemon.
Daemon uid: 9e37e4ec-8243-43e3-9a18-8e33fd9a6de1
  log file: C:\apps\mvnd-0.0.4-windows-amd64\daemon\daemon-9e37e4ec-8243-43e3-9a18-8e33fd9a6de1.log
----- Last  20 lines from daemon log file - C:\apps\mvnd-0.0.4-windows-amd64\daemon\daemon-9e37e4ec-8243-43e3-9a18-8e33fd9a6de1.log -----
09:55:54.759 I Daemon started
09:55:54.762 D daemon is running. Sleeping until state changes.----- End of the daemon log -----

        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemonWithId(DaemonConnector.java:302)
        at org.jboss.fuse.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:233)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:114)
        at org.jboss.fuse.mvnd.client.DefaultClient.execute(DefaultClient.java:188)
        at org.jboss.fuse.mvnd.client.DefaultClient.main(DefaultClient.java:71)
Caused by: org.jboss.fuse.mvnd.common.DaemonException$ConnectException: Could not connect to server 0.0.0.0/0.0.0.0:50141.
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:359)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemon(DaemonConnector.java:312)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemonWithId(DaemonConnector.java:299)
        ... 4 more
Caused by: java.net.SocketTimeoutException
        at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:129)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:349)
        ... 6 more

Could not notify CliPluginRealmCache

Sorry for opening a vague report like this, but I couldn't really figure out what went wrong.

One of my builds succeeded, but nonetheless printed a message like this:

[WARN] Could not notify CliPluginRealmCache
java.nio.file.NoSuchFileException: /Users/otavio/Projects/java/camel-kafka-connector/buildingtools/target/test-classes
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
	at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860)
	at org.jboss.fuse.mvnd.plugin.CliPluginRealmCache$1.onEvent(CliPluginRealmCache.java:455)
	at org.apache.maven.eventspy.internal.EventSpyDispatcher.onEvent(EventSpyDispatcher.java:104)
	at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:490)
	at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:175)
	at org.jboss.fuse.mvnd.daemon.Server.handle(Server.java:420)
	at org.jboss.fuse.mvnd.daemon.Server.client(Server.java:194)
	at org.jboss.fuse.mvnd.daemon.Server.lambda$accept$1(Server.java:175)
	at java.base/java.lang.Thread.run(Thread.java:834)

I built the project it using mvnd -DskipIntegrationTests=true clean install on a Mac.

If there's something I could do to try to collect more information, I would be happy to try it.

Test a scenario using mvn

Follow up of #89

Running maven daemon fails on windows

Running maven daemong fails on windows

Releases 0.0.0
Windows 10

E:\dev\g5rt\runtime>"E:\Program Files\mvnd\mvnd-windows-amd64"
Jun 29, 2020 12:57:30 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[main] INFO org.jboss.fuse.mvnd.client.DaemonRegistry - Removing 0 daemon stop events from registry
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Starting a Maven Daemon (subsequent builds will be faster)
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Removing daemon from the registry due to communication failure. Daemon information: DaemonInfo{uid=192ee0bd-5fac-404a-9726-6e8b75cbac61javaHome=C:\Program Files\BellSoft\LibericaJDK-11, options=[], mavenHome=E:\mvnd, pid=27040, address=52076, idleTimeout=10800000, locale=ru-RU, state=Busy, lastIdle=1593424651736, lastBusy=1593424651736}
Exception in thread "main" org.jboss.fuse.mvnd.client.DaemonException$ConnectException: Could not connect to the Maven daemon.
Daemon uid: 192ee0bd-5fac-404a-9726-6e8b75cbac61
  log file: E:\mvnd\daemon\daemon-192ee0bd-5fac-404a-9726-6e8b75cbac61.log
----- Last  20 lines from daemon log file - E:\mvnd\daemon\daemon-192ee0bd-5fac-404a-9726-6e8b75cbac61.log -----
12:57:31.744 I Daemon started
12:57:31.747 D daemon is running. Sleeping until state changes.----- End of the daemon log -----

        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemonWithId(DaemonConnector.java:286)
        at org.jboss.fuse.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:215)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:97)
        at org.jboss.fuse.mvnd.client.DefaultClient.execute(DefaultClient.java:218)
        at org.jboss.fuse.mvnd.client.DefaultClient.main(DefaultClient.java:69)
Caused by: org.jboss.fuse.mvnd.client.DaemonException$ConnectException: Could not connect to server 0.0.0.0/0.0.0.0:52076.
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:341)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemon(DaemonConnector.java:295)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connectToDaemonWithId(DaemonConnector.java:283)
        ... 4 more
Caused by: java.net.SocketException: Permission denied: no further information
        at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_ARRAY:Ljava_net_SocketException_2_0002e_0003cinit_0003e_00028Ljava_lang_String_2_00029V(JNIJavaCallWrappers.java:0)
        at com.oracle.svm.jni.functions.JNIFunctions$NewObjectWithObjectArrayArgFunctionPointer.invoke(JNIFunctions.java)
        at com.oracle.svm.jni.functions.JNIFunctions.ThrowNew(JNIFunctions.java:801)
        at sun.nio.ch.SocketChannelImpl.checkConnect(SocketChannelImpl.java)
        at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:776)
        at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:120)
        at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:331)
        ... 6 more

The mvn output appears all at once at the very end

Not sure the $subj is expected? While building there is just a single status line changing, showing the executed mojos. The output of the mvn process seems to be cached and appears at once at the very end of the build in the console.

Explain project better in README

Hi,

I am a developer and saw the annoucement on SDKMAN on this project. I clicked the link as I am a fond maven user and your project sounded interesting. Your readme describes only:

The mvnd project aims to provide a daemon infrastructure for maven based builds. It borrows techniques from Gradle and Takari to provide a simple and efficient system.

Provide daemon infrastructure: what does that mean in practicle sense? Does it make my builds go faster? Does it cache stuff? I have no idea if I want (or NEED) to check this out..

Could you provide some nice markteting slur somewhere in the README to entice me more?

apache / maven-mvnd Goto Github PK

maven-mvnd's People

Contributors

Stargazers

Watchers

Forkers

maven-mvnd's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs