Jetty.project: Packaging check in maven jetty plugin breaking execution

[PhantomYdn]

Hello,

We had a very nice feature in our build system: any jar module can be run on a web server just by running mvn jetty:run. Example how that was configured: https://github.com/OrienteerBAP/Orienteer/blob/master/orienteer-core/pom.xml#L274-L306

But with jetty update that become impossible because of the following check:
https://github.com/eclipse/jetty.project/commit/4b513c61e8ac7400826880d18729c71eca1b6ae8#diff-28ee2c02100a8cae9e1d1754ea32af10R64

Please clarify why this check was introduced? And can you please consider removing this check or add some workaround for it? Can't understand what particular value this check is bringing. Per your issues history there are others who has problem exactly because of these check.

[olamy]

The idea is to avoid installing jars for multi modules projects:

pom.xml
              module-a (jar)
              module-b (jar)
              module-c (war) (using module-a and module-b)

So previously if you wanted to run module-c with jetty:run you had to first install all the modules then run jetty:run only on module-c. A bit time consuming...
Now you simply run jetty:run from the top and everything is compiled etc.. and included in your webapp classloader (including module-a/b target/classes). So really time saving. Well for this use jetty:run need to avoid start launching webapp in module-a/b so the packaging check.
I hope this make sense. What I can do is to add a boolean skipPackaging (false per default).

[olamy]

Well reading your pom. I think there is something chicken and egg: core depends on war module but war module depends on core as well..
IMHO you should use jetty:run from the war module and not the core.

[PhantomYdn]

There is only war file being used from 'orienteer-war' module. And actually all modules which are packed as jar allowing to check just them by running 'mvn jetty:run' right now. For example:
https://github.com/OrienteerBAP/Orienteer/blob/master/orienteer-bpm/pom.xml#L185-L215
https://github.com/OrienteerBAP/Orienteer/blob/master/orienteer-pages/pom.xml#L95-L126
All modules available from this link: https://github.com/OrienteerBAP/Orienteer
So don't see any chicken and eggs problems here: it's just one file placed in one place and being reused from different modules instead of copying and pasting it everywhere.
One more point: our war does not include all modules. Those modules can be statically included into
child projects or dynamically through runtime loading which we implemented.

Yes - if you can help a way to work-around this check - as you propose with 'skipPackaging' - it will be great! Thanks!

[olamy]

look #2375 can you please test with your project if that works?

[joakime]

No, don't do skipPackingTest logic.

If we are going to do any skip logic it will be to skip the entire plugin execution, not just a specific step in it.

There's 1 problem and 1 new feature we should consider instead for this issue.

First, we shouldn't be throwing a MojoExecutionException if the packaging isn't war.

https://github.com/eclipse/jetty.project/blob/636ed4a0fee464581f96021207cbbc391d40c0c5/jetty-maven-plugin/src/main/java/org/eclipse/jetty/maven/plugin/JettyRunMojo.java#L191-L192

This should be a simple logged warning and skipped mojo execution.

Something like ...

            if ( !"war".equals( project.getPackaging() )
            {
                getLog().info( "Skipping non-war project " + project);
                return; // don't run this mojo
            }

Then we should create a new configurable which allows the users of the plugin to define what set of packaging types are allowed in their project. A list/collection/array of packaging type strings.
This would even allow for those users that use complex plugin setups that extend from the war packaging type to function.
This list/colllection/array would be defaulted to "war" (obviously).

The above check would then check the list/collection/array of allowed packaging types instead of a hardcoded one.

[olamy]

@joakime good catch LGTM I will change that

[olamy]

packaging list support added
@PhantomYdn
simply use:

            <configuration>
              <supportedPackagings>
                <supportedPackaging>jar</supportedPackaging>
              </supportedPackagings>
            </configuration>

[janbartel]

I don't exactly see why we need the test of the packaging of the project at all? Presumably if a user has defined the jetty plugin in the pom, then they want it executed (unless they've explicitly configured the "skip" option)?

[olamy]

I explained it in a previous comment
Does it make sense?

On Tue, 27 Mar 2018 at 9:37 am, Jan Bartel [e-mail] wrote:

I don't exactly see why we need the test of the packaging of the project
at all? Presumably if a user has defined the jetty plugin in the pom, then
they want it executed (unless they've explicitly configured the "skip"
option)?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/jetty.project/issues/2372#issuecomment-376346665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABNEBT9KWYj7mJNK4tlWM4zLVBXaoTwks5tiXu7gaJpZM4S4Kj1
.

>

Olivier

[janbartel]

Fix checked in via pr #2375

[gracekarina]

Hi, this is still happening to me, is there any special configuration I should add to my pom? Thanks in advance.
My jetty version is <jetty-version>9.4.9.v20180320</jetty-version>
```
org.eclipse.jetty
jetty-maven-plugin
${jetty-version}

true


config
src/test/config/config1.yaml



/

8079
stopit

8080
60000




start-jetty
pre-integration-test

start



jar

0
true



stop-jetty
post-integration-test

stop

[olamy]

@gracekarina should not. Can you try with version 9.4.11.v20180605?
Do you have a sample project to reproduce?

[gracekarina]

Hi @olamy, sorry for the delay, this is the project https://github.com/swagger-api/swagger-inflector/blob/update-jetty-version/pom.xml Thanks in advance!

[olamy]

@gracekarina I'm not clear what your problem is? is it using mvn jetty:run
anyway please look at this pr https://github.com/swagger-api/swagger-inflector/pull/269 this will fix your problem

[gracekarina]

Thanks @olamy that was the issue, and now it's fix with the PR above. 👍