+1
On 11/9/2017 10:29 PM, Jürgen Weber wrote:
Java 7 is end of life, no public support from Oracle anymore.
JSPWiki should at least move to Java 8.
Also, JEE 7 needs Java 8 and has some nice features like WebSockets and JSON.
As for Spring, I do not see any advantages of replacing proven JSPWiki
code with Spring. Remember how the last big rewrite for JSPWiki 3.0
almost killed the project ..
We should restrict changes to features that have an advantage for
users, like Markdown or Mobile.
cheers,
Jürgen
2017-11-09 21:56 GMT+01:00 Juan Pablo Santos Rodríguez
<juanpablo.san...@gmail.com>:
Hi again! (again :-))
given that we have no official roadmap or whatsoever, my personal wishlist
for 2.11 would be
* move to java 7 (we're currently on java 6)
* compatibility with pre-2.9 plugins and filters
* haddock by default
* markdown support (more on this later)
* serialize workflows to disk (JSPWIKI-304)
as for the spring/spring-boot inclusion it'd use to replace big chunks of
WikiEngine/WikiContext, which right now act as IOC container (amongst other
things); almost all managers hold up a reference to one of those classes to
be able to grab their dependencies. Big special care would have to be taken
to preserve the ability to switch implementations through the different
jspwiki*.properties files, though (perhaps through a jspwiki spring boot
starter, or something like that).
I think it would simplify the codebase, but seems like a massive change
throughout the code. If you've some development made on this (no matter if
incomplete), please put it on a branch so we can have a look of what is
going to look like and at least discuss around it. There's no better way to
make traction than to make it visible :-) But please note that this would
be a really big change which should get completely done before going to
master..
br,
juan pablo
On Fri, Oct 6, 2017 at 8:39 AM, David Vittor <dvit...@gmail.com> wrote:
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
