xwiki-devs February 2012

xwiki-devs@xwiki.org

26 participants
58 discussions

[xwiki-devs] [Proposal] New Dates for XE 3.5

by Vincent Massol

Hi, As usual (*sigh*, we need to fix that!) we've lagged in the release of XE 3.5M1 and we need to define what are the new dates. Since we want 3.5 to be a short release I propose to do the following: * Skip 3.5M1 and instead go straight to 3.5RC1 * Release 3.5RC1 on Tuesday 14th (Marius who's the RM isn't available on the 13th). This means we need to start stabilizing **NOW** and fix all failing tests in order to be ready Tuesday morning. * Call 3.5RC1 the Love Release ;) since it's on Valentine's day… * Keep the 3.5 final date for the 20th of February WDYT? Thanks -Vincent

12 years, 10 months

[xwiki-devs] Pull request on meeting manager

by Ludovic Dubost

Hi, I've fixed meeting manager to work with XWiki 3.3 (at least) and CSRF in particular. I've commited the changed to a repo on my github account and issues a pull request, as apparently I could not commit myself. Who would be in charge of pull request on the meeting manager repo in xwiki-contrib. Here is my pull request: https://github.com/xwiki-contrib/application-meetingmanager/pull/1 Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 10 months

[xwiki-devs] Local object references are not that local

by Thomas Mortagne

Hi devs, Denis just reported an issue he have while he is working on generating ids for the database: local reference to an object looks like "space.name^wiki:xspace.class[0]" which is not very local when the absolute reference is "wiki:space.name^wiki:xspace.class[0]" (will let him give more details on what issue it causes). I'm not sure what's the best for this. Here are some ideas: 1/ Relative references for class: change BaseObjectReference to generate a name based on a class reference relative to the document reference. So an absolute reference of an object would give "wiki:space.name^xspace.class[0]" which in turn is not fully absolute even of you can resolve the class reference based on the document. 2/ Local reference for class: pretty much the same thing as 1/ but never contain the wiki. Thing is the current storage does not support class coming from another wiki so would kind of make it "official" in the references generated by BaseObject. 3/ Custom serializer in oldcore: overwrite reference serializers in oldcore and parse the object name to also make the class reference follow the serializer rules (local, compact, etc.). 4/ Object guid as name: use object guid as name but right now guid can't be trusted (sometimes not set, sometimes duplicated, etc.) so it would require to fix some bugs first. 5/ Do nothing: and see this as a limitation of the object reference in the current storage. That means that anyone that really need a local reference for a BaseObject should generate the reference the way he want instead of asking it to BaseeObject before giving it to the serializer. Note that all of these solution generate already currently valid object references, it's mostly about choosing the best default reference. WDYT ? 1/ and 2/ mean that code counting on reference always having absolute reference will be broken, like some event listener on object and object properties modifications probably (would need to check). 3/ is a bit crappy from architecture point of view but at least the base object reference stay fully absolute 4/ is a bit dangerous right now and require to fix several bugs related to guids at least. Also it gives an object reference not very nice from human reading point of view. 5/ does not fix much even if it's possible to manage with a hack helper to get local reference but it's a hack 1/, 3/ and 5/ are nothing else that hacks from my point of view so I'm -0.5 for them 4/ is not a hack but I don't feel very comfortable with object uid that has never really been used (and so have several blocker bug still not fixed) so lets say -0 too 2/ is OK if we say that with BaseObject we will never support classes coming from another wiki. The next storage will have different kind of names for objects anyway not based on classes from what we discussed. It's a +0.5 for me (no solution give me 100% satisfaction but this one is the best until other arguments are exposed) -- Thomas Mortagne

12 years, 10 months

[xwiki-devs] [VOTE] New xwiki-commons-environment module

by Vincent Massol

