- xwiki-devs@xwiki.org - lists.xwiki.org

Non alphanumerics and white spaces in Wiki page Names

by Ludovic Dubost

One thing I'm planning to do, is liberate the special characters in document names. I've had too many problems not accepting accents in wiki page names, even though for european accents they are converted to non-accentued characters automatically when used in a link. The problem is that this cannot be made general because some languages have special characters that do not have a "non-special" fallback.. So I'm thinking of letting any character being chosen in Wiki page names, using the URL encoding conversion of course. Doing this is not too much a problem. One other thing is what to do with white spaces. Currently if you type [new page] the link created is newpage I've had some complaints about it because when we show page searches it shows a concatenated text string instead of a nice page name. Another problem is that it makes it very difficult to search automatically for backlinks in the database since the white space could be anywere in the database. Backlinks would be usefull for displaying and for moving pages and automatically updating links. What I propose is to now default to new%20page for this link which one exception when the page 'newpage' already exists (this treatment could be an option). This way there would be backwards compatibility. Linked with the change for non alphanumerical characters it would free page naming. What do you think ? 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

20 years, 4 months

2
4
0 0

Document Title

by Jiri Luzny

Hi, as I'm working on the TOC stuff which will allow automatic numbering I would like to discuss an aspect that would influence how the numbering is realized. In particular, I'm interested in knowing what is the typical document structure you guys use and how you apply the headings into document sections. What I have seen on xwiki.org is a mixture of various patterns like: 1 title 1.1 chapter1 1.1.1 subchapter1 1.1 chapter2 or 1.1 title 1.1.1 chapter1 1.1.1.1 subchapter1 1.1.1 chapter2 or 1 chapter1 1.1 subchapter1 1 chapter2 or 1.1 chapter1 1.1.1 subchapter1 1.1 chapter2 In our team we used to use this pattern: 1 title 1.1 chapter1 1.1.1 subchapter1 1.1 chapter2 The problem is that generated numbered TOC than would look like: 1 title 1.1 chapter1 1.1.1 subchapter1 1.2 chapter2 which is not consistent with our company's standard Word documentation structure (a common document structure, IMHO) which has this natural TOC: title 1. chapter1 1.1 subchapter1 2. chapter2 ... My question is whether you think it would be good idea to treat a document title as a specific part of document and introduce a new tag like {title} or 0 ... and have its own CSS item. In Confluence the document title is equal to physical wiki document name and rendered separately on top of the page. Another possibility which would solve the generation of TOC issue is to add an option to the TOC tag what initial heading level it should start the generation at. I would personally prefer to treat document title specifically as I consider the mentioned TOC option as a kind of hack, IMHO. Jiri.

20 years, 4 months

2
5
0 0

RE: [xwiki-commits] r469 - in xwiki/trunk/src: . main main/com main/com/xpn main/com/xpn/xwiki main/com/xpn/xwiki/api main/com/xpn/xwiki/atom main/com/xpn/xwiki/atom/lifeblog main/com/xpn/xwiki/cache main/com/xpn/xwiki/cache/api main/com/xpn/xwiki/cache/i

by Vincent Massol

Luis, You need to try using the SVN move command instead of deleting and adding. That will preserve the history of files and it'll be lighter on the commit diffs too. Thanks -Vincent > -----Original Message----- > From: Luis Arias [mailto:kaaloo@users.forge.objectweb.org] > Sent: mercredi 20 avril 2005 22:21 > To: xwiki-commits(a)objectweb.org > Subject: [xwiki-commits] r469 - in xwiki/trunk/src: . main main/com > main/com/xpn main/com/xpn/xwiki main/com/xpn/xwiki/api > main/com/xpn/xwiki/atom main/com/xpn/xwiki/atom/lifeblog > main/com/xpn/xwiki/cache main/com/xpn/xwiki/cache/api > main/com/xpn/xwiki/cache/impl > > Author: kaaloo > Date: 2005-04-20 22:20:54 +0200 (Wed, 20 Apr 2005) > New Revision: 469 > > Added: > xwiki/trunk/src/main/ > xwiki/trunk/src/main/com/ > xwiki/trunk/src/main/com/xpn/ > xwiki/trunk/src/main/com/xpn/xwiki/ > xwiki/trunk/src/main/com/xpn/xwiki/XWiki.java [snip]

20 years, 4 months

2
1
0 0

Reorg of the source hierarchy and precise version identification

by Luis Arias

