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

by Vincent Massol

Hi, I have renamed a few JIRA components to improve consistency. Namely I've renamed them so that similar components appear next to each other. For example "Web Service Plugin" became "Plugin - Web Services", . etc. Removed "XWiki" in front of some components as 1/ everything is about XWiki and 2/ it wasn't consistent with how other components were named. I've also added a "Macros & Filters" component requested by Sergiu. Here's what we have now: - Actions and URLs (Lead: Ludovic Dubost) - Admin (Lead: Ludovic Dubost) - APIs (Lead: Ludovic Dubost) - Applications (Lead: jeremi Joslin) - Build (Lead: Vincent Massol) - Core (Lead: jeremi Joslin) - Default Wiki (Lead: Ludovic Dubost) - Documentation & xwiki.org - Editor - Wiki (Lead: Ludovic Dubost) - Editor - WYSIWYG (Lead: Phung Hai Nam) - JSR168 Module (Lead: Ludovic Dubost) - Macros & Filters - Other (Lead: Ludovic Dubost) - Packaging (Lead: jeremi Joslin) - Plugin - AntiSpam (Lead: Ludovic Dubost) - Plugin - Other (Lead: Ludovic Dubost) - Plugin - Web Services (Lead: Ludovic Dubost) - Plugin API (Lead: Ludovic Dubost) - Rights Management (Lead: Ludovic Dubost) - Scripting - Groovy (Lead: Ludovic Dubost) - Scripting - Velocity (Lead: Ludovic Dubost) - Storage (Lead: Ludovic Dubost) - Storage - JCR (Lead: Artem Melentev) - User Interface - Web Services (Lead: Arthur Casals) - Wiki features (Lead: Ludovic Dubost) I'm not sure what "Packaging" is about. I would be for renaming it to Import/Export but looking at the issues there I think there are other things in it, like packaging in the sense of distribution of files. In any case there seems to be 2 in one there. WDYT? In the future I think it's a good idea that most of these component match module names in svn (this is what we have in Cargo, Maven ,etc - ie in projects using fully maven2's directory structure). There are of course a few transversal components like Build. Anyway we'll see how it goes. Let me know if you think it's missing components/etc. We have to be careful not to have too many too. Any time you are using Other as the component it means we should have something else. BTW I haven't done it but it's a good idea to look at what's currently in Others so see the missing components... 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

18 years, 8 months

1
0
0 0

[vote] Menu for simple users

by Sergiu Dumitriu

Hi all, As http://jira.xwiki.org/jira/browse/XWIKI-562 says, the Beta2 will have two types of users, beginners and advanced. The difference is in the possible actions that the user has access to directly from the interface (all the functions can still be accessed from the right URL). We must decide which are these actions. Here is my proposal: - create: - page - blog entry - space - edit: just the top button (no submenu) with the default editor. It will be possible to switch between the 3 available tabs: WYSIWYG, wiki and page access rights. - show - comments - attachments - history - attributes (no code) - print - pdf - preview - delete - admins only Switching to the "advanced" status: in the user profile (still looking for a better solution). Waiting for your opinions. Sergiu

18 years, 8 months

4
4
0 0

[Proposal] Committers list and Emeritus committers

by Vincent Massol

Hi, Following our recently accepted definition of Committers/Emeritus Committers (see http://www.xwiki.org/xwiki/bin/view/Community/Committership) and the email entitled "[Important] Definition of Committers and their roles and responsibilities" I sent on the 28/12/2006, I have now reviewed the SVN logs to see who have been active committers for the past year. I've put some statistics on http://www.xwiki.org/xwiki/bin/download/Community/HallOfFame/xwiki-mpy-svn-s tats-20070102.zip/xwiki-mpy-svn-stats/index.html. I've also used another tool to generate more information and to find out who's not been active for more than 1 year. Note that other stats can be seen here too: http://ohloh.net/projects/68 As a reminder the goals for this are: * Get more active committers and more participations * Establish rules for defining what a Committer is * Get more transparent to the community by establishing rules and thus have clear rules for accepting new committers * Be fair to everyone I have noticed that there are 3 areas of Committers in XWiki: - Core Committers: Committers working on XWiki Core (i.e. the main XWiki distribution) - Committers working on applications built on top of XWiki (for example Curriki). Of course Core committers can also be Application Committers - Research Project Committers: We've had a few of them for the Google Summer of Code for example and we have some new ones joining us to continue the work on the P2P project. Note that non Core Committers cannot commit to the Core. They need to send patches as other contributors. Core Committers --------------- Thus I'd like to propose to confirm the following persons as Core Committers (who have been active during the past 1 year): - ludovic - Ludovic Dubost - vmassol - Vincent Massol - sdumitriu - Sergiu Dumitriu - jeremi - Jeremi Joslin - namphunghai - Phung Hai Nam - marta_girdea - Marta Girdea - jvdrean - Jean-Vincent Drean - amelentev - Artem Melentev - jkraemer - Jens Krämer - tepich - Jiri Luzny - wr0ngway - Matthew Conway - slauriere - Stéphane Laurière - torcq - Cédric Torcq - moghrabi - Xavier MOGHRABI - rewbs - Robin Fernandes - sgaide (just 1 year) - Sébastien Gaïde - Sebastien has expressed the desire to contribute an installer to XWiki. Thus even though he's not committed for just a year I'm proposing to keep him as an active committer Of course anyone on this list can decide to be moved to the Emeritus Committer status if he/she wants. Curriki Committers ------------------ - jeremi - Jeremi Joslin - ludovic - Ludovic Dubost Research Project Committers --------------------------- - thimel - Arnaud Thimel - chrabiehroy - Roy Chrabbieh Emeritus Committers ------------------- And I propose to move the following as Emeritus Committers: - kevingc - Kevin Chiu - hasseeb - Abdul Haseeb - kaaloo (just 1 year) - Luis Arias - bikash - bikash agarwalla - thomas (just 1 year) - thomas doucedame - akartmann - Alexis KARTMANN - erwan (just 1 year) - Erwan Arzur - ptcoder - Pedro Ornelas - tim - Timothée Peignier - davidbrady - David Brady - alberto - Alberto Saavedra - mpetrashev - Maxim Petrashev - huyennt - Nguyen Thanh Huyen - chungnv - Nguyen Viet Chung - arjunan - Arjunan - mileticn - Nebojsa Miletic In addition the following ids have never committed and will thus not be Committers (they were added as developers on http://forge.objectweb.org/project/memberlist.php?group_id=170). If they need to commit they'll have to be voted in: - alis - Ali Sakebi - cburleso - Cody Burleson - denis - Denis Hovart - dgrizzanti - David Grizzanti - ebilange - Eric Bilange - gflandre - Guillaume Flandre - glaforge - Guillaume Laforge - jdelaulanie - jean de laulanie - ldesmarets - laurent desmarets - leonardosouza - Leonardo Souza - Mahefasoa - NY HERIARIVONY - mjobert - Matthieu Jobert - mno - Max Nokhrin - nicka - Nick Astete - nthomas - Nicolas Thomas - poussin - Benjamin POUSSIN - raffaello - Raffaello PELAGALLI - ramihery - ramihajamalala hery - tuan08 - Tuan Nguyen - yunz - Yun Zhu Of course this is just a proposal and anyone listed here who do not agree, please contact me directly. It's very much possible I've made a mistake. I'll allow for 1 week to ensure everyone has a chance to see this mail. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

5
7
0 0

[vote] Missing searchDocumentsNames functionality

by Sergiu Dumitriu

com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames supports a selectColumns parameter which is supposed to specify which columns should be selected. This parameter is used when building the select string, but the columns are not included in the returned list, so this parameter just makes a bigger select string and increases the execution time. In order to include the specified columns in the result, I propose this: - if selectedColumns is the empty string, keep the previous behavior (return a list of document names) - if selectedColumns is not empty, then return a list of hashmaps, with the column name as the key, with a special name for the document name (for example docname)

18 years, 8 months

4
5
0 0

[xwiki-dev] Errors building in eclipse

by Dan Murphy

Hi, As per a page http://www.xwiki.org/xwiki/bin/view/Community/BuildingInEclipse there are a couple of issues if one tries to build XWiki inside eclipse. Is it of interest to get this working properly ? if so there is a .classpath file that fixes some (trivial) problems ( http://www.xwiki.org/xwiki/bin/download/Community/BuildingInEclipse/.classp… ). The catus ant task def has some errors (inside eclipse anyway) - seems to be due to the interaction between cactus-ant and junit the following warning is issued: A class needed by class org.apache.cactus.integration.ant.CactusTask cannot be found: junit/framework/TestListener xwiki-trunk build.xml line 211 This actually prevents the ant script from being executed correctly - since I don't (currently) run the targets that needs this I can get around the problem by simply commenting out the taskdef - however I'm a bit stumped on how to fix this properly (since the class in question should be available). Assuming building in eclipse is desired (and that the svn repository should contain the .classpath and other . files used by eclipse) shall I simply open a couple of jira's for these problems ? Cheers, Dan PS. Apologies for preempting any discussions on xwiki-dev by creating the "BuildingInEclipse" page, I assumed that since I could create content on the wiki then it was ok to do so... In future I'll discuss on dev list prior to creating xwiki.org content :)

18 years, 8 months

4
11
0 0

New Planning for 1.0 Release

by Vincent Massol

Hi devs, I had already sent an email saying that we needed one more release (Beta 3) as there were lots of bugs raised in Beta 1. Actually it seems we're going to need also a Beta 4 as there are really too many issues in JIRA and not enough committers and contributors working on them. I'm thus proposing the following (I have modified JIRA accordingly: Renamed RC1 in Beta 3, moved unassigned issues from Beta 3 to Beta 4, moved unassigned issues from Beta 2 to Beta 3): * 1.0 Beta 2: 8 Jan 2007 * 1.0 Beta 3: 22 Jan 2007 * 1.0 Beta 4: 19 Feb 2007 * 1.0 RC 1 : 5 Mar 2007 * 1.0 Final : 19 Mar 2007 (actually this is assuming RC1 is good enough in which case we'll label it as 1.0) The idea is to have releases every 2 weeks which is the best way to get feedbacks from users and know in advance of any issues. It also gives us a nice tempo to work with. I believe this is much better than increasing the duration times for each release. Of course if suddenly we get lot of help then we could possibly delivery 1.0 earlier ;-) AFAICS there are 5 active committers currently working on 1.0: * Sergiu * Marta * Ludovic * Nam * Vincent (me) It would be real nice if we get contributions in form of patches from other users and developers lurking here. Anything you can help fix in JIRA is a great help. We have also a big need in term of documentation help. For example we need to document all macros/plugins/etc in the Code Zone (http://www.xwiki.org/xwiki/bin/view/Code/). We have also other needs like a skin authoring guide, a configuration guide, better tutorials, etc. This is something anyone can easily contribute to. I'll send another email on the Beta 2 status. Let me know if there's any issue with the above. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

2
2
0 0

[vote] doc.isTemplate

by Sergiu Dumitriu

Hi, I often see queries like "select something where doc.fullName != XWiki.SomeTemplate", which is definitely not nice. I would like to add a new property to the document class, which indicates if the document is a template. Also, we should provide an api to select documents containing a certain type of objects, like: $xwiki.searchDocumentsWithObjects("XWiki.ArticleClass", [extraquery], [count, start]) This should behave like the current searchDocuments, but it also writes the from and where parts of the query that tie the right type of object to the document, and filters out the template documents.

18 years, 8 months

2
2
0 0

1.0 Beta 2 Release status

by Vincent Massol

Hi, Here's the status on Beta 2: * Fixed issues: 55! * Open issues: 37 * Yesterday was a record day: 17 issues were fixed! Well done to Marta and Sergiu who set up a new record on issue closing: :-) * Days remaining (including week end ;-)): 4 Here are the remaining assignments: * eveilleau thomas 1 * Francois Le Droff 1 * Ludovic Dubost 3 * Marta Girdea 10 * Phung Hai Nam 5 * Ravaneswaran Chinnasamy 1 * Sergiu Dumitriu 13 * Vincent Massol 3 Could you please all review your assignments to ensure they can be done before the 8th. They need to be finished for the 7th so that I can starting cutting the release on the 8th morning. If you know you cannot finish some please reassign them to a later release. Thanks everyone -Vincent, 1.0 Release Manager ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

1
0
0 0

[xwiki-dev] What happened to /Main/BuildingInEclipse?

by Dan Murphy

Hi All, In response to a comment on http://www.xwiki.org/xwiki/bin/view/Main/Download I created /Main/BuildingInEclipse detailing how I'd managed to get XWiki to be built in eclipse... only it's gone ! Was there something wrong with it, or was it accidentally deleted ? If the later is the case, can it be recovered or should I re-do it. If there was a reason for it being deleted please let me know so I don't make the same error twice :) Thanks Dan

18 years, 8 months

2
2
0 0

XWiki 1.0 skin and Panels need to be separated

by Vincent Massol

Hi, I think we need to cleanly separate the 1.0 skin from the Panels application. I think they shouldn't be linked and it should be possible for a user to upgrade to the XWiki 1.0 skin without requiring to install the Panels application (http://www.xwiki.org/xwiki/bin/view/Code/PanelsApplication). Conversely, it would be nice if the Panels application could be used with some other skin. Any idea on how to achieve this? How easy would it be? 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

18 years, 8 months

3
2
0 0

XWiki 1.0 JIRA issues

by Vincent Massol

Hi, Reminder: We need everyone who are committing to implement issues for 1.0 B2 and RC1 to assign issues to themselves (or unassign themselves if they cannot do it). I'd like this to be finalized by today end of day. I'll then do a full pass to see what's left and send a summary email. It's probably there'll be lots of important issues not taken up so we'll have to do some shuffling. Make you select issues please choose with the following in mind: 1) no new features 2) as little as possible of improvements 3) bug fixes in priority 4) bug fixes raised in b1 in priority. There are several issues reported by users on the list which we need to transform into jira issues (the best is to ask users who are reporting them to do that in order to help) 5) Don't put any issues in 1.0. We should have issues only in B2 and RC1. We must leave 1.0 free for any bug found when RC1 is released. 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

