xwiki-devs February 2007

xwiki-devs@xwiki.org

29 participants
70 discussions

Non ascii characters in doc names, need advices for patch

by Gilles Serasset

Hi all, I filed a jira issue concerning the management of doc names that use non ascii char (which poses problems to setup using non iso-latin-1 encoding). The bug is easy to see: setup a utf-8 xwiki and create a page using name "été" for instance. Xwiki redirects you to: http://localhost:8080/xwiki/bin/edit/Main/%C3%A9t%C3%A9? template=&parent=&title=%E9t%E9 As you can see the page name is urlEncoded using UTF-8 but the aram part is encoded using ISO-latin-1 Digging into the code, this redirect is done by create.vm: $response.sendRedirect($newdoc.getURL("edit", "template=${template} &parent=${parent}${auxparams}&title=$title")) the getURL method encodes the page name, but leaves the action string untouched. Somewhere deep in the java standard servlet API, this untouched string has to be encoded and somehow is encoded in iso (I still don't know why nor where... My question is: there are 2 ways to deal with this pb: 1. expect vm macros to explicitely call a urlEncode method when an URL is built. 2. expect the sendRedirect Method to check and encode unproperly encoded URLs. I'd vote for the first solution as the second may lead to nasty results, but I definitelly need your advice for submitting a patch for this. Regards, Gilles, -- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75

17 years, 10 months

xwiki as portlet available?

by Haymo Meran

Hi, is the Xwki already available as JSR-168 portlet? Best regards Haymo Meran -- __________________________________________________________________ Haymo Meran email. h.meran(a)gentics.com Chief Applications Engineer mobile. +43 699 126 775 13 Gentics Software GmbH tel. +43 1 710 99 04 0 Barmherzigengasse 17/5/2 fax. +43 1 710 99 04 4 1030 Vienna, Austria web. http://www.gentics.com Der Inhalt dieser E-Mail ist eine persönliche und vertrauliche Information und nur für den Gebrauch des oben angeführten Adressaten bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, ersuchen wir Sie höflich, sich sofort mit uns ins Einvernehmen zu setzen und die E-Mail zu vernichten. Für elektronisch übermittelte Auskünfte und Ratschläge, die nicht durch nachfolgende schriftliche Ausfertigung, welche von einem zeichnungsberechtigten Vertreter unserer Gesellschaft autorisiert wurde, bestätigt werden, wird grundsätzlich keine Haftung übernommen. Gänzliche Virenfreiheit kann niemals garantiert werden und eine Haftung findet hiefür gleichfalls nicht statt. Es gilt österreichisches Recht unter Ausschluss allfälliger Kollisions- oder Verweisungsnormen. Gerichtsstand ist Wien-Innere Stadt.

17 years, 10 months

New Codesytel guidlines and some questions

by Christian Gmeiner

Hi all, at the moment I am working on xml-rpc in xwiki, I am adding documentation and fix the coding style. But I run in some trouble: 1) I have an interface "ConfluenceRpcInterface", which is documentet quite well. Now in "ConfluenceRpcHandler", which implements the "ConfluenceRpcInterface" I need to add javadoc to each method. The question now: Shall I copy and paste the javadoc from the interface, is it okay to add something like /* * (non-Javadoc) * @see com.xpn.xwiki.xmlrpc.ConfluenceRpcInterface#login(java.lang.String, java.lang.String) */ or should I not document the interface and add the documentation to the implemantion of the interface? 2) ArrayList is not allowed. What should I use instead? Thanks, austriancoder

17 years, 10 months

Fwd: [xwiki-dev] .xar Extension NOT Used Properly

by Catalin Hritcu

