Conflicts:
java/com.sap.sailing.server/SailingServer (No Proxy).launch
java/com.sap.sailing.server/SailingServer (No Proxy, Jetty on 8889).launch
java/com.sap.sailing.server/SailingServer (No Proxy, No Tests).launch
java/com.sap.sailing.server/SailingServer (No Proxy, winddbTest).launch
java/com.sap.sailing.server/SailingServer (Proxy).launch
java/com.sap.sailing.server/SailingServer (Proxy, Jetty on 8889).launch
java/com.sap.sailing.server/SailingServer (Proxy, Remote Debug SAP VM).launch
java/com.sap.sailing.server/SailingServer (Proxy, SwissTiming Live Simulation).launch
java/com.sap.sailing.server/SailingServer (Proxy, winddbTest).launch
it seems the GWT compiler cannot handle java.lang.Class objects dynamically but requires
the .class literal statically at compile time. Refactored the AbstractEntryPoint.onModuleLoad
method and its uses accordingly.
The GWT compiler will strip any deliveries of the unused example. The code is not yet refactored. The
AppActivityMapper is still an example and should become something like a registry that we can use to
bind activities to places. The AppPlaceHistoryMapper is also example-specific and needs to be provided
by the respective application.
the duplicate loading for the null time point in the Leaderboard.html entry point still persists; we would need
a smarter way of identifying that the offset adjustment which is causing the second load during the callback
wouldn't really required another load with null at basically the same time point, but the difficulty is that
then the timer's notion of live time and the leaderboard contents would deviate. Assuming that the null time
point is handled efficiently by the live leaderboard DTO cache, I think we can live with this.