Hello all, I've been busy this afternoon doing some housecleaning in the code base: - seperate folders for src/main - core java src/test - unit tests src/test-cactus - integration tests I've been building against the latests stable jars I could find, including hibernate 3.0.1 for which I had to change a lot of imports and some stuff in the configuration files. I just commited the version numbered jars because we are going to be playing with Maven 2 tomorrow night at the OSSGTP and I figured it might be easier to write the dependencies that way. I also ported the RSS macro to Rome 0.6 because it broke on the latest commons-digester. Rome sure is a sweet API ! We're going to be doing some other interesting things with Rome. So all of this stuff is still on my machine while I continue unit tests (actually these are quite long because a lot of them are actually integration tests and bring up hibernate (with showSql = true :( ) etc...), but since cruise control is coming back up, I'm going to just make sure the build runs and ant release works. I've been working on tests for my lifeblog stuff, and I definitely like running them one at a time directly in eclipse, even the server tests through Jetty. So I have to see how to refactor that so the other tests benefit and for it all to be ant and ide compatible. I bet you have a lot of ideas on that one Vincent ! ;) My concern, is what to do about your diffs and how changes to the src hierarchy could affect your current work. I hope that doesn't cause you too much pain. Please let me know if you have any ideas on this issue because I'm a bit stumped. Actually maybe I can just tell you when I start to commit and when its done and then you can move your sources in the right place (easy to do) and update. Cheers, -- Luis Arias http://www.xwiki.com http://www.innover-entreprendre.net +33 6 14 20 87 93 mobile

20 years, 4 months

3
6
0 0

Re: Database Support

by Ludovic Dubost

Hi Bruce, Nice to meet you. The first test you need to do is start XWiki with an empty database connected to the Firebird database. In xwiki.cfg you should setup "xwiki.superadminpassword=toto" that will activate the "superadmin" user with password "toto" which will be able to setup rights. From there you should be able to access an empty wiki and create some pages to see if everythings works. Features to test are: 1/ Pages 2/ Attachments 3/ Versions One of the key features needed is the support for large text fields (without size limits). Oracle can't do this (except in the latest versions) and required some specific hibernate hacks. Converting the default Database to Firebird might be more complex. You can download the default DB on Sourceforge. It is a zipped SQL file exported from Mysql. However I think it is quite full of specific MySQL sql. I think there are some improvement in MySQL 4.1 to the export with allows for "compatible" export so you might need to import/export in MySQL to create a more compatible file. Ludovic Bruce Bacheller a écrit : >Thanks for the Quick response. > >I am on the Firebird Foundation (FirebirdSQL.org) and will get you any support needed from our THE FirebirdSQL side to get it working. > >I will host it on my site which is FirebirdXML.info or Infodes.org. >That is Linux/Apache/Tomcat. > >We are having hosting our user conference in germany next Month May 15th and I would like to have it operational for that event. I will make sure that XWiki gets good exposure to the Firebird Community as well. > >We are pretty close to Oracle in syntax. > >Can you send me a copy of the SQL code in MySQL (table creation) so I can review it and set up test. > >Looks like XWiki has developed A VERY NICE piece of Open Source Software. > >Regards, >Bruce > >-----Original Message----- >From: Ludovic Dubost [mailto:ludovic@xwiki.org] >Sent: Wednesday, April 20, 2005 3:54 PM >To: Bruce Bacheller; xwiki-dev(a)objectweb.org >Subject: Re: Database Support > > >Hi, > >We haven't made any tests, but XWiki uses hibernate and JDBC so there is >a good chance that it works. >You will need to try. We are open to requests in case of problems. > >Ludovic > >Bruce Bacheller a écrit : > > > >>Do you have plans to Support Firebird the Open Source DBMS ? >> >> >> >> >> > > > > -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

20 years, 4 months

1
0
0 0

Re: Database Support

by Ludovic Dubost

Hi, We haven't made any tests, but XWiki uses hibernate and JDBC so there is a good chance that it works. You will need to try. We are open to requests in case of problems. Ludovic Bruce Bacheller a écrit : > Do you have plans to Support Firebird the Open Source DBMS ? > > > -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

20 years, 4 months

1
0
0 0

Cruise Control

by Ludovic Dubost

Hi All, I'm currently setting-up cruise control 2.2.1 to setup a continious build on the latest SVN source. It will compile XWiki and run tests everytime there are changes in SVN, including the cactus based tests. Results will be published on a web site: http://build.xpertnet.biz and a notification email will be sent either to the dev list or the commit lists. Any comments about the choice: dev or commit list ? I might automatically publish the artifacts to one of the xwiki.com production machines. The build machine is running Mandrake Linux. 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

