vertx-maven-plugin

vertx-maven-plugin copied to clipboard

In the vertx run command, the --redeploy option takes a list of glob patterns to determine which files should be watched for changes and thus trigger a redeploy. Could this capability be exposed via the plguin?

From the help output of the vertx run command:

    --redeploy <includes>                    Enable automatic redeployment of
                                             the application. This option takes
                                             a set on includes as parameter
                                             indicating which files need to be
                                             watched. Patterns are separated by
                                             a comma.

@InfoSec812 - right now we don't but we could add it. will check with @cescoffier - for thoughts on adding it ? if you are good I can add it up

right now the redeploy goals are all aligned to compile phase only and by default we scan only "target/**/*" for redeploy. The simple technique we follow is to trigger compile when source changes, we need to check if we can have configuration parameter to run additional goals during redeploy so that we can hook in any phase during redeploy.

@cescoffier thoughts ?

@InfoSec812 @kameshsampath I'm not against it. I think it would be great. What is the use case to redeploy when something not in the target dir is updated? (Anything to do with typescript / js stuff ?)

@cescoffier Precisely! My ideal workflow is to use the vertx-maven-plugin in conjunction with the frontend-maven-plugin such that I can run: mvn clean compile frontend:npm vertx:run

When running like this, changes to my Angular/Vue.js/etc... projects would be monitored. Changes in those files would then trigger the compile and frontend:npm phases/goals.

@InfoSec812 Did you look into https://github.com/fabric8io/vertx-maven-plugin/tree/master/samples/vertx-web-example providing an example using the frontend maven plugin, node-based tools and vert.x maven plugin redeploy?

@cescoffier I did, but that it using grunt's ability to monitor for changes. The projects we are working on are using either AngularCLI or Vue.js/WebPack.

@InfoSec812 Grunt is just an example. You can use any type of tools:

1. the build process will run after every change in src/main.
2. the vert.x app is redeployed after every change in target.

If your web build tool has a "watch" mode, 1. is not necessary. If your web build process writes something in target, the application is redeployed. For instance, you may want to write the output of your build into target/classes/webroot.

@cescoffier That is not the behaviour I am seeing... You can look at my example project at https://github.com/InfoSec812/service-proxy-client-example.

The problem is that when I save changes under src/main/web I see that the Java code gets recompiled, but the frontend:npm goal does not get executed.

Additionally, I often end up with a build loop because I am trying for the following build order:

1. compile Java code (Generates JS Proxy files)
2. Use Maven Resource plugin to copy generated JS to Vue.js/WebPack src dir (src/main/web/) << Causes build loop!
3. Transpile Vue.js/WebPack app via frontend:npm
4. Redeploy Vert.x app

@InfoSec812 Just change the phase:

 <execution>
  <phase>process-resources</phase>
  <goals>
    <goal>npm</goal>
  </goals>
  <configuration>
        <arguments>run build</arguments>
  </configuration>
</execution>

The redeploy replays all mojo executions that happened between the initialize phase (not included) and the compile phase (included). By adding the phase, the vertx:run captures the mojo execution and replays it when you change a file.

BTW, your vert.x maven plugin config can be reduced to:

              <executions>
                <execution>
                    <id>vmp</id>
                    <goals>
                        <goal>initialize</goal>
                        <goal>package</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <redeploy>true</redeploy>
            </configuration>

Hum, I've the same build loop.... Can't you copy the file to the target dir instead?

BTW, there is also an issue in the current process:

in the process-resources phase, it:

1. build the vue.js application, copying the output to src/main/resources
2. copy the src/main/resources to target/classes (default behavior)

In the compile phase (executed after the process-resources phase), it:

1. compile the Java sources and generate the proxy
2. copy the proxy file to src/main/web/src/lib (but won't take it into account as the copy has already been done)

There are 2 actions triggering the loop:

1. the copy of the output of the npm build to src/main/resources -> it should go to target/classes/webroot
2. the copy of the proxy (that anyway is not taken into account) should use the target/classes/webroot

Tryying to see what can be done...

And therein lies the problem... IF I change the phase, the NPM build will happen before the JS proxy code is generated. Copying the generated code to target/classes doesn't help because then it isn't bundled into the WebPack application and is therefore never loaded.

Yes... By modifying the npm build to the process-classes phase it takes the new proxy, but I still have a loop between the copy resources and the compile phase.

Makes sense as the NPM build modifies the contents of src/main.

BTW, how would adding access to the --redeploy configuration help in this case?

I'm not certain that it would...

To fix the issue we would need another work directory that is not in src/main. This work dir would be the directory used to do the npm build and this process will copy the output to target/classes/webroot.

The copy of the proxy file would to this work directory.

But at the point where we place the webpack artifacts into src/main/resources/webroot, the build loop would happen again.

Just to take a few steps back... The whole point of this exercise is to be able to do quick development cycles. I have a working solution for building the runnable jar, but I do not have a good solution for a dev server/quick reload.

We would not do that anymore. We would copy the output to target/classes/webroot:

In the config.js file:

index: path.resolve(__dirname, '../../../../target/classes/webroot/index.html'),
assetsRoot: path.resolve(__dirname, '../../../../target/classes/webroot'),

Even if we copied the webpack output to target/classes/webroot that would not be what is served when using vertx:run... From my experience, vertx:run resolves the webroot path to src/main/resources/webroot.

Hum, that's a bug then. It should always serve it from target/classes/webroot and never from the src/main/resources/webroot, as this latter directory contains unprocessed file. @kameshsampath are you aware of this?

Actually this is https://github.com/fabric8io/vertx-maven-plugin/issues/129

And in fact, when I just tried it, the writing of the bundled webpack to target/classes/webroot triggers the build loop again...

Als, in case I haven't said so before, I really appreciate all of the assistance and patience @cescoffier !!!

because of the compile phase copying to src/main/web?

No, the compile phase is copying to target/classes/webroot in my test.

pom.xml

...snip...
                <execution>
                    <phase>compile</phase>
                    <goals>
                        <goal>npm</goal>
                    </goals>
                    <configuration>
                        <arguments>run build</arguments>
                    </configuration>
                </execution>
..snip..

index.js (Build Config)

...snip...
  build: {
    env: require('./prod.env'),
    index: path.resolve(__dirname, '../../../../target/classes/webroot/index.html'),
    assetsRoot: path.resolve(__dirname, '../../../../target/classes/webroot'),
    assetsSubDirectory: 'static',
...snip...