18 years, 8 months

2
5
0 0

[xwiki dev] 1.0 Beta 1 & XWiki Classes issues

by Dan Murphy

Hi Chaps, I'm having problems using the XWiki Class support and could do with some help... Firstly it's worth mentioning that I'm building my own XWiki from the XWIKI_1_0_BETA_1 tag in svn - but I don't think this is a problem :) When I try to edit a class, the URL is incorrect : <http://localhost:8080/xwiki/bin/edit/XWiki/TestClass?editor=class> http://localhost:8080/xwiki/bin/admin/XWiki/TestClass?editor=class Where as I think it should be : http://localhost:8080/xwiki/bin/edit/XWiki/TestClass?editor=class This looks like jira http://jira.xwiki.org/jira/browse/XWIKI-624 & I've added a comment to it about the URLs. I can get around this problem and sucesfully get create my desired class, sheet & template. However, when I create a new document with the class it doesn't seem to be adding an instance of my class automatically. Things are OK when I add the object, but I need the instance to be added automatically. Any clues / pointers on how to debug this and figure out what's wrong ? I'm running on Kubuntu 6.0.6, MySQL 5.0.21, WAS CE 1.1 & a 1.5 JDK Many thanks in advance, Dan

18 years, 8 months

1
1
0 0

[vote] Should emphasizing radeox filters ignore spaces?

