Hi On Sat, Feb 4, 2012 at 12:49 AM, Sergiu Dumitriu <[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