20 years, 4 months

2
1
0 0

Chinese Character not encoded as UTF-8 in web page

by Patrick Lee

Hi Ludovic Thanks for the help. I can now compile the svn source. On 4/19/05, Ludovic Dubost <ludovic(a)pobox.com> wrote: > > Hi Patrick, > > I think it is just that you need junit.jar in your ant installation. > > Ludovic > I now have the following questions: 1. the version # is now Version 0.9.500, smaller than the previous downloadble war file ( 0.9.543). Is this correct? 2. I have attempt to save some chinese character on a new page then try to edit it again using the default (html ) editor. Both the html page source and the editable version still show 大 etc for a chinese character, just like the previous version (0.9.543). Besides, the page source shows the following: <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta name="language" content="en" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> I suppose that the xml/html file is encoded in ISO-8859-1 instead of UTF-8. Is there anywhere I could change the default? And it is the same no matter I choose the page/document language as en or zh. 3. I have also try to export this to PDF and the result supprise me. Please check the attachment. The three encoded chinese characters have been truncated to only one code with some left over of the first and last character. I will take a look at the svn revision 452 about the uft-8 changes set soon and try to find out the problem. Thanks in advance. Patrick Lee

20 years, 4 months

2
2
0 0

Not able to compile from the svn source

by Patrick Lee

Hi all I have checked out the source from object web and try to compile it but without any success. error message is as follow: BILD FAILED /usr/local/src/xwiki/build.xml:127: taskdef A class needed by class org.apache.cactus.integration.ant.CactusTask cannot be found: junit/framework/Test I have looked into build.xml and at line 127, the following was found:  <taskdef resource="cactus.tasks"> <classpath> <pathelement location="${lib.dir}/cactus-1.6dev.jar"/> <pathelement location="${lib.dir}/cactus-ant-1.5.jar"/> <pathelement location="${lib.dir}/commons-httpclient-2.0-rc2.jar"/> <pathelement location="${lib.dir}/commons-logging.jar"/> <pathelement location="${lib.dir}/aspectjrt-1.1.1.jar"/> </classpath> </taskdef> Notice that all the above mentioned library except commons-httpclient-2.0-rc2.jar were found in the lib directory. commons-httpclient-2.0.1.jar were found in lib directory instead. I have tried to change the above to commons-httpclient-2.0-1.jar but still got the above message. What have I missed. Any help is appreciated. Patrick Lee

20 years, 4 months

2
2
0 0

TOC numbering

by Jiri Luzny

Hi, I'm working on a design of Table of Contents feature and I need a help of some XWiki expert ;-) As an optional feature the {toc} tag should allow to specify if both TOC and the actual headings should be automatically numbered (the same how it works in Word). To add the numbering into items in TOC section during a processing of a TOC velocity macro is simple but to add the number just before a text of heading in the actual content means to change the existing content in the middle of rendering. I was thinking of modifying filter.heading.print Radeox filter (BTW an easy way for adding an anchor into headings) to encapsulate the heading text by a velocity macro (which will then share the same numbering logic/variables with the TOC macro) and then let it process by VelocityRenderer. Unfortunately it doesn't work because VelocityRenderer is called before RadeoxRenderer in the chain of renderers. So, is it possible to change content of document being rendered from within a velocity or groovy macro? If not, is there other flexible way of this kind of changing of existing document content during rendering phase than to modify an existing renderer or create a new one? Thx, Jiri.

20 years, 4 months

2
1
0 0

RE: [VOTE] Moving some directories in SVN

by Vincent Massol