by Sergiu Dumitriu

Hello, Should the following work, too? A * bold * word In my opinion, for the filter to work, the bold markers should not be separated by spaces from the text, like: A *bold* word This reduces the misinterpretations of the filter (two bolds on the same row, http://jira.xwiki.org/jira/browse/XWIKI-333 ), eliminates the confusion between bold and lists: * is this bold, * or is it a list with an asterisk? The same for italics and underline. The radeox filter rules can be easily changed, but the wysiwyg editor must put the filter markers not exactly at the selection start/end, but at the nearest character.

18 years, 8 months

3
3
0 0

W3C compliance

by Marc Lijour

xwiki.org home page is not valid html: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.xwiki.org

18 years, 8 months

4
11
0 0

[Proposal] Create wikis/ module in SVN

by Vincent Massol

Hi, I'd like to propose creating a wikis/ module in wiki/wiki/trunk, as follows: xwiki/xwiki/trunk/ |_ wikis |_ default |_ xwikiorg |_ pom.xml The idea is to save both the default wiki and the xwiki.org wikis in SVN. Right now the default wiki is saved in xwiki/xwiki/trunk/standalone/import/... which I don't think is the right place. And the xwikiorg wiki is not saved at all. The rationale for having it in SVN is 1/ to have it linked and tagged along with the sources, 2/ to have it in the IDE when we refactor stuff (for example, it's easy to go a search and replace on some tokens), 3/ to get SVN diffs on modifications brought to xwiki.org so that all developers can see the changes and also to link the JIRA documentation issues to modifications on the wiki pages. In the "far" future, it would be cool to finish the SVN storage implementation so that we could configure the xwikiorg wiki to use xwiki/xwiki/trunk/wikis/xwikiorg as the storage location. For now, we should simply be careful to use the online wikis to make changes and from time to time (say once every week - I need to automate this) export data from there and save them in SVN in the locations defined above. Another detail: for xwikiorg we should not export the users as 1/ the passwords are saved in clear in the export (that's a bug to fix) and 2/ There's no point in saving all those users registering on xwiki.org. To summarize there are 2 proposals in one here: A) Create the xwiki/xwiki/trunk/wikis/default structure and move the default wiki there B) Add the xwikiorg wiki in there too. Please provide your feedback on these 2 proposals. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

5
10
0 0

XWiki 309 : Bold codification is not the same than in wiki editor mode

by phunghainam＠xwiki.com

Hi All ? We will use syntax for bold text is *text* or _text_ for both editor mode ? and how to config to show the toolbar in wiki editor (normal mode) . >> In wysiwyg mode, bold text is coded with *text*. in wiki mode, when using the >> small toolbar, it is coded with _text_. In some cases, switching from wysiwyg to >> wiki mode, some problems appear, but I can't reproduce them systematically. I >> suggest to have a same codification between both modes to avoid any problem.

18 years, 8 months

4
7
0 0

[Proposal] New locations for skins in SVN and their delivery format

by Vincent Massol

Hi, As previously discussed, it would be nice to put skins in a specific location in SVN so that we can start delivering skins separately from the main distribution. I'm proposing to put the skins in: xwiki/xwiki/trunks/ |_ skins/ |_ <skin1>/ |_ <skinN>/ The web/* modules builds would still bundle one skin. Now the question I still have is how do we make the skins available to end users? We have 2 options: 1) We could provide them as zips. The users would then have to have access to the machine where the wiki is running and unzip them in the skins/ dir of the webapp. 2) Provide them as a single XML document (with all files attached to the skin document), as a XAR. I think option 2 is much better as it allows users to install the skin without requiring access to the machine. Note: Sergiu tells me that we need to check that attaching all the files to a skins document works as he had some issues with an old wiki. As a reminder Sergiu tells me that skin files are searched in 5 places: - XWikiSkins object property - skin doc attachment - skin directory - base skin - default skin It's a little bit more complex in term of build but it should still be doable. Here's how I envisage it: * have the skin files in the <skinN> directories as mentioned above * have the build use the XWiki Java API to do the following: - create a Document - add a XWikiSkins object to it - for each file in <skinN> attach it to the Document - export the Document in XML * have the build create a package file (XAR format) and create a XAR file Thus each <skinN> modules would produce a XAR file WDYT? 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

18 years, 8 months

2
2
0 0

[vote] Skin naming convention

by Sergiu Dumitriu

The current trunk version has 4 skin directories: - 'default' is the skin used until this autumn, the classic XWiki skin, which can still be seen on old.xwiki.org - 'new' is (AFAIK) a failed experiment for implementing a new skin, mostly empty, unused - 'xwiki10' is the skin developed this summer/autumn by Marta, with the main goal of improving usability. It was deployed on the intranet, and was used as the starting point for a few sites. Also it is the starting point for the beta1 skin (if you take away the images and colors). Thus, we call it the XWiki10 alpha skin - 'xwiki10b1' is the current skin, deployed in the beta1. Problem: we're now working on the beta2. Should we make a new directory, xwiki10b2? This is bad practice. We will also have 1.0rc1 and 1.0 final, and then 1.1 and 2.0 (with beta-s and rc-s) and who knows what next. We'll soon have a dozed directories if we keep it like that. This is why we must decide on one skin naming convention which should work for an unlimited timespan. Options: 1. We continue in the same way as it is now, making lots of skin directories 2. Each major version will have it's own skin directory. Thus, we will have 'xwiki09', 'xwiki10', 'xwiki11', 'xwiki20', etc. 2a. 'default' points to the 0.9 version 2b. 'default' points to the latest stable skin 3. As 2, but each release duplicates the skin, like a svn tag, creating xwiki10b1, xwiki10b2, xwiki10rc1, etc. 4. We only have two skin directories, 'default' and 'wip' (work in progress). Once we release a new version, we copy the wip skin as the new default. Pros and cons, as I see them: 1+ We don't have to change anything, we continue as it is now 1+ Users kep the old skin intact, nothing gets broken for them 1- Anytime we make a new release, those willing to use the new skin have to change their settings to reference the new skin 1- We make tons of directories, thus ignoring one of the benefits of version control. 1- We increase the size of XWiki a lot (the current skin has more than 1Mbyte) 2+ We let users choose their favorite skin-flavor and stick with it 2+ We offer a few different skins to choose from 2a+ we keep a piece of backwards compatibility, meaning that sites based on the default skin will not be broken with each new release 2b+ we offer the best of XWiki with each new release. Sites using the default skin unmodified will instantly have a fresh new look, and those that want to keep the old one just have to change one option. 2b+ default means default, so it should always be the skin used by default 2- We have to override the current directories. xwiki10 (the alpha skin) will be replaced with the real 1.0 skin, and any site using the alpha will have to be fixed. This problem only occurs this time, since xwiki10 was used prematurely, and only in a few sites 3+ If a user prefers the beta2 skin over the final skin, he has a choice, without asking him to never update that directory or manually copy it into a 'mycustomskin' directory 3- In theory, the skin will be almost the same between the beta1 and final version, with only minor fixes and improvements. So, anyone wanting to stick to a temporary version must be crazy :) . Of course, this does not apply to the 1.0alpha skin. 3- Again, we discard versioning 3- Again, we make too many unnecessary directories which can be retrieved from the various branches/tags 4+ We make full use of version control, and we keep the xwiki package size to a minimum. Users always have the latest version of the skin, and we don't have to maintain too many skin directories up to date with important features/fixes. 4- We have to change too many existing directories 4- It is hard to fix bugs in existing skins, so we provide poor support for those who chose to use an older skin. A big + for keeping the number of directories to a minimum and overriding existing directories: XWiki users can always copy their skin to a new directory and use it as it is, ignoring 'default' or 'xwiki10', which are subject to change. Another big + for keeping the number of directories to a minimum: new features/fixes/improvements are usually implemented in only one skin, so at least you don't have to feel bad knowing that you probably should make the change in all the other skin directories A big + for keeping a skin directory for each major release: some features/fixes/improvements must be implemented in all skin versions, for the clients using an older version of the skin Implied changes: 1: None 2a: we copy 'default' into 'xwiki09' and rename 'xwiki10b1' into 'xwiki10', overriding the alpha skin 2b: 2a + we copy the new skin in the 'default' directory 3 'xwiki10' becomes 'xwiki10a', 'xwiki10b1' becomes 'xwiki10', 'xwiki10b1' is copied from the beta1 branch 4 'default' remains the same until 1.0 rc1, 'xwiki10b1' becomes 'wip', and all the other directories are removed. After rc1, we replace 'default' with the new skin I vote for 2b.

