xwiki-devs July 2007

xwiki-devs@xwiki.org

25 participants
104 discussions

LANG property in startup script in standalone version

by Vincent Massol

Hi, Does anyone know why we have the following LANG property defined in our startup scripts: #!/bin/sh export LANG=fr_FR.ISO8859-1 JETTY_HOME=. JETTY_PORT=8080 JAVA_OPTS=-Xmx300m java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT - Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar I think this is bad as it's french and I don't think we should set it for the user. That said, if it's there its probably because it was required in the past, hence my question here. To summarize: anyone sees any issue if I remove that "export LANG" line? Thanks -Vincent

16 years

Attaching an image from another document?

by Vincent Massol

Hi, I'd like to attach an image to the current document but the image is attached to another document. I couldn't find the answer in the FAQ. It would be great if the {image:} radeox macro allowed for this. Right now the only solution I'v found (which is a bit ugly) is to use an HTML <img> tag as in: <img src="/xwiki/bin/download/XWiki/Toolbar/image.gif" /> Any other solution I would have missed? Thanks -Vincent ___________________________________________________________________________ D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions ! Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses http://fr.answers.yahoo.com

16 years, 2 months

[Proposal] Internationalizing XWiki Applications

by Vincent Massol

Hi, Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers: * Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages * Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files Implementation details: * Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely WDYT? Thanks -Vincent

16 years, 4 months

One WAR with everything, one empty WAR and/or one WAR per database?

by Vincent Massol

Hi, With the 1.1M3 release we have currently only released a hsql version of the platform WAR. That war only includes the HSQL JAR but not the driver JARS for other DBs. In our current build we can generate the platform WAR for other DBs using for ex: mvn install -Pmysql. That includes the driver JAR for that DB. Before we were bundling all driver JARs into our WAR so our users may be a bit confused and we need to decide on the strategy we want to have. I can see 3 possible strategies: 1) 1 WAR per database - We could start by releasing only 2 WARs: one for HSQL and one for MySQL. I don't think we need more and releasing more is going to be a pain as each WAR weights 40MB. 2) 1 WAR with everything - Cons: having all these DB drivers makes our WAR fatter - Possible solution: we only release the HSQL and MySQL drivers 3) 1 empty WAR I feel 3) might actually be the best solution for the following reasons: - if the user is non technical he'll install the standalone version - if the user is technical it means he shouldn't have any problem following install instructions that tell him to download such driver at such location and put it in WEB-INF/lib - we only release one common WAR and our XWiki Platform is environment independent (which is a new property to have I think) - releasing one WAR makes our release process simpler (only 40MB to release once) WDYT? Thanks -Vincent

16 years, 10 months

Platform Core directory change for introducing components

by Vincent Massol

Hi, I'd like to make the following changes: * Move current code in platform/core/trunk/* to platform/core/trunk/ xwiki-core/*. In the future the goal is that this module is broken down into several other modules. * Create platform/core/trunk/xwiki-plexus: Will hold the classes to bootstrap plexus. * Create platform/core/trunk/xwiki-component: Will hold xwiki classes related to the component architecture. For example: XWiki's ComponentManager and the lifecycle classes (like Initializable for example). These are independent of the underlying component framework used (Plexus, OSGi, etc) I'll do that in the coming few days. Let me know if there's any issue. Thanks -Vincent

16 years, 11 months

[VOTE] Commit Eclipse integration source code and give Commit rights to it to Tharindu and Asiri

by Vincent Massol

Hi, I'd like to commit the eclipse integration source code in a xwiki- extensions/xwiki-eclipse directory. Of course Tharindu/Asiri shoud clean up their code and align it with XWiki's coding conventions first and I won't commit anything until they do so. I'd also like to give them commit access to that section of our SVN (and NOT as general committers). Here's my +1 to both topics. Please cast your votes. Thanks -Vincent

16 years, 11 months

Issue with version numbers while working on new diff interface

by Ludovic Dubost

While working on the new diff interface I've hit this bug http://jira.xwiki.org/jira/browse/XWIKI-1468 with the numbering on versions in the RCS file which does not correspond to the version of the real documents. There are different ways to fix this, but maybe it's not worth to do the "perfrect fix" with Artem's work on versioning storage that coult not make use of RCS. So the problem is that in the RCS file you have 1.3 -> $doc.version = 1.4 1.2 -> $doc.version = 1.3 1.1 -> $doc.version = 1.2 This actually is visible in the UI when you request the version list of the document that is in version 1.4 you will be shown version 1.3,1.2,1.1 but no 1.4. If you click on 1.3 then you will see document in the latest version. If you make a diff between 1.3 and 1.2 then you will see in the UI "From 1.4 to 1.3". I found that this problem depends on the initial version of the document when it is first saved. This means that we should be able to detect the issue for fixing the view as well as migrate the version file on save when we see the problem. Fix 1: change the UI to acknowledge this mistake (make only changes in vm files) but no fix to saving Fix 2: change $xwiki.getDocument(doc, version) and $doc.getRevisions (and related) to send back the right data but no fix to saving Fix 3: fix the problem in saving (move all versions by one if we detect the problem), detect the issue (last RCS version not equal to current doc version) to apply fix1 and fix2 for the display (probably easier to do with fix 2) I'm more favorable to fix 3 combined with fix 2. WDYT ? Ludovic -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

16 years, 11 months

Why do we throw exceptions in the ConfluenceRpcInterface methods?

by Vincent Massol

Hi, If our goal is to implement the Confluence XMLRPC interface (http:// confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure. Does anyone know why we're throwing them? Are we ok to remove all exception throwing? Thanks -Vincent

16 years, 11 months

Patches for XML RPCs related to Xeclipse

by Asiri Rathnayake

Hi Vincent, I have completed patches on XML RPCs needed to continue work on Xeclipse. http://jira.xwiki.org/jira/browse/XWIKI-1520 http://jira.xwiki.org/jira/browse/XWIKI-1521 http://jira.xwiki.org/jira/browse/XWIKI-1524 Can you please verify these and apply them as you see fit ? Thanks a lot. - Asiri

16 years, 11 months

XECLIPSE.R.1.0.M1

by tharindu jayasuriya

Hi all, This is about r.1.0.m1 version of xeclipse (XWiki-Eclipse-Plugin). We have completed following tasks in this release, 1. Cleaned up source code ( need to be confirmed by Vincent ) 2. Implemented adding/deleting pages. - Adding pages does not seem to work correctly due to some errors in XML-RPC implementation of XWiki, need to look into this. - Removing pages does not work at all because the corresponding XML-RPC is not implemented in XWiki. 3. Implemented adding/deleting spaces. - Adding spaces work fine. - Deleting spaces does not work (RPC not implemented in XWiki) As it's obvious by now, we need to peek into XWiki internals to get these issues fixed. But since we have a scheduled release today (and these issues showed up all of a sudden), we thought of finishing the work from the plugin's end and uploading the relevant work. Anyway, those issues need to be fixed asap. We have tested the work on a stand alone (HSQLDB) Xwiki installation, it would be really nice if someone can test the plugin on a real server and confirm the results :) Vincent, I couldn't find an appropriate place to upload the files in XWIKI JIRA, so i thought of attaching relevant files into this email. I'm really sorry for any inconveniences. Hope to hear from you very soon. Thanks a lot! - Tharindu & Asiri

16 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2007