Hello all, What would you think of using the JAR extension instead of (mis-) using XAR for XWiki applications, and using the JAR manifest for storing the information that is now stored in package.xml ? Any other way this can be fixed ? Already created a JIRA task about this http://jira.xwiki.org/jira/browse/XWIKI-802 but I would like to hear your opinions before spending the time to implement a change you might actually not want :) Catalin ---------- Forwarded message ---------- From: Vincent Massol <vincent(a)massol.net> Date: Feb 2, 2007 7:56 PM Subject: Re: [xwiki-dev] .xar Extension NOT Used Properly To: Catalin Hritcu <catalin.hritcu(a)gmail.com> Hi Catalin, I think it's best to discuss all this on the list. Also, I've provided some answer in JIRA. Thanks -Vincent On Feb 1, 2007, at 11:22 PM, Catalin Hritcu wrote: > Hi Vincent, > > I created a JIRA issue for this and assigned it to myself: > http://jira.xwiki.org/jira/browse/XWIKI-802 > > At the time I don't really know much about what needs to be changed to > make it happen, but I'll look into it. Suggestions welcome :) > >> I guess we could use a JAR format and use information in the manifest >> to describe the content of an archive > > Can you also be more precise about the information you want stored in > the manifest? > http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest > According to this it seems that a manifest can store many things. > > Regards, > Catalin > > On 1/31/07, Vincent Massol <vincent(a)massol.net> wrote: >> Hi Catalin, >> >> See my other email on this topic. Basically I think I agree with >> you but >> we're currently focusing on releasing XWiki 1.0 and fixing bugs. >> this is an >> improvement request that will have to wait for quite long unless >> someone >> contributes a patch for it (including patches for the >> documentation ;-)). >> >> Thanks >> -Vincent >> >> >> On Jan 8, 2007, at 11:32 AM, Catalin Hritcu wrote: >> >> >> The new way to import/export wiki pages is very useful. However, I >> think that using the .xar extension for the zip(!) archive is highly >> confusing. This because there is already a XAR(eXtensible ARchiver) >> archiving utility which uses the .xar extension for quite a >> while. And >> while now XAR is standalone, it will be quite probable used by the >> MacOSX package system in the future. Then download your archive will >> yield an error like this (safari automatically expands archives): >> >> "Error opening xar archive: xwiki-1.0-beta-1.xar" >> >> Links: >> http://www.opendarwin.org/projects/xar/ >> http://www.nabble.com/xar-in-Mac-OS-X-t2081148.html >> >> >> <messagefooter.txt> >> ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com

17 years, 10 months

[VOTE] Commit access to Jason Van Zyl on the XWIKI_2_0 branch

by Vincent Massol

Hi committers, As explained in a previous email on the V2 Architecture, Jason and I would like to start experimenting with Plexus and components. For this I have created a 2.0 branch in SVN. I'd like us to vote to give Jason access to that 2.0 branch. Here's my +1 Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 10 months

Xwiki and plugins

by Anne Louisa Croos

Dear Sir! I am not sure that I am sending this email to right place, but I guess it is a start. I have few questions around xwiki which I hope you can answer me or that you will redirect to the right person to answer. The thing is that I want to use plugins which are included in xwiki. On this page "http://www.xwiki.org/xwiki/bin/view/UserGuide/Plugins" you want us to "copy its JAR (Plugins are bundled as JARs) into your XWiki installation: drop it in XWiki WAR's WEB-INF/lib directory. " But when I go to "http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xwiki/xwiki/trunk/core/s…" to download, there aren't any jar files to download. Does it mean that I have to download the java files, compile them and create jar files before I can use them on WEB-INF folder? I hope you can help me with this question. Thank you. -- Yours sincerely Anne Louisa Croos Database Developer IT-Department / open archaeology Museum of Culture History University of Oslo Tlf: +47 22 85 96 52

17 years, 10 months

[patch proposal] regex handling in XWiki core

by Pablo Oliveira