Hi everyone, (switching list) I really don't understand what is the problem with the: xwiki/ xwiki-plugins/ directory structure. Do you put all your files in a single directory on your machine? I believe not. I'm sure you're using folders. xwiki/ plugin1/ plugin2/ ... pluginN/ will work well *only* if we have very few plugins (and I don't think that's the plan! :-)). In addition it's not balanced with the xwiki/ directory. We could also have xwiki-core/, xwiki-plugin-manager/, xwiki-persistence/, etc at the top level but we don't. Why? Because it's better organized to have them under xwiki/ as they all are about the xwiki engine proper. The same applies for the plugins. They are all plugins. Also there are other things than plugins. Imagine some other extensions or other applications built on top of xwiki. Say an issue tracker for example. It would then go in: xwiki/ xwiki-plugins/ xwiki-tracker/ [...] It would really be a mess to mix all the plugins at the top level with other things. I don't understand what's your issue with multiple level directories. I guess you haven't seen a Maven directory structure yet too! ;-) Once and if we migrate to Maven, I can tell you that the structure inside xwiki/ is going to contain *lots* of directories! :-) I hope I have convinced you a little more... Thanks -Vincent > -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > On Behalf Of Luis Arias > Sent: jeudi 14 avril 2005 19:50 > To: XWiki.org Developers Mailing List > Subject: Re: [VOTE] Moving some directories in SVN > > Hi All, > > +1 for this structure which seems real clean and extensible. Don't > like the two level hierarchy for the plugins Vincent proposed in his > later post too much. > > Looking forward to participating in this community ! > > Luis. > > On 4/14/05, Jiri Luzny <jiri.luzny(a)seznam.cz> wrote: > > > [REPOROOT]/ > > > |_ xwiki/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin1/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin2/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > > [+1] > > IMHO it's more flexible and at the root level I would also add other > > tools that are not XWiki plugins like xwiki-scripts, > > xwiki-eclipse-client etc.. in future. > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > >get a working version ready this week. > > > > cool, cannot wait for it! The simple email notification workaround > > (http://www.xwiki.org/xwiki/bin/view/Dev/RecentChangesNewsletter) we > > use at my company is quickly reaching its limits ;-) > > > > Jiri. > > > > On Wed, 13 Apr 2005 18:08:41 +0200, you wrote: > > > > >Hi all, > > > > > >just read through the mails of the last days - this really seems to > > >become a high traffic list now :-) > > > > > >On Wed, Apr 13, 2005 at 05:04:20PM +0200, Vincent Massol wrote: > > >[..] > > >> This is not right. I'd like to transform it into: > > >> > > >> [REPOROOT]/ > > >> |_ xwiki/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ [branchname] > > >> |_ tags/ > > >> |_ [tagname] > > > > > >+1 for this one. > > > > > >> And then if we want want to add a xwiki-plugins project later on we > would > > >> have: > > >> > > >> [REPOROOT]/ > > >> |_ xwiki/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ tags/ > > >> |_ xwiki-plugins/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ tags/ > > >> > > >> This follows the standard SVN directory structure defined in > > >> http://tinyurl.com/4dhja. > > >> > > >> One reason is that the release lifecycle of xwiki/ and xwiki-plugins/ > will > > >> probably be different (you can release a newer version of a plugin > even if > > >> the core is not released again). > > > > > >here I would vote for each plugin having it's own set of > > >trunk/branches/head directories. I think different plugins will have > > >different development cycles, and imho one would not want to branch all > > >plugins just because one plugin is undergoing major changes. > > > > > >so I would suggest an architecture like this: > > > > > > [REPOROOT]/ > > > |_ xwiki/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin1/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin2/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > > > > > > >Greetings, > > >Jens > > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > >get a working version ready this week. > > > > _______________________________________________ > > Developers mailing list > > Developers(a)xwiki.org > > http://www.xwiki.org/mailman/listinfo/developers > > > > > -- > Luis Arias > http://www.xwiki.com > http://www.innover-entreprendre.net > +33 6 14 20 87 93 mobile > _______________________________________________ > Developers mailing list > Developers(a)xwiki.org > http://www.xwiki.org/mailman/listinfo/developers ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com

20 years, 4 months

3
2
0 0

XWiki syntax future direction

by Jiri Luzny

Hi, I would like to start a discussion about a concept of future extending of XWiki syntax. I already had a short email conversation with Ludovic about this topic and I would like to know your opinion. There are some missing things in XWiki syntax that prevent us to have XWiki documents as the standard documentation form in the department I work. I would like to extend the syntax with features such as Table of Content, cross-references (smarter linking inside one document), headers and footers, bookmarks in PDF output etc... There are currently two approaches how it can be done in XWiki: 1. to extend it using Radeox macros 2. to use Velocity macros and variables for it Here are a couple of examples how a document writer would then use each variant: Table Of Content: 1. {toc} 2. #toc() or ${doc.getToc()} Anchor: 1. {anchor|anchor_name} 2. #anchoe(anchor_name) Link to internal anchor: 1. [#anchor_name] 2. [${doc.fullname}#anchor_name] Include other document: 1. {icludePage:page_name} 2. #includeTopic("page_name") Ludovic tends to prefer the Velocity approach due its easier way of integrating and deploying, however I personally have a little problem with adding such basic, pure document related tags as Velocity macros. The biggest issue I see is the mixing of those two approaches without a clear separation of purpose. Most of our end-users like a Project Managers, Requirements Analysts and Testers are not skilled programmers and they treat XWiki as a Word editor for web based knowledge collaboration. It is now confusing and hard to explain to them why sometimes they should use {macro} and sometimes #macro() (I'm not even talking about explaining what ${doc.fullname} means ;-)). Both snipsnap and confluence using only radeox macros which is not that flexible as XWiki velocity macros but it is a consistent for both end-user and developer extending it. On the other hand, Velocity macros (together with Groovy) are excellent for *programming* of documents, adding fancy staff to it like the Blog macros, IM macros etc.. I would personally vote for using Radeox macros for the basic document editing and formatting capabilities and Velocity for the more advanced stuff. Jiri.