Hi devs, Thomas and I have been brainstorming about the need to introduce a generic notion of Environment in XWiki Commons. The idea is that there are some modules that are currently in Platform that should/could be moved to Commons. To name just two: * Cache * Extension However these modules need a notion of Environment. They don't need the full notion of Container that we have in Platform though (they don't need the notion of request/response/session for example). So here's a proposal. * Introduce the following modules: xwiki-commons-environment |_ xwiki-commons-environment-api |_ xwiki-commons-environment-standard |_ xwiki-commons-environment-servlet * With the following Java content: - in xwiki-commons-environment-api: Environment (Interface) |_ getTemporaryDirectory() --> File |_ getPermanentDirectory() --> File |_ getResource() --> URL |_ getResourceAsStream() --> InputStream - in xwiki-commons-environment-standard @Named("default") StandardEnvironment |_ setResourceDirectory(File) |_ setTemporaryDirectory(File) |_ setPermanentDirectory(File) - in xwiki-commons-environment-servlet @Named("default") ServletEnvironment |_ setTemporaryDirectory(File) |_ setPermanentDirectory(File) Usage from other components: @Inject private Environment environment; * Usage in a standard environment (standard as in Java SE): ECM ecm = new ECM(); ecm.initialize(getClass().getClassLoader()); StandardEnvironment env = (StandardEnvironment) ecm.lookup(Environment.class); env.setPermanentDirectory(new File(…)); … However to make it simpler to initialize XWiki in a standard environment we will provide a System helper class in xwiki-commons-environment-standard: ECM ecm = System.initialize() <-- uses System classloader and sets tmp dir to java.io.tmp.dir, no permanent dir set, no resource dir ECM ecm = System.initialize(File permanentDirectory) <-- uses System classloader and sets tmp dir to java.io.tmp.dir, resource dir points to permanent dir ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory) <-- uses System classloader and sets tmp dir to java.io.tmp.dir ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory, File temporaryDirectory) <-- uses System classloader ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory, File temporaryDirectory, ClassLoader classLoader) ECM ecm = System.initialize(ClassLoader classLoader) <-- Sets tmp dir to java.io.tmp.dir, no permanent dir set, no resource dir Note: in 99% of use cases the user just has to write the following to initialize XWiki: ECM ecm = System.initialize(); * Technical impl details: - getTemporaryDirectory default to java.io.tmpdir - getResource default to getPermanentDir * Relationship with Container: - We initialize the Environment component in the Container init classes (DefaultServletContainerInitializer for Servlets) - We deprecate ApplicationContext. Code that's using ApplicationContext is now asked to use the Environment component instead Here's my +1 Thanks -Vincent

12 years, 10 months

[xwiki-devs] Adding CSS code into Xwiki skin

by Kaya Saman

Hi guys, I know I've asked this before so please bare with me and save the lynching for later ;-) I have added this CSS to the Xwiki file system and would like to add it to the Xwiki Skin Document instead....: body#body, #allviewpanels .accordionTabContentBox{background-image: url( ../../images/colors/gray/H4x4-GRAY.png); } body#body #xwikimaincontainer, body.hideright #xwikimaincontainer, body#body.hideright #xwikimaincontainerinner, body.importbody #xwikimaincontainerinner, body.exportbody #xwikimaincontainerinner, body.adminbody #xwikimaincontainerinner, body.hidelefthideright #xwikimaincontainerinner, body#body.hidelefthideright #xwikimaincontainerinner { background-image :url( ../../images/colors/bg/gpl-red.png) ; } #xwikimaincontainerinner, body#body.editbody #xwikimaincontainerinner, body#body.eportbody #xwikimaincontainer, body#body.importbody #xwikimaincontainer, body#body.adminbody #xwikimaincontainer, body#body.hidelefthideright #xwikimaincontainer, body#body.hideleft #xwikimaincontainer, body#body.editbody #xwikimaincontainer { background-image :url( ../../images/colors/bg/gpl_right-red.png) ;} body#body.editbody #globallinks, #globallinks, #rightPanels, #editPanels.panels{ background-image: url( ../../images/colors/bg/gpl-red.png);} #company { background-image: url( ../../images/colors/bg/gpl-red.png); } First of all where do I add it, into which section?? I created a new skin doc called WWW_Skin (I was told to not use Default Skin) - then select customize and insert where?? I tried adding to Style section and UI broke.... After I find the section what's the syntax to use???? Or would it be simpler to change the 'default stylesheet' under Admin -> Presentation and create my own style.css doc???? (which I kind of did anyway but it calls another css doc) Best regards, Kaya

12 years, 10 months

[xwiki-devs] [VOTE] Upgrades for the 4.x cycle

by Sergiu Dumitriu

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. 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? J) Joda Time 2 and Quartz 2, and maybe freshen up the plugins that use them. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 10 months

[xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties

by Vincent Massol

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. Here's my +1 Thanks -Vincent

12 years, 10 months

[xwiki-devs] JIRA Calendar - Needs to be up to date

by Vincent Massol

Hi devs, Just to let you know that I've fixed the calendar in the system dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000 I've also set all planned release dates for Commons, Rendering, Platform, XE and XEM. We need to remember to set them whenever we decide roadmap dates and whenever we change those dates. This calendar is linked from our roadmap pages on xwiki.org so we need to keep it up to date. Thanks -Vincent

12 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2012