Hi, As some of you may know, I am currently working on a version of XWiki for mobile devices. I have been investigating the possibility of running some parts of XWiki on a J2ME - CDC PP configuration. During this process I have noticed that XWiki uses two different api for matching regular expressions: * Jakarta ORO * java.util.regex ( JDK > 1.4 ) Because j2me does not have the java.util.regex classes, I have made some small changes so that the core of XWiki only uses Jakarta ORO, so I can continue my tests. Yet, I think these changes (see attached patch) may be of a more general interest because: * it might be cleaner to stick to a single regex lib * this patch factors some of the regex handling on an encapsulating class that would allow us to change the regex underlying implementation more easily. What do you think? Regards, Pablo

17 years, 10 months

[ANN] XWiki 1.0 Beta 4 Released

by Vincent Massol

Hi, We're happy to announce the availability of XWiki 1.0 Beta 4 (http:// www.xwiki.org/xwiki/bin/view/Main/Download). Major changes: * Lots of bugs fixed * Added support for internationalizing XWiki applications * Added XMLRPC addSpace() API (confluence1.addSpace) * Improve FeedPlugin to store RSS article in xwiki pages * (Experimental) XWiki Google Web Toolkit Server API added, for developing GWT applications in XWiki * All the files stored on disk should be charset independent * Add button to setup underline for text in wiki editor See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10Beta4 for more details. Enjoy! -The XWiki Development Team ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 10 months

[Proposal] Apply our new coding style to all code at once

by Vincent Massol

Hi, Now that we have our new coding style defined (see http:// www.xwiki.org/xwiki/bin/view/Community/) I think it would be best to apply to all our java sources at once so that 1) people do not make code style change at the same time as they submit changes and 2) so that one's uncommitted work isn't hard to merge. I propose to apply the coding style to all our code base on Monday 12 after the Beta 4 release. Is that ok with everyone? Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 10 months

[Proposal] Top level SVN directory structure

by Vincent Massol

Hi , I'm continuing my search of a perfect SVN directory structure. Here's my latest proposal which I'd like to share with you: xwiki/ |_ xwiki-core/ (*) --> JAR, WAR |_ xwiki-plugins/ --> JAR |_ xwiki-applications/ (**) --> XAR |_ xwiki-clients/ |_ xwiki-tools/ |_ xwiki-distributions/ (**) --> ZIP, TGZ, EXE |_ xwiki-tests/ (**) (*) renamed from xwiki/ in xwiki-core/. xwiki-core/ will in the future contain the different components of the core, split into different build modules. (**) new directories - xwiki-applications/: see previous email proposition on that. - xwiki-distributions/: XWiki distributions. Will currently contain only the standalone distribution (as tgz and exe) but will contain other distribs in the future. Like the standalone distribution on Tomcat with MySQL, like a J2ME distribution, etc. - xwiki-tests/: functional tests. Depends on almost all other artifacts (xwiki-core, plugins, applications, distributions). Do not depend on xwiki-clients/ You may notice that I haven't put xwiki-extensions/ in there, which was in my previous email for putting Curriki. After thinking this through, I really think Curriki should not be in the XWiki SVN. I believe we should create a new ObjectWeb project called Curriki or XWiki Curriki and it should have its own SVN. This is because the xwiki/ dir should really be about XWiki as the platform. In addition SVN commit rights might be different, lifecycles and releases are different, etc. If we decide that Curriki should stay then we'll need to reorganize the full structure as: xwiki/ |_ xwiki/ |_ xwiki-core/ (*) --> JAR, WAR |_ xwiki-plugins/ --> JAR |_ xwiki-applications/ (**) --> XAR |_ xwiki-clients/ |_ xwiki-tools/ |_ xwiki-distributions/ (**) --> ZIP, TGZ, EXE |_ xwiki-tests/ (**) |_ curriki/ In the meantime (ie. while we debate this particular point) we can move curriki in xwiki-extensions. But really if Curriki was part of XWiki it should be split in xwiki-plugins/ (for curriki-specific plugins), xwiki-applications/wikis/curriki (for the curriki XAR) and xwiki-distributions/curriki (for the Curriki distributions). However I don't think Curriki is part of the XWiki platform. Last I'm not sure but I think we should probably merge xwiki-clients and xwiki-tools but that can wait. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 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 2007