18 years, 8 months

3
3
0 0

[Important] Definition of Committers and their roles and responsibilities

by Vincent Massol

Hi all XWiki developers, I have created a page on http://www.xwiki.org/xwiki/bin/view/Community/Committership explaining what we call a Committer and their roles and responsibilities. Please all take the time to read this page and to provide any comment you have. If nobody objects these will be the new roles and responsibilities to follow for Committers in 72 hours! :-) Once we've agreed on what is a Committer, I'll then review the svn logs and see who's been participating to XWiki for the past year and elect those who have been active participants to this new status of Committer. Those who have been committing in the further past (more than 1 year ago) will be elected as Emeritus Committers. Thanks -Vincent, self-declaimed benevolent despot ;-) ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

5
4
0 0

Beta1 and Trunk discrepancies

by Vincent Massol

To XWiki developers who have committed for 1.0 beta1: I'd like to close the 1.0 beta 1 branch now that 1.0 beta 1 has been delivered (and have a 1.0 beta 1 tag). However before doing so I've done a quick compare of trunk and beta1 branch and I've found the following changes that are newer in the beta1 branch than in trunk. I'd like to be sure we're not missing anything in trunk. Could you please verify that the trunk is ok for these files please? (I've attached screenshots of diffs to make it easy for you :-)) The left pane in the image represents beta1 and the left one represents trunk. Name State Type Changes Left Time Right Time Relative Directory ------------------------------------------------- ------------- ------ ------- -------------- -------------- ---------------------------------------------------------------------- Document.java Left Younger Text ~1 18/12/06 12:05 17/12/06 13:49 core/src/main/java/com/xpn/xwiki/api IndexUpdater.java Left Younger Text +3 18/12/06 12:04 17/12/06 13:49 core/src/main/java/com/xpn/xwiki/plugin/lucene editor_template.js Left Younger Text +11 ~53 18/12/06 12:14 18/12/06 10:44 web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor image.htm Left Younger Text +12 18/12/06 12:14 18/12/06 10:44 web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor image.js Left Younger Text +6 ~2 18/12/06 12:14 18/12/06 10:44 web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor/jscripts attachments.js Left Younger Text +12 ~29 18/12/06 12:14 18/12/06 10:44 web/standard/src/main/webapp/wiki_editor_2/plugins Thanks -Vincent

18 years, 8 months

2
4
0 0

Fwd: [xwiki-commits] [Issue] Created: (XWIKI-632) Minimize the number of build warnings

by Sergiu Dumitriu

I don't know what are the proper Affects/Fix for fields for this issues, since it is a general issue we should all keep in mind. ---------- Forwarded message ---------- From: Sergiu Dumitriu (JIRA) <jira(a)xwiki.org> Date: Dec 29, 2006 1:05 AM Subject: [xwiki-commits] [Issue] Created: (XWIKI-632) Minimize the number of build warnings To: xwiki-commits(a)objectweb.org Minimize the number of build warnings ------------------------------------- Key: XWIKI-632 URL: http://jira.xwiki.org/jira/browse/XWIKI-632 Project: XWiki Issue Type: Improvement Components: Core Affects Versions: 1.0 B2, 1.0 RC1, 1.0, 1.1, 2.0 Reporter: Sergiu Dumitriu Priority: Minor Fix For: 1.0 B2, 1.0 RC1, 1.0, 1.1, 2.0 In time, a lot of warnings have slipped into XWiki: using deprecated API, unused variables, possible null values, private unused fields/methods, unnecessary cast, unused imports... When reworking a piece of code, or a full class, also keep in mind that the number of warnings should be minimized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- You receive this message as a subscriber of the xwiki-commits(a)objectweb.orgmailing list. To unsubscribe: mailto:xwiki-commits-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

18 years, 8 months

1
0
0 0

boolean xwiki data-type

by Marc Lijour

Hi for boolean, the class editor presents 3 last fields. Form type (radio button, check box): ok Display Type: I don't get this one Default: I don't get this one ; I tried false/No/no but I always get a parsing error. Could you give some explanations on these last 2 fields? Thank you. Marc

18 years, 8 months

3
4
0 0

mailing-list issue

by Marc Lijour

I could not register to xwiki-announce from http://forge.objectweb.org/mail/?group_id=170. ERROR MSG: <xwiki-announce-subscribe(a)objectweb.org>: host cvs.objectweb.org[194.199.16.17] said: 550 Unknown local part xwiki-announce-subscribe in <xwiki-announce-subscribe(a)objectweb.org> (in reply to RCPT TO command)

18 years, 8 months

3
6
0 0

xpage=editclass link does not work

by Marc Lijour

When using the "wizard", in ClassSheet the link to edit the class points to: ....NewClass?xpage=editclass which is then redirected to ....NewClass?editor=class. The problem is that the right menu does not appear automatically when landing in the ...editor=class page. On the contrary it is there when using the top menu "edit>Class" which points directly to the ...editor=class page.

18 years, 8 months

2
2
0 0

RE: [xwiki-commits] [Issue] Closed: (XWIKI-400) Need to find a way to center an image

by Vincent Massol

Hi Nam, Was this issue fixed in 1.0 B1 or B2? If so please reopen and set the correct fix for field/ Is it about the WYSIWYG editor? If so please reopen and set the component. Also could you please review all your issues for B2, RC1 and ensure that you keep only what you're going to implement in the defined timeframes. Last could you please remove any issue from the 1.0 version (see my other mails where I explain why). Thanks -Vincent > -----Original Message----- > From: Phung Hai Nam (JIRA) [mailto:jira@xwiki.org] > Sent: lundi 25 décembre 2006 08:35 > To: xwiki-commits(a)objectweb.org > Subject: [xwiki-commits] [Issue] Closed: (XWIKI-400) Need to find a way > to center an image > > [ http://jira.xwiki.org/jira/browse/XWIKI-400?page=all ] > > Phung Hai Nam closed XWIKI-400. > ------------------------------- > > Resolution: Fixed > > This bug has been fixed ! > > To align center an image we use Horizontal Alignment option . > > > Need to find a way to center an image > > ------------------------------------- > > > > Key: XWIKI-400 > > URL: http://jira.xwiki.org/jira/browse/XWIKI-400 > > Project: XWiki > > Issue Type: Task > > Affects Versions: 1.0 B1 > > Reporter: Phung Hai Nam > > Assigned To: Phung Hai Nam > > Priority: Critical > > Fix For: 1.0 B2 > > > > > > you need to find a way to center an image (the text 'center' as the > > alignement info could add a <div align='center'> tag). > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.xwiki.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 8 months

2
1
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