xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Questions concerning the development of XWiki, Final Round

by Martin Schönberger

Hello again, and let me start once more by thanking everyone who bore with me until now. The answers you gave me so far helped a great deal for me to understand the details of this project's development as an example of open source processes and their underlying structures. In the final round of this extended interview I would like to conclude with a few questions which move a bit outside the box and beyond the horizon. ;) As I explained in one of my earlier posts, I am researching open source development processes in comparison to other approaches of developing software, and trying to find out how they relate to each other in different aspects. Besides examining those aspects, however, I am also interested in your opinion about the process. Do you see similarities to agile methods of development, or to the well-defined processes of software engineering, in your approach? Where can these similarities be found, and where do they end? Finally, may I ask you for a quick outlook into the future of XWiki? Which chances and challenges do you see coming up? In what direction would you like the development of XWiki to go in the following years? Also, do you have any points you would like to additionally mention, some vital aspect of the process I failed to address, or a special emphasis on anything you feel we did not talk about enough? I am glad for further hints and comments. :) Best regards, Martin

12 years, 7 months

[xwiki-devs] Jetty tool maven reorganization

by Vincent Massol

Hi devs, Just some heads up to let you know I'm planning to reorganize the Jetty tool modules today as follows: xwiki-patform-tool-jetty/ |_ xwiki-patform-tool-jetty-listener/ --> JAR |_ xwiki-patform-tool-jetty-configuration/ --> JAR using Remote Resource Bundle plugin |_ xwiki-patform-tool-jetty-resources/ --> ZIP that includes the other 2 modules The goal of introducing xwiki-patform-tool-jetty-configuration is to be able to use the Maven Remote resource plugin to substitute the xwiki data dir value. Thanks -Vincent

12 years, 7 months

[xwiki-devs] [Proposal] XWiki's Permanent Directory Strategy for Installations

by Vincent Massol

Hi devs, Since I'm working on making XE work in Windows7 I've thought more about XWiki's install and configuration. Actually this is not a new topic, I remember starting a discussion about it a few years ago on the devs list but we didn't act on it so here it comes again ;) Rationale ======== The idea is to separate XWiki's binaries from its data. There are several reasons for wanting this: * Some OSes require this and don't allow writing in the binary directory. Windows 7 for example won't allow writing data in \Program Files. * It makes upgrading simpler since you don't need to fish for configuration data and copy them somewhere before unpacking a new distribution over. Or if you unpack in a new directory you don't need to copy the data from the old directory to the new one. * As a consequence of the previous point It allows easier auto upgrades of XE * It makes it simpler to know what to backup: all you need to back is the data directory. Proposal ======= This is the simplest I've found (I've imagine a lot of more complex options which offer other small possibilities but in the end I went for the simpler one for now). So here goes the process when starting up XE: * XE looks for a XWIKI_DATA environment variable and if found it uses it as its environment.permanentDirectory value * If not found, XE looks in the user home directory for an XWiki directory. Now the name of this directory is environment-dependent. On non windows systems it looks for ".xwiki" directory and on Windows systems it looks for a "XWiki" directory. * If not found, then XE stops and prints a message in the console explaining that it couldn't find the location of the XWiki Data dir with explanations on how to set it. The recommendation is thus that users set the XWIKI_DATA environment property. Notes: * At startup XE prints as an INFO log the location of the permanent dir it is using. * For the standalone distribution we would set the XWIKI_DATA env variable in the xwiki start file (start_xwiki.sh and start_xwiki.bat) to point to the data/ dir in the distribution. * One aspect that is not covered here yet (the topic for another email): the installer. I'll prepare another mail for that since it's independent for me. Use cases ========= This allows the following use cases: * Make it easy to upgrade XE * Make it easy to backup XE * MAke it easy to use an existing XE install but point it to a different configuration, for testing purposes for ex * Allow installing XE for all users on a system * Allow installing XE for my user only WDYT? Thanks -Vincent

12 years, 7 months

[xwiki-devs] append html node to wysiwyg

by liujinlong5788

Hello , I have sent a similar email yesterday which said I can't append html button to wysiwyg in js. Just now I have tried in plugin with gwt. It doesn't work eithor. For example I define a string varirable String button= "<input type='button' value='xx' />" and use execute(button) ,and it will add a button to wysiwyg editor ,but it does nothing to the source ,so ,the things I have done can't be saved.Of course ,execute(rta.getDocument().createButtonInputElement()) doesn't work eithor. I see the RichTextArea which is implemented by xwiki and extended from the RichTextArea of the gwt has a method setHtml() .And it doesn't work just like execute(). At first ,I think this should be a very easy thing .but I have been defeat by it - -! Pleanse ,help me . Thank you .

12 years, 7 months

[xwiki-devs] Two problems about wysiwyg

by liujinlong5788

Hello , I an sorry it's also simple problems about wysiwyg. The first one .can I use component in wysiwyg plugin. (The component is to get and save data in database which is not the table created by XWIKI, and not mapped by hibernate )I hava used it ,but it can't run .So , I wander it is the problem in my code or XWIKI doesn't support it (I thinke there is something wront with the grammer .I don't know how to say it correctly ,but I think you can understand it). The second one is when I use js to operate the wysiwyg, I use editor.getRichTextArea().contentWindow.document.body to get the document ,but all the operate to the html do nothing to the source , and {{html}} tag which I think will work also take no effect. So ,If I append html child to the document ,The change can't be saved .Is there method to make it or the method to operate the source .I don't think getSourceText can achieve it .. Thank you!