20 years, 5 months

3
5
0 0

RE: [VOTE] Moving some directories in SVN

by Vincent Massol

> -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > On Behalf Of Jiri Luzny > Sent: jeudi 14 avril 2005 06:09 > To: XWiki.org Developers Mailing List > Subject: Re: [VOTE] Moving some directories in SVN [snip] > BTW: Does anybody have any experience with Subeclipse? The current CVS > support in Eclipse is excellent so I'm curious what I would loose/gain > when switching to SVN. [snip] I'm using subclipse. The level of support is not as good as CVS but getting close. You'll probably have some issues when using svn+ssh protocol. I really recommend reading http://www.tmate.org/svn/subclipse.html. In practice I use both TortoiseSVN and subclipse. TortoiseSVN really works great if you're on windows. -Vincent

20 years, 5 months

2
1
0 0

RE: [SVN] Change of directory structure... hold your breath!

by Vincent Massol

Ok, I've done the move for the trunk. The full URL for checking out the trunk is now: [svn|svn+ssh]://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk I'll be doing the same for branches and tags now. Thanks -Vincent > -----Original Message----- > From: Vincent Massol [mailto:vincent@massol.net] > Sent: vendredi 15 avril 2005 11:23 > To: 'xwiki-dev(a)objectweb.org' > Subject: [SVN] Change of directory structure... hold your breath! > > Hi there, > > As agreed by everyone, I'm going to make the change from trunk/xwiki to > xwiki/trunk (and from branches/xwiki and tags/xwiki to xwiki/branches and > xwiki/tags). > > Thanks > -Vincent

20 years, 5 months

2
1
0 0

[SVN] Change of directory structure... hold your breath!

by Vincent Massol

Hi there, As agreed by everyone, I'm going to make the change from trunk/xwiki to xwiki/trunk (and from branches/xwiki and tags/xwiki to xwiki/branches and xwiki/tags). Thanks -Vincent

20 years, 5 months

1
0
0 0

Fwd: Moving some directories in SVN

by Patrick Lee

---------- Forwarded message ---------- From: Patrick Lee <patrickl.mo(a)gmail.com> Date: Fri, 15 Apr 2005 14:32:34 +0800 Subject: Re: [xwiki-dev] RE: [VOTE] Moving some directories in SVN To: Vincent Massol <vincent(a)massol.net> Hi Vincent I totally agree with your directory structure althought I am not a xwiki developer nor a committer, at least not yet ... Patrick On 4/15/05, Vincent Massol <vincent(a)massol.net> wrote: > Hi everyone, > > (switching list) > > I really don't understand what is the problem with the: > > xwiki/ > xwiki-plugins/ > > directory structure. > > Do you put all your files in a single directory on your machine? I believe > not. I'm sure you're using folders. > > xwiki/ > plugin1/ > plugin2/ > ... > pluginN/ > > will work well *only* if we have very few plugins (and I don't think that's > the plan! :-)). > > In addition it's not balanced with the xwiki/ directory. We could also have > xwiki-core/, xwiki-plugin-manager/, xwiki-persistence/, etc at the top level > but we don't. Why? Because it's better organized to have them under xwiki/ > as they all are about the xwiki engine proper. The same applies for the > plugins. They are all plugins. > > Also there are other things than plugins. Imagine some other extensions or > other applications built on top of xwiki. Say an issue tracker for example. > It would then go in: > > xwiki/ > xwiki-plugins/ > xwiki-tracker/ > [...] > > It would really be a mess to mix all the plugins at the top level with other > things. > > I don't understand what's your issue with multiple level directories. I > guess you haven't seen a Maven directory structure yet too! ;-) Once and if > we migrate to Maven, I can tell you that the structure inside xwiki/ is > going to contain *lots* of directories! :-) > > I hope I have convinced you a little more... > > Thanks > -Vincent > > > -----Original Message----- > > From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > > On Behalf Of Luis Arias > > Sent: jeudi 14 avril 2005 19:50 > > To: XWiki.org Developers Mailing List > > Subject: Re: [VOTE] Moving some directories in SVN > > > > Hi All, > > > > +1 for this structure which seems real clean and extensible. Don't > > like the two level hierarchy for the plugins Vincent proposed in his > > later post too much. > > > > Looking forward to participating in this community ! > > > > Luis. > > > > On 4/14/05, Jiri Luzny <jiri.luzny(a)seznam.cz> wrote: > > > > [REPOROOT]/ > > > > |_ xwiki/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > |_ xwiki-plugin1/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > |_ xwiki-plugin2/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > > > [+1] > > > IMHO it's more flexible and at the root level I would also add other > > > tools that are not XWiki plugins like xwiki-scripts, > > > xwiki-eclipse-client etc.. in future. > > > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > > >get a working version ready this week. > > > > > > cool, cannot wait for it! The simple email notification workaround > > > (http://www.xwiki.org/xwiki/bin/view/Dev/RecentChangesNewsletter) we > > > use at my company is quickly reaching its limits ;-) > > > > > > Jiri. > > > > > > On Wed, 13 Apr 2005 18:08:41 +0200, you wrote: > > > > > > >Hi all, > > > > > > > >just read through the mails of the last days - this really seems to > > > >become a high traffic list now :-) > > > > > > > >On Wed, Apr 13, 2005 at 05:04:20PM +0200, Vincent Massol wrote: > > > >[..] > > > >> This is not right. I'd like to transform it into: > > > >> > > > >> [REPOROOT]/ > > > >> |_ xwiki/ > > > >> |_ trunk/ > > > >> |_ branches/ > > > >> |_ [branchname] > > > >> |_ tags/ > > > >> |_ [tagname] > > > > > > > >+1 for this one. > > > > > > > >> And then if we want want to add a xwiki-plugins project later on we > > would > > > >> have: > > > >> > > > >> [REPOROOT]/ > > > >> |_ xwiki/ > > > >> |_ trunk/ > > > >> |_ branches/ > > > >> |_ tags/ > > > >> |_ xwiki-plugins/ > > > >> |_ trunk/ > > > >> |_ branches/ > > > >> |_ tags/ > > > >> > > > >> This follows the standard SVN directory structure defined in > > > >> http://tinyurl.com/4dhja. > > > >> > > > >> One reason is that the release lifecycle of xwiki/ and xwiki-plugins/ > > will > > > >> probably be different (you can release a newer version of a plugin > > even if > > > >> the core is not released again). > > > > > > > >here I would vote for each plugin having it's own set of > > > >trunk/branches/head directories. I think different plugins will have > > > >different development cycles, and imho one would not want to branch all > > > >plugins just because one plugin is undergoing major changes. > > > > > > > >so I would suggest an architecture like this: > > > > > > > > [REPOROOT]/ > > > > |_ xwiki/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > |_ xwiki-plugin1/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > |_ xwiki-plugin2/ > > > > |_ trunk/ > > > > |_ branches/ > > > > |_ tags/ > > > > > > > > > > > >Greetings, > > > >Jens > > > > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > > >get a working version ready this week. > > > > > > _______________________________________________ > > > Developers mailing list > > > Developers(a)xwiki.org > > > http://www.xwiki.org/mailman/listinfo/developers > > > > > > > > > -- > > Luis Arias > > http://www.xwiki.com > > http://www.innover-entreprendre.net > > +33 6 14 20 87 93 mobile > > _______________________________________________ > > Developers mailing list > > Developers(a)xwiki.org > > http://www.xwiki.org/mailman/listinfo/developers > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > > > > -- > 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 > > >

20 years, 5 months

1
0
0 0

Cool JS demos that could be of interest for XWiki Editing

by Ludovic Dubost

