5 Feb
2012
5 Feb
'12
11:01 p.m.
Hi
On Sat, Feb 4, 2012 at 12:49 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Hi devs,
I'd like to have an early decision on what (bigger) dependencies should be
upgraded in the next release cycle.
A) HTML 5. Already proposed by Jerome. This is something that has a
continuous aspect, since "switching to HTML5" can be something as simple as
writing a smaller DOCTYPE, or can go to rewriting the entire templates and
rendering engine. We'll start small and improve things as we go.
+1
I believe the HTML5 renderer is a mandatory step though ; otherwise we
will generate unvalid markup. For example <tt> does not exists anymore
in HTML5, yet it is generated by the XHTML/1.1 rendered.
B) Hibernate 4. Will require some code changes since we're using a few
deprecated APIs that have been removed in 4.0.
C) Struts 2. We could move away from Struts completely at some point, but
until we have the time to implement our own action mechanism, a good step
forward is upgrading to a newer version of Struts.
D) Velocity Tools 2. I'm not quite happy with how version 2.0 is packaged,
since it brings in a dependency on Struts 2, but 2.1 isn't planned yet.
Alternatively, we could package our own subset of velotools, since we're
only using the generic tools, not VelocityView or VelocityStruts.
E) Servlets 3.0. Since we're using Java 1.6, we could also require a
servlet-3.0 capable container. This will give us more flexibility in
defining servlets and filters, since the 2.4 versions we're using now
requires a central web.xml file. The problem is that only the most recent
versions of the popular servlet containers are compatible: Jetty 8, Tomcat
7, Glassfish 3, WebSphere 8, WebLogic 12. Oracle Application Server doesn't
provide a version compatible with servlets 3.0, but this server is
discontinued anyway. This means that users on older Linux server versions
will have to install Tomcat 7 manually.
F) Jetty 8. This is required for Servlets 3.0, but it would be a good
upgrade on its own.
G) HSQLDB 2. Better for performance.
H) Lucene 3.5, Tika 1.0. Upgrading Lucene shouldn't be a problem, but an
early attempt at using Tika 1.0 didn't work, it would require some time to
debug it.
I). Sass, Less or something like that. Personally I'm against this, since
we're already providing support for most of their benefits by including
Velocity code in CSS files. Does anybody else consider that we should
include a CSS framework?
I'm +1 for this.
You can potentially achieve some of the benefits those frameworks do
provide using velocity, but I don't think this is the right approach.
There are some feature you will not be able to emulate elegantly with
velocity, like mixins [1] or nested rules [2]. Similarly, you would
have to write a complete velocity tool to emulate what color functions
brings out of the box and with a "natural" syntax [3].
Now, that said, I'm personnaly even more interested in bringing such
pre-processing power to skin extensions than bringing them to skin
stylesheets - I'm not writing them ;). Some time ago I've started
working on this on a branch on my fork [4], but it's not quite ready
yet.
Jerome
[1] http://lesscss.org/#-mixins
[2] http://lesscss.org/#-nested-rules
[3] http://lesscss.org/#-color-functions
[4] https://github.com/jvelo/xwiki-platform/tree/sx-preprocessors
J) Joda Time 2 and Quartz 2, and maybe freshen up the plugins that use them.
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/