Fix for #477

[maybeec]

Fix for #477 including another fix regarding the faulty integration of the log4j backend for slf4j

[oasp-ci]

Can one of the admins verify this patch?

[jomora]

@maybeec, I found the same solution. Adding the spring-boot-maven-plugin in the way you did basically fixes the problem of the missing start class.

Nevertheless, I did some investigation on why the spring-boot-maven-plugin is missing, and I found that this was done to solve another issue where libraries were included twice (see here and #405 ).

I think we should investigate further if #405 could be solved differently. Potentially, this could allow us to use the spring-boot-maven-plugin again.

What do you think?

[maybeec]

good catch! yes, we should investigate further, which impact this will have on #405. Especially also for the batch component as stated in #405. I think we are not yet done here. If you like to debug this a little bit. I may have little time today. But we should stay connected.

[jomora]

The following configuration of spring-boot-maven-plugin in core pom.xml seems to solve #405 and #477.

      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
          <mainClass>io.oasp.gastronomy.restaurant.SpringBootApp</mainClass>
          <layout>ZIP</layout>

        </configuration>
        <executions>
          <execution>
            <id>fat-jar</id>
            <goals>
              <goal>repackage</goal>
            </goals>
            <configuration>
              <classifier>fat</classifier>
            </configuration>
          </execution>
        </executions>
      </plugin>

What happens?

Core pom.xml specifies both maven-jar-plugin and spring-boot-maven-plugin. Both should produce a JAR file according to the project's packaging type. As long as the spring-boot-maven-plugin is configured as stated in #405 (look at the code) (which is more or less default configuration) only a single JAR file will be assembled. AFAIK this happens due to the fact that default naming is applied.

By defining a classifier in the spring-boot-maven-plugin as defined above, default naming does not apply to the JAR assembled by the spring-boot-maven-plugin. The maven-jar-plugin will still produce a JAR with the default name, whereas the spring-boot-maven-plugin will produce a name including the classifier. Therefore, two JARs are assembled instead of a single one where each JAR is configured according to one of the two maven plugins.

This conclusion is supported by mavens logging output as show in the following

[INFO] --- maven-jar-plugin:2.5:jar (default-jar) @ oasp4j-sample-core ---
[INFO] Building jar: C:\Projects\oasp\workspaces\test\oasp4j\samples\core\target\oasp4j-sample-core-dev-SNAPSHOT.jar
[INFO]
[INFO] --- maven-source-plugin:2.4:jar-no-fork (attach-sources) @ oasp4j-sample-core ---
[INFO] Building jar: C:\Projects\oasp\workspaces\test\oasp4j\samples\core\target\oasp4j-sample-core-dev-SNAPSHOT-sources.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:1.4.0.RELEASE:repackage (fat-jar) @ oasp4j-sample-core ---
[INFO] Layout: ZIP
[INFO] Attaching archive: C:\Projects\oasp\workspaces\test\oasp4j\samples\core\target\oasp4j-sample-core-dev-SNAPSHOT-fat.jar, with classifier: fat

Why does this solve #405?

Since Maven adheres to default naming conventions when assembling the OASP4J server, the slim JAR produced by the maven-jar-plugin will be included in the server JAR. Hence, the dependencies will only be packaged in the server, but not in the core JAR and the server size will stay around 50mb.

Why does this solve #477?

Although the core JAR with the default name (oasp4j-sample-core-dev-SNAPSHOT.jar) which is produced by the maven-jar-plugin is not runnable (see #477 again) as a standalone app, the fat JAR produced by the spring-boot-maven-plugin is runnable. Hence, when starting the core app the developer has to choose the fat JAR which can be identified by the classifier.

More Info:

I verified that the server JAR works on a brand-new Tomcat 8 instance, and also that the fat JAR starts from the command line.

I'm not sure whether this is the best solution, but it is quite simple and seems to work. Of course, the naming could be changed from fat to executable or standalone or something.

Unfortunately, I have no idea whether any problems occurr in the batch project as was feared in #405. Could anyone give me guidance on how to do that? :-)

[maybeec]

@jomora I gave you access to my fork. Please be welcome to implement your proposal.

[sroeger]

We had a similar problem for the generation of the server jar. See PR #446

[hohwille]

We should simply first implement #384 that is somehow stuck even though the majority voted for it (except for @maihacke). core should not contain a dependency on tomcat and spring-batch and should not build a bootified jar.

[jomora]

This PR will be closed. PR #491 provides a solution. Please, contact me if you have any question regarding this procedure. Cheers!