Seems a good plan to baseline Across on Spring Boot. There are some similarities between what Boot tries to accomplish and what Across core does. Spring Boot devtools (as of 1.3) has similarities to the current development mode, LoggingModule, DebugWebModule and ApplicationInfoModule relate somewhat to the actuator.

The Spring Boot libraries come packed with useful classes (eg lots of Conditional annotations) that could then be used in modules. Using the IDE integration of Boot (eg the properties generation) could make configuration of Across modules easier.

Versions

Because of the development timeline, a focus on Across being a facilitator for modern (new) web applications seems advised. If we focus now on latest (or to be) versions of the core related libraries, there is a decent chance they have become more mainstream by the time Across reaches the maturity level that makes it really useful for larger enterprise projects.

This would mean actively dropping the current support efforts for things like JBoss. Leave those up to contributors instead of incorporating them in the core dev.

Versions I would think of :

JDK 8 (GA)
Spring Boot 1.3 (Q4 2015)
Spring Framework 4.3(Q2 2016)

For UI generation:

Thymeleaf 3 (Q1 2016)
Bootstrap 4

Vision

A goal for a demo project would be to have a simple Spring Boot application with in it a single domain object and a Spring Data repo. Some basic configuration: Spring security configurer and something like @EnableAcrossContext("AdminWebModule", "EntityUiModule"). When starting the application, there's a full-fledged admin UI for managing the entity.

This mainly requires some polishing and finetuning of recent modules, focusing on configuration reduction and hooking up with Spring Boot.

Functionality

Core functionality that would make Across broadly useful and appears to fill in a gap: setting up an opinionated web setup for templating, resources that can be used to generate configurable runtime UIs. Providing a bootstrap based ui model and generate entity management interfaces based on Spring data repositories or custom entities. Current projects have shown there can be quite some dev time saved with this, and at the same time creating a decent, semantically correct, html output without in depth knowledge.

Development focus could then be on:

Currently in across web:

templating system
web resources (registry, webjars, cache busting etc)
menu building system

Modules

Bootstrap ui module: components & thymeleaf integration
adminwebmodule for setting up the centralized admin pages
Entity ui module for generating UIs

More loose coupling would be required, so you could easily generate a custom UI and render it anywhere, not requiring adminweb.

Interesting approach would be to be able to generate a ui for a remote service endpoint (created through Feign for example). Could help teams generating management UIs for microservice resources.

Phased approach of Boot baselining

make Boot and across compatible
1. To be tested, the way an Across context works now it might clash with the Boot way of enabling functionality.
reduce the configuration required for an Across context, use auto detection of modules, installers, remove need for an application module itself
migrate to Spring profiles, configuration properties with all Boot support (yaml f.i.)
simplify Across code: reduce the spots where Across does things differently than standard Spring, possible candidates: @AcrossCondition, use of Mbassador etc

Browser not supported