Here are really cool Javascript demos that combined with AJAX techniques ( http://www.ajaxian.com) would be really interesting to use to get better wysiwyg editing in XWiki. If there are any people interested to work on this don't hesitate to drop in the discussion. The slide shot sorter is quite nice and would look good for the S5 XWiki module.. 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

20 years, 5 months

3
3
0 0

Mock objects (was RE: Subversion migration done)

by Vincent Massol

Hi Luis (switching list) > -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > On Behalf Of Luis Arias > Sent: vendredi 15 avril 2005 08:38 > To: XWiki.org Developers Mailing List > Subject: Re: Subversion migration done [snip] > P.S. I have some questions about using MockObjects in my LifeblogTest. > The problem being that it seems to me that most existing tests go > through cactus and require a container. So I'm getting null pointers > and stuff because the XWiki object is not set up right. So per your > suggestion I'm going to try to do this through jmock and mockobjects > (I need both right ?). I didn't see jdk5 jars in the mockobjects tar > file so I suppose I should use the 1.4 j2ee 1.3 ones. > > I'm going through the doc and I'll post some detailed questions later > on if I need too. JMock dynamically generate the mocks for you so there's no need to have any mock class anywhere. JMock/EasyMock/DynaMock all use what is called dynamic mocks as opposed to static mocks that was done by the mockobjects.jar jar before. Check the JMock getting started guide: http://jmock.codehaus.org/getting-started.html [snip] Thanks -Vincent

20 years, 5 months

1
0
0 0

Re: Subversion migration done

by Luis Arias

Sorry ! I just replied without checking in gmail ! I hope this one goes to the right place ! On 4/15/05, Ludovic Dubost <ludovic(a)xwiki.org> wrote: > > Luis, > > It's time to move to the new list ! > > http://forge.objectweb.org/mail/?group_id=170 > > Ludovic > > Luis Arias a écrit : > > >Ok that sounds great ! I will try that this morning. Thank you > >Vincent. I'm not ready to commit anything yet but I would like ssh > >access. I signed up as kaaloo(a)gmail.com on ObjectWeb. > > > >P.S. I have some questions about using MockObjects in my LifeblogTest. > > The problem being that it seems to me that most existing tests go > >through cactus and require a container. So I'm getting null pointers > >and stuff because the XWiki object is not set up right. So per your > >suggestion I'm going to try to do this through jmock and mockobjects > >(I need both right ?). I didn't see jdk5 jars in the mockobjects tar > >file so I suppose I should use the 1.4 j2ee 1.3 ones. > > > >I'm going through the doc and I'll post some detailed questions later > >on if I need too. > > > >Luis. > > > >On 4/14/05, Vincent Massol <vincent(a)massol.net> wrote: > > > > > >>Hi Luis, > >> > >> > >> > >>>-----Original Message----- > >>>From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > >>>On Behalf Of Luis Arias > >>>Sent: jeudi 14 avril 2005 19:17 > >>>To: XWiki.org Developers Mailing List > >>>Subject: Re: Subversion migration done > >>> > >>>Hi Vincent, > >>> > >>>Very cool, after a bit of fumbling I updated the wiki and there does > >>>not seem to be anymore trace of erroneous CVS instructions. How can I > >>>handle my diffs ? Just checkout directly on top of my existing CVS > >>>tree ? > >>> > >>> > >>Here's a very simple way: > >>- You check out from the new repo using svn+ssh. > >>- You delete all the CVS directory from your old CVS tree on your machine > >>- You copy the old directory structure over the new one that you've just > >>checked out > >>- You commit. As SVN works by sending diffs only the differences will be > >>committed. > >> > >>There are probably other ways but I've used this one successfully in the > >>past. > >> > >>-Vincent > >> > >> > >> > >>>On 4/13/05, Vincent Massol <vincent(a)massol.net> wrote: > >>> > >>> > >>>>Hi everyone, > >>>> > >>>>The SVN migration has been done. All XWiki source code is now in > >>>> > >>>> > >>>Subversion. > >>> > >>> > >>>>All information about accessing the new repository is available on > >>>>http://forge.objectweb.org/plugins/scmsvn/index.php?group_id=170. > >>>> > >>>>Note that the instructions says to use > >>>>svn://svn.forge.objectweb.org/svnroot/xwiki. This is not quite correct. > >>>>Using this will check out not only the SVN trunk (the equivalent of CVS > >>>>HEAD) but also all the tags and branches. To get only the trunk, use the > >>>>svn://svn.forge.objectweb.org/svnroot/xwiki/trunk URL. > >>>> > >>>>You'll now need to use a Subversion client to check out the source code. > >>>> > >>>>Some clients that I have been using successfully in the past (on > >>>> > >>>> > >>>windows): > >>> > >>> > >>>>- TortoiseSVN > >>>>- command line svn (works on both windows and unix) > >>>>- Subclipse for Eclipse > >>>>- Intellij's IDEA (EAP version has SVN support built in) > >>>> > >>>>Note: If you're a developer and want to use the svn+ssh protocol it's a > >>>>little bit more tricky. I've found TortoiseSVN to work very fine. If > >>>> > >>>> > >>>you're > >>> > >>> > >>>>using subclipse you'll need to read > >>>> > >>>> > >>>http://www.tmate.org/svn/subclipse.html. > >>> > >>> > >>>>If you're using IntelliJ you should search for "svn+ssh" in the forums > >>>>(you'll see some of my posts explaining how to do it). > >>>> > >>>>For a good free book on Subversion, see http://svnbook.red-bean.com/ > >>>> > >>>>Ludovic, you can turn off the old CVS repo. We also need to update the > >>>>instructions on the wiki. > >>>> > >>>>Thanks > >>>>-Vincent > >>>> > >>>>_______________________________________________ > >>>>Developers mailing list > >>>>Developers(a)xwiki.org > >>>>http://www.xwiki.org/mailman/listinfo/developers > >>>> > >>>> > >>>> > >>>-- > >>>Luis Arias > >>>http://www.xwiki.com > >>>http://www.innover-entreprendre.net > >>>+33 6 14 20 87 93 mobile > >>>_______________________________________________ > >>>Developers mailing list > >>>Developers(a)xwiki.org > >>>http://www.xwiki.org/mailman/listinfo/developers > >>> > >>> > >>_______________________________________________ > >>Developers mailing list > >>Developers(a)xwiki.org > >>http://www.xwiki.org/mailman/listinfo/developers > >> > >> > >> > > > > > > > > > > -- > Ludovic Dubost > XPertNet: http://www.xpertnet.fr/ > Blog: http://www.ludovic.org/blog/ > XWiki: http://www.xwiki.com > Skype: ldubost AIM: nvludo Yahoo: ludovic > > -- Luis Arias http://www.xwiki.com http://www.innover-entreprendre.net +33 6 14 20 87 93 mobile

20 years, 5 months

1
0
0 0

Commit access on GForge for current XWiki committers

by Vincent Massol

Hi everyone, If you're a current committer on Sourceforge you'll need to register on objectweb so that we can give you commit rights. Let Ludovic or myself know about it and we'll add you as committer on GForge. Thanks -Vincent

20 years, 5 months

1
0
0 0

SVN rights for developers

by Daniel López

Hi All, I have a question about ObjectWeb IDs when downloading from svn. To download nightly versions of xwiki files, will be necessary to identify as Objectweb users by ID instead of anonymous, like it was with sourceforge? Thanks, Danielo

20 years, 5 months

2
1
0 0

Re: [VOTE] Moving some directories in SVN

by Daniel López

Hi everybody, Mine is +1. It looks better organize. Danielo. Vincent Massol wrote: >Hi again, > >The current directory structure in SVN is: > >[REPOROOT]/ > |_ trunk/ > |_ xwiki/ > |_ branches/ > |_ [branchname] > |_ xwiki/ > |_ tags/ > |_ [tagname] > |_ xwiki/ > >Where REPOROOT = svn[+ssh]://svn.forge.objectweb.org/svnroot/xwiki > >This is not right. I'd like to transform it into: > >[REPOROOT]/ > |_ xwiki/ > |_ trunk/ > |_ branches/ > |_ [branchname] > |_ tags/ > |_ [tagname] > >And then if we want want to add a xwiki-plugins project later on we would >have: > >[REPOROOT]/ > |_ xwiki/ > |_ trunk/ > |_ branches/ > |_ tags/ > |_ xwiki-plugins/ > |_ trunk/ > |_ branches/ > |_ tags/ > >This follows the standard SVN directory structure defined in >http://tinyurl.com/4dhja. > >One reason is that the release lifecycle of xwiki/ and xwiki-plugins/ will >probably be different (you can release a newer version of a plugin even if >the core is not released again). > >XWiki committers, Please cast your vote: > >[] +1, I agree >[] 0, I don't have any opinion >[] -1, I don't agree. State your reason > >Here's my +1 > >Thanks >-Vincent > > >_______________________________________________ >Developers mailing list >Developers(a)xwiki.org >http://www.xwiki.org/mailman/listinfo/developers > >

20 years, 5 months

1
0
0 0

Just a test

by Luis Arias

How do incoming messages look on this list, I want to set up my labels... -- Luis Arias http://www.xwiki.com http://www.innover-entreprendre.net +33 6 14 20 87 93 mobile

20 years, 5 months

1
0
0 0

Welcome!

by Vincent Massol

Welcome everyone to this new list @ Objectweb. -Vincent _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com

20 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs