Hi you will still be able to run JSPWiki within all these application servers, as it will still build a war file that is deployable anywhere.
What it makes easier is the development/testing (CI/CD) process, I think. It also means more developers might be interested in participating as they know Spring. You are right though, a better front end UI for mobile would be valuable. But I guess I'm more of a backend developer and curious whether anyone has any thoughts on the roadmap for back end? Cheers, David V On Fri, Oct 6, 2017 at 5:21 PM, Jürgen Weber <juer...@jwi.de> wrote: > Hi, > > right now you have the choice of several products to run JSPWiki: Tomcat, > Jetty, Wildfly, Weblogic and Websphere (liberty). WildFly Swarm even gives > you a full application if you prefer microservices. I do not see anything > in Spring that we don't already have. > > A far more important missing feature is probably a decent mobile > experience. We need a mobile Skin or even an App. > > Greetings, > > Juergen > > Am 06.10.2017 01:45 schrieb "David Vittor" <dvit...@gmail.com>: > > > Hi Team, > > > > I'm thinking of moving the backend of JSPWiki to use Spring, and down the > > track to Spring Boot? > > > > Would this be worthwhile for the community? Spring is a very popular Java > > framework, and will make other integration easier, such as APIs, > > SpringSocial, SpringSecurity, and even SpringCould. > > > > It's also a dependency injection framework, which means building other > > components should be much easier. > > > > I think the licenses permit this: > > * https://en.wikipedia.org/wiki/Spring_Framework > > * https://github.com/spring-projects/spring-boot/blob/master/LICENSE.txt > > > > Note: I have in the past tried to move this to PICO Container, and I > think > > I got quite close. But I think going this Spring will be a better > framework > > for the future, and it has a bigger developer community. > > > > One problem may be the size of the Spring framework, but I think we can > > tweak this to keep it to a minimum. But will definitely be bigger than > the > > current implementation. > > > > Any thoughts? > > > > Cheers, > > David V > > >