12 years, 7 months

[xwiki-devs] [Proposal] Add and Copy CLIRR explanations to release notes when releasing

by Vincent Massol

Hi devs, I'd like to propose that we: 1) always add explanations in our pom.xml files when we add CLIRR excludes (since we should have any based on our deprecation/legacy rule) 2) copy them in our release notes. As an example I've just done that for http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… The advantage: * Users get an explanation as to why we have broken some APIs * We need the explanation in our pom.xml for ourselves to understand why we're excluding some files and since we have that explanation we might as well copy it to the release notes… WDYT? Thanks -Vincent

12 years, 7 months

[xwiki-devs] [Proposal] XWiki Configuration and Data directories

by Vincent Massol

Hi devs, This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear. Executive Summary ================ Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions. * Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files Rationale ======== This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked. Use Cases ========= The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution Short Term Proposal ================= * Add 2 system property variables: xwiki.config.dir and xwiki.data.dir * Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now) * Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now) * Don't provide a default value for environment.permanentDirectory in xwiki.properties * Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need). Use Cases Walkthrough =================== UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data * environment.permanentDirectory is not defined in xwiki.properties UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4 UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set environment.permanentDirectory WDYT? Thanks -Vincent

12 years, 7 months

[xwiki-devs] context.language having wild values?

by Paul Libbrecht

Hello developers, We had some (rare) users that had a very bad issue because we told their browser to load the lang_xx.js of their language. And their language was... wild! See: http://jira.xwiki.org/browse/CURRIKI-5694 for a sample of the things that got submitted to us. Sure, we'll now protect against these bizarre languages, still, there might be other things broken. Is there some guarantee on the set of possible languages provided by $context.language? I was expect the possible values of ISO-623-1 but that was clearly not sufficient! paul

12 years, 7 months

[xwiki-devs] [VOTE] Remove the notion of sending messages from the activity macro

by Eduard Moraru

Hi devs, We have recently extracted the functionality of sending messages from the activity macro into a new messageSender macro [1][2]. However, for backwards compatibility reasons, the activity macro still uses by default (unless the parameter messageSender='false' is specified) the messageSender macro so the users still see the ability to send messages as a feature of the activity macro. The proposal is that, for 4.1, we follow the original jira [2] issue idea (as seen in the issue's images) and: - Completely remove the messageSender macro call from activity macro (including the recently introduced messageSender=true/false parameter) - Providing instead a "Send Message" gadget for the main Dashboard that will use the new messageSender macro This way we have 2 clear macros, no more mixing: - messageSender for sending messages - activity for displaying messages (and other events) Additionally, it makes it easier for users to remove the ability to send messages from the homepage by editing the Dahsboard and removing the "Send Message" gadget. Here's my +1. Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

12 years, 7 months

[xwiki-devs] deadly bug on MoveItM: temporary fix

by Paul Libbrecht

Hello Smalalers, Thanks to Marc, we just realized that MoveItM broke since quite a while, since shortly after 1.1. I rolled back to the version 1.1 on prod so that http://sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveItM_S… kind of works whereas: http://dev.sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveI… shows the bug. I've opened: http://youtrack.i2geo.net/youtrack/issue/LABB-16 do you know of anyone else intending to use MoveItM? It is not very clear if the logging will work on the URL that works... paul

12 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs