xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

by jeremi joslin

Hi, I will try to do my best to help Ludovic to lead the project because he is very busy. I've started to review Jira tasks to find what we need to fix before the release. 1. I propose to split in Jira the XWiki project in 2 or 3 projects: * XWiki core (which is written in java) and the minimum UI (When you run XWiki with a blank DB) * XWiki plugins (also written in java, for exemple: feed plugin, mail plugin ...) * XWiki applications (in script language like groovy or velocity, for example: blog, photo album, wysiwyg...) the last too can be one because some applications can have a plugin like the feed plugin which have also an application. Like this, we can release the core without all the application and vice versa. Because many of you don't need the applications. 2. For next iterations before the release : - 1.0 B1 - 1.0 B2 - 1.0 RC1 - 1.0 RC2 - 1.0 3. I will do a summary in few days of the work to do before the release and propose you a road map. What do you think about it? I think, we can use the apache voting system (for those who don't know it: http://www.apache.org/foundation/voting.html) Jérémi -- Blog: http://www.jeremi.info LinkedIn: https://www.linkedin.com/profile?viewProfile=&key=1437724 http://www.xwiki.org skype: jeremi23 -- msn et gtalk : jeremi23(a)gmail.com

19 years, 9 months

RE: [xwiki-dev] Proposal: XWiki Maven2 migration

by Vincent Massol

> -----Original Message----- > From: Ludovic Dubost [mailto:ludovic@xwiki.com] > Sent: mardi 3 janvier 2006 08:59 > To: xwiki-dev(a)objectweb.org > Subject: Re: [xwiki-dev] Proposal: XWiki Maven2 migration > > > Hi Zhong, > > Happy new Year (I'll come up with a longer email a little later). > > You are welcome to help on the migration to maven 2. I know Vincent did > a first try when Maven was still alpha. I'll check with him to see if > there is anything usable from his work. I didn't do much (I'm attaching a pom.xml that I started but it won't help much). My main issue at the time was that ibiblio POMs were almost all wrong. I think the situation has changed now and it should be much more usable. I agree that the build should be split in small modules and the list below sounds good. > Indeed it would be great to create some submodules for each XWiki > module. This of course needs a little discussion to decide what you be a > module and what should be in the core. > > I think a first split would be: > > core > core-doc > core-objects > core-api > core-web I think we should do it nested (check the cargo build for examples): core/ doc/ objects/ api/ web/ > store-rcs > store-hibernate store/ rcs/ hibernate/ > render > render-radeox > render-velocity > render-groovy render/ radeox/ velocity/ groovy/ > user-xwiki > user-ldap > user-exo user/ xwiki/ ldap/ exo/ > plugin > plugin-core > plugin-packaging > plugin-fileupload > plugin-xyz plugin(s)/ core/ packaging/ fileupload/ xyz/ > stats > pdf > xmlrpc (or webservice) > > It might be a little too detailed. It sounds good I think. It doesn't look too detailed at all. > I think in the process of splitting > in modules we might want to use a container system. > We've been discussing OSGi with Mandriva and eXo is using > picocontainer.. It might be a good time to think about it more in details. Cool. However I don't think the module split above would be much impacting by the choice of running inside a container or not. The modules would still be needed. It's just their implementation that would change. > Indeed it will have some impact in the development. I suggest we do this > on a branch. The objective is to get out a new release with the wysiwyg > editor and the new skins, so this should be work for the next release My advice would be NOT to do it on branch. My personal experience (on all projects where I have tried this) is that it doesn't work... You should rather do it on trunk slowly (as I did when I modified the m1 build). The reason is that the branch will never get merged in the trunk (it's just too hard to do). So what I'd do is simply start introducing the modules one by one and ensure that the current build continue to work at all times and add a new m2 build for the new modules. This is what I've done on Cargo too and I currently have two builds sitting next to each other but using a m2-enabled directory structure. Once our m2 build is as good as the m1 build, we'll remove the m1 build. Thanks and happy new year too! -Vincent > Zhong ZHENG a écrit : > > Hi the XWiki Team, > > > > I found in the mailing list archives that you are planning to use > > maven to build xwiki. I am a committer to the apache pluto project, > > which uses maven2. Thus i got some experience on maven 2. (Mr. Vincent > > Massol must be a maven master, since he is on the maven team :) I > > would like to help you migrate to maven. > > > > I checked out the xwiki source from subversion, and am trying to > > re-organize the project layout and create pom.xml files. Currently i > > am still dealing with the dependencies. I would like to propose to > > separate the xwiki project into small subprojects, and decouple the > > APIs from the implementation (such as user api and different > > implementations, plugin api and different plugin implementations, > > etc.). That will make the source more clear and more readable. > > > > I don't know how to help on this topic. Re-organizing the project > > layout introduces too many modifications on the project, which may > > have a lot of impacts on the current development, and it's difficult > > to generate svndiff and create patches. I would like to know if it is > > possible to apply for joining the dev team and create a new branch in > > svn for the maven migration. > > > > I am taking a look at the JCR spec currently, since I created a java > > wiki engine project ( http://people.apache.org/~zheng/elsie/ > > <http://people.apache.org/%7Ezheng/elsie/> ) and am thinking of > > refactoring it using JCR and apache jackrabbit. I found that you are > > also planning to implement the xwiki repository using JCR. I would > > like to help and contribute to this subproject too. > > > > Best regards. > > > > -- > > ZHENG Zhong > > - http://heavyz.blogspot.com/ > > - http://people.apache.org/~zheng/ <http://people.apache.org/%7Ezheng/> > > ------------------------------------------------------------------------ > > > > > > -- > > You receive this message as a subscriber of the xwiki-dev(a)objectweb.org > mailing list. > > To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org > > For general help: mailto:sympa@objectweb.org?subject=help > > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > > > > -- > Ludovic Dubost > XPertNet: http://www.xpertnet.fr/ > Blog: http://www.ludovic.org/blog/ > XWiki: http://www.xwiki.com > Skype: ldubost AIM: nvludo Yahoo: ludovic >

19 years, 9 months

Vote for Mandriva Club/XWiki for ObjectWeb's best use case Awards

by Ludovic Dubost

ObjectWeb is organizing a "best use case" awards for the ObjectWeb Conference. Mandriva Club usage of XWiki is nominated. Anybody can vote. It's quick and easy ! Go go XWiki community. It's simple. One vote per person (no need to cheat). http://objectwebcon06.objectweb.org/xwiki/bin/Main/Vote The conference is in Paris from January 31st to February 2nd at the same time and place as the "Solution Linux" show (which is the most known Open Source show in France). We will have a presentation of XWiki on February 2nd ! Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

19 years, 9 months

FI: Possibly interesting new prototype applications

by Jim Stuttard

Hi, Came across this while trying to learn more about Phil Wadler's 'Links' unified web language. It's the result of their summer intern program. http://www.aktors.org/interns2005/ -- Jim Stuttard

19 years, 10 months

Re: [xwiki-users] Spellcheck

by Hans Gerwitz

(Moving this to xwiki-dev) True, but a plugin architecture for simple, linear editing "workflow" beyond the present edit->preview->save might make sense. It'd be nice to have edit-time plugins that not only correct spelling, but suggest internal links, verify external links, request entry of tags, auto-create objects based on content, etc. While working on SnipSnap, I often find myself wanting to plug into the edit lifecycle. Perhaps refactoring the render lifecycle to use WikiModel presents an opportunity here? - - - Hans Gerwitz http://phobia.com/ On Dec 20, 2005, at 11:04 AM, Ludovic Dubost wrote: > > Hi, > > A spell check plugin does not make much sense anymore.. > The Googlebar is compatible with both IE and Firefox and includes a > spellcheck toll for forms > > Ludovic > > Marc Lijour a écrit : >> Hi >> >> Is there a spellcheck plugin available? >> >> Regards, >> >> Marc >> >> >> --------------------------------------------------------------------- >> --- >> >> >> -- >> You receive this message as a subscriber of the xwiki- >> users(a)objectweb.org mailing list. >> To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org >> For general help: mailto:sympa@objectweb.org?subject=help >> ObjectWeb mailing lists service home page: http:// >> www.objectweb.org/wws >> > > > -- > Ludovic Dubost > XPertNet: http://www.xpertnet.fr/ > Blog: http://www.ludovic.org/blog/ > XWiki: http://www.xwiki.com > Skype: ldubost AIM: nvludo Yahoo: ludovic > > > > -- > You receive this message as a subscriber of the xwiki- > users(a)objectweb.org mailing list. > To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/ > wws

19 years, 10 months

New Skins work

by Ludovic Dubost

Hi All, I'm working right now on new skins both for XWiki.com wikis and the open source XWiki. In the process, the structure of the main templates has been simplified to handle 2 columns by default. We plan to reintroduce the third column later. We also plan to add an easy system to choose colors for your skin using "color schemes" in the XWiki preferences. I'd like to start a discussion about which is the best skin for the default wikis on xwiki.com and in the open source wiki, as well as which one is the best skin for the xwiki.org web site. XWiki.com will have a different skin which is going to be "business oriented", which we could also use for XWiki.org. You'll find links to the skins on http://www.xwiki.org/xwiki/bin/view/Dev/Skins The three new skins are Sinorca, Blue, Wikipedia http://www.xwiki.org/xwiki/bin/download/Dev/Skins/SinorcaSkin.gif http://www.xwiki.org/xwiki/bin/download/Dev/Skins/BlueSkin.gif http://www.xwiki.org/xwiki/bin/download/Dev/Skins/WikipediaSkin.gif The other 2 skins are a little older: Business: http://pause-java.com/xwiki/previews/business/800_600.jpg ModernBlue: http://pause-java.com/xwiki/previews/modern-skin/800.jpg We are also interested in feedback about the business skin: http://www.xwiki.org/xwiki/bin/download/Dev/Skins/XWikiComBusinessSkin.gif Let us know what you think. The number one objective is deciding for a default skin for Wikis and the skin for XWiki.org. Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

19 years, 10 months

Re: Extensibility of XWiki

by Hans Gerwitz

Since this came up on xwiki-users, any idea what the timeframe for Groovy-powered custom tags looks like? Is this going to wait for WikiModel? - - - Hans Gerwitz http://phobia.com/ On Dec 19, 2005, at 9:11 AM, Ludovic Dubost wrote: > > Hi, > > The easiest solution for custom tags is the use of velocity macros > > Ludovic > > malesch a écrit : >> Dear XWiki Community >> >> I am completely new to XWiki but so far I think, it could be a >> ideal starting point for >> realizing a personal documentation system. >> >> However, I would need to extend XWiki for new custom tags which >> would allow me >> structuring my contents in a special way. >> >> Can this easily be done with XWiki? Are plugins the "way to go"? >> Can limitations >> for XWiki's extensibility already be pointed out? >> >> Thanks a lot! >> ma/esch >> >> --------------------------------------------------------------------- >> --- >> >> >> -- >> You receive this message as a subscriber of the xwiki- >> users(a)objectweb.org mailing list. >> To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org >> For general help: mailto:sympa@objectweb.org?subject=help >> ObjectWeb mailing lists service home page: http:// >> www.objectweb.org/wws >> > > > -- > Ludovic Dubost > XPertNet: http://www.xpertnet.fr/ > Blog: http://www.ludovic.org/blog/ > XWiki: http://www.xwiki.com > Skype: ldubost AIM: nvludo Yahoo: ludovic > > > > -- > You receive this message as a subscriber of the xwiki- > users(a)objectweb.org mailing list. > To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/ > wws

19 years, 10 months

Improvement: LDAP authentification with virtual wikis

by Xavier MOGHRABI

Hi XWiki developers, I'm using LDAP to authentificate users for several virtual wikis. I'm using a single LDAP a base for all the wikis. The problem I had is that when a user logged on a wiki he was only added on the wiki he logged even if my authentification is unique. So that's difficult to manage the access rights if I have to look for the user page. So, when we use virtual wikis and LDAP authentification, I propose that users should be added in the wiki where the LDAP has been configured: - 1st case if the authentification has been configured in the preferences of the Main Wiki or in the xwiki.cfg file, the users should be added in the Main Wiki. -2nd case if the authentification has been configured in the preferences of a Virtual Wiki, the users should be added in the Virtual Wiki on which the user is logging. By the way, to prevent access right problem, after having creating the user XWiki should flush the cache. Here is attached a patch that I've tested on my wikis with the 1st case only that should do this. Regards. -- Xavier MOGHRABI - Consortium ObjectWeb Email : xavier.moghrabi at objectweb.org Phone : +33 4 76 61 52 35

19 years, 10 months

TinyMCE Wysiwyg Problems

by Sascha Österle

Hello, I intesively tested the tinyMCE wysiwyg editor from the standalone package. (XWIKI 0.9.1000 - I know its a developer version) and discovered some problems. I would be gratefull for some hints/workarounds. If there are none I hope that my report is helpfull for the X-Team. 1) It does not always save when using Internet Explorer, but it is not clearly reproducable for me. Has anyone got a idea how to solve this (workaround or sth.) 2) It keeps Changing Links when saving [NoSpace] => [NoSpace] => [NoSpace] [With Space] => [With Space] => [With Space>With%20Space] [WithGermanCharÄ] => [WithGermanCharÄ] => [WithGermanCharÄ] Legend: "=> means 'becomes when saving'" From now on, IE and Firefox both show very strange links in the status bar. I believe the URLs are escaped once more before displaying. This leads to: http://../With%2520Space.... for a link that should in my opinion be http://../With+Space or perhaps http://../With%20Space This leads to several Problems: a) IE not usable b) You have to save the document twice to get your final Links. c) "http://../With%2520Space" Links are always marked as non existent. When I try to edit them, the content apears in the editor. After saving they are still shown as non existent. Wiki Syntax edited Links handled special chars and spaces well. Does TinyMCE have to escape those? How can I stop it from doing this? Thanks! Sascha ps.: Besides the links thing the editor ist just great! It works perfectly even vor longer texts. Thanks a lot for such a neat tool.

19 years, 10 months

XWiki Release?

by Paul Dlug

Is there any time estimate on a new release of XWiki? It seems to have been a very long time since the previous one. Are there also any plans to include functionality to allow one wiki page to be included inside another? (to do some rudimentary templating) Thanks, Paul

19 years, 10 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